kamil interesting thread to follow.
I do have one package that I would like to have but, that's a huge PITA.

I've looked at it several times but always walk way from it cause, it's too much work to do alone, qt5-qtwebengine

    Jay Cinnamon should really get some issues sorted out and move forward from the deprecated mozjs52, even Debian is considering dropping support, https://github.com/linuxmint/cjs/issues/80

    As for plasma, one issue I'm aware of is kwin dependency on libinput

    • Jay replied to this.
    • Jay likes this.

        pfr FreeBSD has a patchable port of xbacklight for Intel chips.
        Really low hanging fruit here, I've asked for a release tag a few months back but, no reply.

        • pfr likes this.

            I'd say:

            1. kubectl
            2. oc
            3. docker client (yes the client can be compiled on non-Linux OS, just like OpenBSD recently did).
            4. CDE

            My list of precedent features in the host system:

            • Linux-compatible-in-spirit backend for Linux-input subsystem and ported on top of it libinput + libudev for input/output/networking
            • logind drop-in replacement
            • finished futexes and switched libpthread to them
            • stabilized AIO
            • Modern container and sandbox system APIs (equivalent in functionality to namespaces, cgroups, etc)

            And then the following programs in pkgsrc (+including full ports to NetBSD):

            • Valgrind
            • VirtualBox
            • Gnome3
            • KDE Plasma (KDE5)
            • Docker, Kubernetes, Podman
            • systemd-nspawn a homegrown replacement
            • .NET
            • LLVM linker (LLD) (the integration with NetBSD is not finished)
            • GNU toolchain with fully upstreamed local patches
            • qemu with all features ported
            • DPDK with all features ported

            One extra item:

            • GPLv2 Linux filesystems as loadable kernel modules

              kamil once futexes are ready qtwebengine should be just an insane amount of patches.

              Any clue about when futexes could become available?

                  pin There is chance that in NetBSD-10 an initial version for public consumption. Unfortunately a revamped version of libpthread might not be ready for this release and wait for another one.

                  • pin replied to this.
                  • pin likes this.

                      kamil Modern container and sandbox system APIs (equivalent in functionality to namespaces, cgroups, etc)

                      Yes, that would be great.
                      As I said in another topic, the possibility to run Docker containers on NetBSD would be incredible, especially if a NetBSD node could be integrated in a Kubernetes cluster, just like Windows-powered nodes. I think NetBSD is a great fit for containers both as host OS and as a container OS.
                      Also, since NetBSD can run Linux binaries through the syscalls translation, it could even become possible to run Linux containers on a NetBSD host. But, hey, I'm daydreaming now. 😄

                      kamil systemd-nspawn a homegrown replacement

                      nspawn is a great feature, but to be honest, kamil, I'd prefer that the nspawn features would be ported to the chroot command. Since UNIX systems already has such facility, I think improving it would be a better strategy than rewrite another tool that is doing the same (no, well, actually it's not doing the same thing, but the result is mostly that).
                      Since you have more knowledge and visibility of the NetBSD's chroot implementation than I am, do you think that improving it by introducing the same capabilities of nspawn (without destroying backwards compatibility, I guess) would be possibile, or it would be better to write a specific tool, like systemd developers did?

                            Small wishes:

                            1. Make man honour a MANWIDTH env. variable.
                              Right now, I've munged man.conf to add -O width=$((${COLUMNS:-80} - 3)) where needed, and that's as ugly as it looks here. Should be trivial to query the terminal to get column-width if MANWIDTH=tty and then pass an appropriate -O width=... to mandoc.

                            2. Change the kernel messages when adding/deleting GPT partitions to be less scary.
                              The first time I used gpt and saw those deleting /dev/dkXX messages, I thought: Dear God, did the system just delete all my existing partitions right now for some bizarre reason?

                            Related, but, considerably more difficult I imagine:

                            1. gpt should gain a commit command, and the corresponding -f x flag (like FreeBSD's gpart) for the other commands, to defer writing GPT mods until a final commit has been done.

                              Sam

                              I'm daydreaming now.

                              Help to make this dream come true!

                              nspawn is a great feature, but to be honest, kamil, I'd prefer that the nspawn features would be ported to the chroot command. Since UNIX systems already has such facility, I think improving it would be a better strategy than rewrite another tool that is doing the same (no, well, actually it's not doing the same thing, but the result is mostly that).
                              Since you have more knowledge and visibility of the NetBSD's chroot implementation than I am, do you think that improving it by introducing the same capabilities of nspawn (without destroying backwards compatibility, I guess) would be possibile, or it would be better to write a specific tool, like systemd developers did?

                              chroot(8) is designed as a wrapper over the chroot(2) syscall. nspawn(8) could wrap over native APIs delivering namespaces + cgroups. There is some overlap from high lever point of view, but the internals would differ significantly and the feature set of nspawn, with OCI standards integrated is incomparable to chroot(8).

                              Thus, we could add a secure version of chroot that plugs the security issues from the real chroot(8) and enable it for normal users. A demonstrative version of a secure chroot was crafted with the research project on netbsd-sandbox. It could be shipped as a drop-in replacement for the current chroot(8) users.

                              • Jay likes this.

                                I would like to have qutebrowser and badwolf working. Probably qutebrowser doesn't currently start because of an issue with the package @pin was mentioning, qt5-qtwebengine, which is not present in pkgsrc.

                                • pin replied to this.

                                  rockyhotas ...and badwolf working...

                                  badwolf works fine, I've been using it as my only web browser for the last 4 months.
                                  What's not working for you? pkgsrc branch?

                                  As for qutebrowser, ...it's doomed to no longer work with the qt5-qtwebkit backend at some point. qt5-qtwebengine will be the only option.