Lately I’ve been exploring FreeBSD and OpenBSD. One of the more interesting things about them is how they handle OS and package upgrades.

On FreeBSD, the freebsd-update command is used for upgrading the OS and the pkg command is used for managing user packages. On OpenBSD, the syspatch command is used for upgrading the OS and the pkg_* commands are used for managing user packages.

Unlike Linux, these BSDs have a clear separation of OS from these packages. OS files and data are stored in places like /bin and /etc, while user installed packages get installed to /usr/local/bin and /usr/local/etc.

On the Linux side, the closest thing I can think of is using an atomic distro and flatpak, homebrew, containers, and/or snap for user package management. However, it’s not always viable to use these formats. Flatpak, snap, and containers have sandbox issues that prevent certain functionality; homebrew is not sandboxed but on Linux its limited to CLI programs.

There’s work being done to work around such issues, such as systemd sysext. But I’m starting to feel that this is just increasing complexity rather than addressing root problems. I feel like taking inspiration from the BSDs could be beneficial.

  • Voytrekk@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    1
    ·
    23 hours ago

    You could use something like homebrew for your packages while keeping just system packages to the default package manager. It has the upside of being separated and more recent, but it can mean duplicate packages are on the system.

    • Leaflet@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      22 hours ago

      Homebrew is good for unsandboxed CLI programs, but unfortunately not GUI apps.

      An issue I ran in the past when using a custom OS on my phone was that flatpak, containers, or snap were able to talk to my phone properly to flash the OS. So on an atomic distro, I would either have to install Chromium using something like rpm-ostree, systemd systext, or boot into a traditional distro like Debian.

      • just_another_person@lemmy.world
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        18 hours ago

        You are fundamentally misunderstanding how these work though. “Sandbox” is good when any userspace executed binary may comprise a system. How does that refer to a GUi, as you are using it? The actual executable code has nothing to do with it having a graphical interface.

        • Leaflet@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          12 hours ago

          Thats not what I’m saying.

          My first point is that homebrew is only good for CLI applications. Almost no GUI apps are available, the only one I know of is xeyes.

          My second point is that homebrew is unsanboxed. That’s good for programs that don’t work well sandboxed, such as fetch tools like fastfetch.

          This leaves a gap of a good supported way to install GUI apps that are unsandboxed. I used to need this when I used an Android phone with a custom OS. I needed to have unsandboxed Chromium with adb tools to flash and update the OS. However, when sandboxed, Chromium doesn’t have access to adb tools.

          • just_another_person@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            7 hours ago

            Again, no. There are a myriad of ways to do this if you just want a plainly, locally installed and running program:

            1. Both RPM and dpkg support being able to unpackaged or install packages into your local home directory.
            2. Download source, build and install yourself

            You’re just adding arguments on arguments that aren’t making any sense now. You’re original comment and understanding has been addressed.

            • Leaflet@lemmy.worldOP
              link
              fedilink
              English
              arrow-up
              1
              arrow-down
              1
              ·
              6 hours ago

              You’re just adding arguments on arguments that aren’t making any sense now. You’re original comment and understanding has been addressed.

              My main point is that I’m worried about additional complexity. On most atomic distros, you’re not supposed to touch the base system, so various tools are preinstalled or available: flatpak, podman, homebrew, snap, appimages, systemd sysext.

              The BSDs seem to enjoy a separation of OS and user packages with reduced complexity. Though their task is easier since they are complete operating systems, whereas linux is just a kernel and many different projects put together, and many different groups putting out their own distros with varying packages and compatibility.

              Both RPM and dpkg support being able to unpackaged or install packages into your local home directory

              These don’t seem to be advertised features. More like hacky workarounds. Complex rpm commands. Ubuntu thread with various proposed solutions.

              It would be really cool if dnf and apt got good, easy, simple support for installing packages into the home folder. But that’s not what’s happening. The proposed solution seems to be systemd sysext, which again, prompted me to have worries about complexities about how software is being managed on more “modern” distributions.

              You’re just adding arguments on arguments that aren’t making any sense now. You’re original comment and understanding has been addressed

              And I keep discussing it because I enjoy doing so.