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.

  • AnUnusualRelic@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    6 hours ago

    I think of those as BSD thoughtful and pondered, and Linux as fairly fast and maybe thoughtless (in the jouyful sense that things have to go forward). In the end BSD is definitely cleaner, but behind, and Linux is much messier but is at the front of what’s going on.

    And I’m sayin this as someone who’s worked with both systems for decades and even though I prefer Linux on the desktop or on servers, on embedded systems, where you’d need some really clean code to poke at, BSD really shines.

    Of course BSD works fine (mostly) everywhere. It’s almost as good today as it was in 2000.

  • steeznson@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    4 hours ago

    Alpine package manager and use of MUSL over glibc are pretty similar to a BSD. Like others have pointed out there are limits to how closely a Linux distro can match the deliberate structure of those distros given the different design philosophy

  • nyan@sh.itjust.works
    link
    fedilink
    arrow-up
    2
    ·
    10 hours ago

    Gentoo will allow you to update the small set of required system packages and their dependencies separately from everything else (emerge --update system), but doing the reverse would require some pretty heavy micro-management.

  • INeedMana@piefed.zip
    link
    fedilink
    English
    arrow-up
    7
    ·
    15 hours ago

    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.

    What do you consider the OS? Is firefox a part of OS? Is office part of OS?

    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.

    Personally, the ditching of /usr/local mess was one of the selling points of Arch for me, but in a way you could achieve this in Arch. Create a secondary pacman config with RootDir set to /usr/local and alias pacman --config /etc/pacman_local.conf as pkg_pacman

    • Ŝan@piefed.zip
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      12 hours ago

      Points for þe how-to. In not sure I agree about losing /usr/local being a good þing. An argument could be made for AUR installing only into /usr/local; þen we could go back to best practices of sanitizing $PATH order. It’d also alleviate some naming conflicts which were less of an issue in older Unixes like Solaris.

      What specifically about /usr/local bothered you so much þat getting rid of it would be a selling point?

      • INeedMana@piefed.zip
        link
        fedilink
        English
        arrow-up
        1
        ·
        12 hours ago
        1. it partitions same things into separate locations One library is here, another one is here, some older version there, which one should this binary load? Where should I point the -L to? Of course, compiling things completely from scratch is unmaintainable anyway (that’s why PKGBUILD was another big point - it’s easy to create your own AUR packages that will get pacman-level maintainability), but sometimes you want to check if that new patch solves your issue
        2. if distro does not care, the packages will have different prefixes I can see some use of /opt. But it should be my decision if I want something installed in /opt/bin or /usr/local/bin. In distros that did not enforce where things are put in, it was all over the place. But to be fair, to me, even bin/sbin separation is bs
  • jollyrogue@lemmy.ml
    link
    fedilink
    arrow-up
    11
    ·
    19 hours ago

    There are none. Linux is a baseless system, which is its power and frustration.

    You could install Debian or Alma Linux and run pkgsrc on it to approximate a base and extra packages setup like the BSDs.

    There are parts of a tightly coupled userland forming, like iptools and systemd, but there are many things missing at the moment.

  • deadcade@lemmy.deadca.de
    link
    fedilink
    arrow-up
    10
    ·
    20 hours ago

    To answer the question in the title: No, because these systems inherently have different architecture. Something like OpenBSD (the OS) is relatively self-contained. Linux distributions have system components that are externally developed, but a user might rely upon.

    What exactly is the “problem” you have with Linux package managers? It’s specifically extra complexity to separate “system” and “packages”. This works well for *BSDs that often develop the entire OS themselves, but would pose extra challenges for Linux distributions, where the line between “OS” and “user installed package” is much more blurred.

  • black_flag@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    13
    ·
    22 hours ago

    I feel like in Linux any distinction between “OS” and “something else” would be arbitrary, except, perhaps the example of the AUR vs regular packages in arch, or maybe the universe repo in Ubuntu. Why would you want a whole different system for managing those packages?

    • jollyrogue@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      19 hours ago

      It’s not so much about a second package manager as it is about having a base system and separating extra software from the base system.

      Moving extra packages out of the base system allows the extra packages to be updated quicker. Fewer things get frozen when the stable point in time distro release is tagged. This also helps the base as it can move without having to worry about every piece of software in the repos being compatible with the changes.

      The concept exists as 3rd party repos. However, most aren’t setup to be as cleanly separated as ports are.

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

      You’re not really “managing” the OS files, you’re just applying patches and upgrading to new releases. All the interesting stuff (from the user perspective) is done using pkg on FreeBSD and pkg_* on OpenBSD; it’s with those you install your packages like the DE/WM, web browser, CLI tools, etc.

      There’s a couple of benefits to splitting these. Makes it easier to “reset” the system to its default state and makes it impossible to accidentally break the OS (you can’t accidentally remove any critical components like the kernel).

  • Eugenia@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    ·
    17 hours ago

    No, there isn’t, however, NixOS is made by ex-freebsd people, and some of the philosophy has bled through there. Have a look at it.

    • bobo@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      16 hours ago

      My NixOS config works this way

      nixos-rebuild switch --upgrade for system package upgrades and config changes

      home-manager switch for user package updates and config changes

  • Red Rozenglass@fedi.dreamscape.link
    link
    fedilink
    arrow-up
    2
    ·
    17 hours ago

    @that_leaflet@lemmy.world Slackware is the closest I know. It has a set of packages that it considers the official distribution, and you’re supposed to install all of them unless you know what you’re doing, and it doesn’t provide any more extra packages to choose and install; anything else you might need that’s not in the default install, you install from a ports-like community repo called SlackBuilds.org, or other providers of SlackBuild scripts or pre-built packages. To update the entire core system, you run slackpkg update && slackpkg upgrade-all. It will only upgrade Slackware’s core packages, and not your extra packages. If you’re running a stable Slackware version, then those upgrades have very little chance of breaking your dependent extra packages. If you want to upgrade your extra packages, then that’s on you, whether you’re doing it manually, or using one of the many community-made non-official package manager. This setup has been very stable in my commercial production experience which started with Slackware 15.0.

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

      I’m worried about complexity. Traditional Linux package management isn’t perfect. Atomic distros try to address this in various ways, including but not limited to a clear separation of OS and user packages.

      For example, on Fedora Silverblue you’re not meant to modify the base OS with rpm-ostree. You’re supposed to use flatpak and toolbox (homebrew and appimages are also options, but not preinstalled). But these have limitations that rpms do not.

      On the BSDs, this isn’t really a problem. It manages a clear OS and user package split without the sandboxing limitations. That’s not to say that sandboxing is bad, I fully support it, but when you run into the currently unfixed limitations, it’s a pain. As an example, in the snap and flatpak versions of Chromium-based browsers, you can’t use Android’s adb tools, which I used to need when using custom OSs on my Pixel. You either have to overlay the rpm or use a non-atomic distro.

      Systemd sysext is being thrown around as the solution to this problem as the way to install software that needs to be unsandboxed but without modifying the base OS. But I don’t see why instead we can’t just still be able to install RPMs on the base system, but to places like /usr/local/bin. The systemd sysext method seems like an unnecessary reliance on systemd and additional complexity. Take this for example: https://github.com/mmcnutt/Bazzite-Discover-Sys-Ext. There’s so much work being done, what what is basically just taking the existing Plasma Discover rpm and converting it into a new format.

  • 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.

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

    You’re just describing organizational things, and this is what makes a distribution its own thing in some sense.

    It’s hard to succinctly describe the difference between BSD and Linux, but essentially, in BSD the OS is everything: kernel, tools, extensions…etc. You’re always interacting with the OS when you change something. It’s like interacting with a single binary that has everything packed into it.

    In Linux, the tools provided to manage packages are largely just automation to verify, acquire, unpack, and link the various contents of packages. The OS is the kernel, which is separate from everything else, and aside from custom additions like DKMS modules, everything comes from the same source.

    I’m not sure what you mean with the update tooling having some “clear separation of OS from these packages”, but maybe you want to try and expand on that a bit. If you’re talking about BSD, that’s wrong, because all the packages management tools are directly executed from the OS, and change the running OS.

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

      I’m not sure what you mean with the update tooling having some “clear separation of OS from these packages”, but maybe you want to try and expand on that a bit

      On FreeBSD and OpenBSD, OS upgrades are handled by the freebsd-update and syspatch commands respectively. User package installs are handled by the pkg and pkg_* commands respectively.

      The pkg tools do not touch the base OS. That also helps avoiding issues like uninstalling critical system packages and makes it easier to wipe the system to a “clean” state, undoing user modifications.

      It’s hard to succinctly describe the difference between BSD and Linux, but essentially, in BSD the OS is everything: kernel, tools, extensions…etc

      It also certainly helps that neither FreeBSD or OpenBSD comes with desktop environments by default. That muddies the water of what is an OS package and what is a user package. If desktop environments were treated as OS packages, then it would not be possible for the users to uninstall the DE apps.

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

        The pkg tools do not touch the base OS. That also helps avoiding issues like uninstalling critical system packages and makes it easier to wipe the system to a “clean” state, undoing user modifications.

        Well this is just a subjective and semantic take, and it’s mostly around your individual perception of what happens when you interact with userspace.

        You seem to be assuming that OS provided packages are the only packages people interact with, and that they all require modifications outside of UserSpace, but that is not so. AppImage, Flatpak, various types of container runtime configs…etc. These are all very popular ways to run things without privilege escalation. You can install and run most RPMs in userspace if their packaging doesn’t otherwise require system alterations.

        Re: Desktop Environments. They’re just userspace programs like anything else in unix-like systems. They aren’t part of the OS layer anywhere on BSD or Linux. The APIs they communicate with are the things running with escalated privileges.

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

          I’m not saying they’re running with special privileges, just that they’re part of the “OS”. Stuff that comes included with every system and that should not be removed.

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

            But that’s not accurate. I’m not trying to be pedantic here, just correcting your assumption.

            Think about it like this: there’s Fedora Workstation, and Fedora Server. The only functional difference between those two distros is the package selection. If I install Fedora Server, which comes with no desktop, all I have to do to turn it into Fedora Workstation is install the packages for a desktop environment. No fundamental changes are made to the OS (kernel) at all. Vice versa also works in turning a “desktop” into the server flavor. It’s just packaging.