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.
Why do you consider this a problem?
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.