> As a sysadmin, your goal for long term stability is to separate the important bits from the volatile bits to stop them from treading on each other’s toes.

> Separation of the core OS from the services it is running is the key to keeping a hygienic separation between components sharing the same file system.

This sounds sensible on the surface, but I'm not convinced. Surely if I run a production system that actually does something, the critical bits I would want separated is not just the core OS, but the core OS plus whatever production software I run on it.

And at that point, why would I want to install any other volatile bits on that system?

It only sounds like a partial solution really. You'll still end up with a load of random files in `/usr/local/etc` and unless you maintained a 100% strict policy of only installing using Ports (yeah right) you will eventually get some files of unknown origin.

The proper solution is proper separation of app files, as found on Mac (more or less), NixOS, Android and iOS.

I guess FreeBSD is still stuck in the 90s with Linux (except NixOS).

This

The thing I dislike about this kind of article is that they contain enumerations of relatively small deltas between systems. Things that you can bicker over for hours ("look, FreeBSD has better ZFS support", "but FreeBSD is actually rebasing on ZFS on Linux"). But they do not matter that much in the end. FreeBSD does not provide any meaningful changes compared to Linux that will convince most Linux users; and vice versa. These discussions usually boil down to some form of tribalism.

For me the excitement is in projects that radically change FLOSS systems, addressing their shortcomings. For example:

- Docker, despite its shortcomings, drastically changed how software is deployed in most companies (most FreeBSD folks don't seem to get this, it's not about "we had jails earlier", it's all about the ease of packaging/deployment).

- Nix and Guix completely change package management, by treating packages as values built by pure functions. Allowing using several (isolated) versions of packages in parallel, reproducibility, per-project environments, fully declarative system configuration, atomic upgrades/rollbacks.

- Fedora Silverblue takes Fedora, but changes it to a stacking of OSTree snapshots, providing a largely read-only root filesystem, with atomic upgrades and rollbacks. Applications are installed through Flatpak. Development is done through rootless containers with Podman.

Not all of these projects and ideas may end up being adopted industry-wide, but they explore exiting new directions in packaging, system management, etc. Which to me is far more interesting than bickering over which kernel is slightly better in which use case, or separation between a base system and third-party ports which don't solve the 99 problems in packaging that actually matter (such as: this old project needs an ancient Boost version and in my 'global FHS namespace' package manager having two versions of Boost is conflicting).

I am currently using NixOS and Nix on Mac, but I am also actively tracking Guix and Silverblue because these projects are so damn exciting.

How does Silverblue handle the real world, where does it fail? Nix was the fight concept a decade a go I'm a amazed that it has come so far. Packaging is soo hard atm, the question for me is always how can I get this system to build cleanly with the least amount of work (now and in the future). This is not something docker solved completly, but almost (tracking vulns in base docker images sucks, and using external DBs to track supply lines and what is running on all hosts is not how it should be done)

I always thought that /usr/local in FreeBSD was meant only for ports, not for custom software, and that is supposed to go in /opt.

In any case I agree with the need of proper separation of app files. If we could adapt a bit the base tools of the OS, I think we could get there at least half-way there easily. For example if I could write something like

PATH=$PATH:/opt/*/bin

I wouldn't need to symlink every custom binary that I install (and similarly for man pages, service files etc.)

>unless you maintained a 100% strict policy of only installing using Ports (yeah right)

What do you mean "yeah right"? That's precisely how everyone I know has always managed our BSD fleets. If something isn't in ports (yeah right), you just make a port out of it. It takes 5 minutes unless the software has some crazy messed up build system.

Same on Linux, unless the software has some crazy build system, at which point you probably won't and that's exactly OP's point.

I have no idea what you are trying to convey.

It's quite simple really. On BSDs you tend to use ports to keep your filesystem tidy, but the moment you need something that's not already packaged you either a.) package it yourself b.) the build system is complex and thus you don't package it properly and make a bit of a mess on your filesystem.

So while BSDs might have slightly better FS layout as far as separation of user & system software, in the end you'd probably end up with a bunch of untracked files outside the system's software manager, no matter if you're on Linux or BSD.

Again, you're just ignoring what I said. I've managed tens of thousands of BSD systems for 25 years. I've never had anything installed that wasn't registered in the package database so all its files were uninstalled correctly. Yes, you literally do stick entirely to ports, creating a port when needed. Having a complex build system doesn't mess up your filesystem, it makes it take longer to create the port.

Good for you, but you can do exactly the same on Linux, so there's no advantage for BSDs there.

My myself have seen plenty of cases of people not having the time to create a package for a software they need now, but maybe the domain BSD is used in is less prone to needing software prone to that. Maybe it's just you being lucky.

However again, that's not a technical benefit. You can do exactly the same on Linux.

>Good for you, but you can do exactly the same on Linux,

Nobody suggested otherwise. Read what you reply to.

> If something isn't in ports (yeah right)

Err, yeah yes. Not everything is in Ports. Software doesn't magically appear in Ports as soon as it is written. I would have thought that was blindingly obvious.

99%+ of software people use is in ports. And for the <1% that isn't, it takes 5 minutes to make one. Like I said in the post you replied to without bothering to read.

> Separation of the core OS from the services it is running is the key to keeping a hygienic separation between components sharing the same file system.

I try to achieve this goal on my linux servers with containers, more precisely at the namespaces separation level which gives the ability to mount a set of config files inside the service's container. The other advantage is that versioning a service configuration becomes easy, allowing both clean undo/redo strategies and remote backup. I'm pretty lazy so I'm using docker, but really the gist is around mounting config files for a segregated service process.