47
submitted 18 hours ago by that_leaflet@lemmy.world to c/linux@lemmy.ml

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.

you are viewing a single comment's thread
view the rest of the comments
[-] just_another_person@lemmy.world 2 points 18 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.

[-] that_leaflet@lemmy.world 3 points 17 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 1 points 17 hours ago* (last edited 13 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.

[-] that_leaflet@lemmy.world 2 points 17 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 2 points 16 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.

this post was submitted on 26 Aug 2025
47 points (100.0% liked)

Linux

57670 readers
627 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS