The desire to be different is strong with some people.
From the BSDs, I think only OpenBSD has a really unique selling point with its focus on security. People ask "why pick FreeBSD rather than Linux" and most will not find compelling arguments in favour of FreeBSD there.
Can you give that shot for me on Linux? Could you spin up a Ubuntu 14 VM and do a full system update to 24.04 without problems? Let me know how you go.
I once needed help with a userland utility and the handbook answered the question directly. More impressive was the conversation I had with a kernel developer, who also maintains the userland tools — not because they choose too but because the architecture dictates that the whole system is maintained as a whole.
Can you say the same for Linux? You literally cannot. Only Arch and RedHat (if you can get passed the paywall) have anything that comes close to the FreeBSD Handbook.
FreeBSD has a lot going for it. It just sits there and works forever. Linux can do the same, if you maintain it. You barely need to maintain a FreeBSD system outside of updating packages.
Most people who use containers a lot won’t find a home in FreeBSD, and that’s fine. I hope containers never come to the BSD family. Most public images are gross and massive security concerns.
But then, most people who use FreeBSD know you don’t need containers to run multiple software stacks on the same OS, regardless of needing multiple runtimes or library versions. This is a lost art because today you just go “docker compose up” and walk away because everything is taken care of for you… right? Guys? Everything is secure now, right?
The command you most likely used is freebsd-update[0]. There are other ways to update FreeBSD versions, but this is a well documented and commonly used one.
> I don’t recall having to reboot — might have needed to.
Updating across major versions requires a reboot. Nothing wrong with that, just clarifying is all.
> Most people who use containers a lot won’t find a home in FreeBSD, and that’s fine. I hope containers never come to the BSD family.
Strictly speaking, Linux containers are not needed in FreeBSD as jails provide similar functionality (better IMHO, but I am very biased towards FreeBSD). My preferred way to manage jails is with ezjail[1] FWIW.
> But then, most people who use FreeBSD know you don’t need containers to run multiple software stacks on the same OS, regardless of needing multiple runtimes or library versions.
I completely agree!
0 - https://docs.freebsd.org/en/books/handbook/cutting-edge/
And yes, jails are way better, but here we are.
I used (and pushed) it everywhere I could and first encountered on Solaris before FBSD. Even had it on my Mac workstation almost 18 years ago (unsupported) -- aside I will never forgive that asshole Larry Ellison for killing OpenSolaris. NEVER.
Systemd is the worst PoS every written. RCs are effective and elegant. Systemd is reason enough to avoid Linux but I still hold my nose and use it because I have to.
There's pretty much nothing I can't do on FreeBSD that I would get with one Linux or another. Not much of a gamer so maybe that factors in..
This is especially true compared to how beautifully well and consistently the BSDs tend to document their init and configuration systems. Or Mac OS, again—launchd is still way easier to use and far more of a "fire and forget" system without adding complicated interfaces for unrelated stuff like network interfaces and logging. But that has always been true as well.
I love the simplicity of RC scripts. Easy to understand, easy to debug, it just fucking works.
Simplicity is king, because it's understandable. A behemoth like systemd feels like it requires a PhD.
Systemd also runs 100% against the Unix/Linux philosophy of composability and single purpose.
You’re handwaving away something that is pretty important. You can say that having 500 services is its own problem but it’s also a reality, even on desktop operating systems.
So go and count all the services that are not base install and tell me how many you have.
Linux is "just" the kernel and every distro invites new solutions to perceived core problems whereas the BSDs have a whole base system that comes from one source, reducing the chance of a systemd popping up there. Both approaches have their ups and downs.
Something I love with systemd is how I can get very useful stats about a running process, e.g. uptime, cumulated disk & network IOs, current & peak mem usage, etc.
Also the process management (e.g. restart rules & dependency chain) is pretty nice as well.
Is that doable with RC (or other BSD-specific tooling) as well?
In terms of uptime or IO and stuff, those metrics are already available. Be that via SNMP or other means. Say you start an nginx in systems, which network and disk usage does it report? Just the main process or all its forks? Same problem in RC.
But that is part of the point. Why in the ever-loving existence should an INIT system provide stats like disk usage? That is NOT what an init system is for.
If you need memory usage or IO usage or uptime, there are so many other tools already integrated into the system that the init system doesn't need to bother.
Init systems should only care about starting, stopping and restarting services. Period. The moment they do more than that, they failed at their core job.
This might came across stronger than meant to, but still holds true.
BSDs are about "keep it simple, keep it single purpose" to a "I can live with that degree". What you get though is outstanding documentation and every component is easily understandable. Prime examples are OpenBSD/FreeBSD PF. That firewall config is just easy to grok, easy to read up on and does 99.999% of what you ever need out of a firewall.
Well, the main process and its whole hierarchy, that's what you would expect of an init system monitoring its services, right? And what's nice with systemd is that I can get that from a simple `systemctl status my-service` – of course I could deploy a whole observability stack, but better if I can avoid it.
But there is no need to be defensive, it RC can that's nice, if it can't, then well, too bad.
> there are so many other tools already integrated into the system that the init system doesn't need to bother.
That's what I'd love to hear about, what are the equivalent in the BSDs world.
Or you just grab the PID and get it through that. A bit more manual, but composable.
Ditch the LLMs (not insinuating that you use them, but just in case), try to use the Handbooks and the man pages.
If you ever feel the need that you have so many interdependent services that you need something more complex than RC, then you might have an actual architectural problem to be honest.
Bang on.
In reality systemd is 69 different binaries (only one of which runs as pid 1), all developed under the same project, designed to work together.
They’re designed to work together but as far as I am aware there’s no reason you couldn’t replace individual binaries with different ones, though admittedly I have never done that.
Linux is a monolith that includes a bunch of drivers for things you will never need (on a typical distro, not when you compile your own kernel). It does way more than I need it to, and it most definitely does more than one thing. But of course that's ok in that case
Small, well integrated base system, with excellent documentation. Jails, ZFS, pf, bhyve, Dtrace are very well integrated with eachother, which differs from linux where sure there's docker, btrfs, iptables, bpftrace and several different hypervisors to choose from, but they all come from different sources and so they don't play together as neatly.
The ports tree is very nice for when you need to build things with custom options.
The system is simple and easy to understand if you're a seasoned unix-like user. Linux distros keep changing, and I don't have the time to keep up. I have more than 2 decades of experience daily driving linux at this point, and about 3 years total daily driving FreeBSD. And yet, the last time I had a distro install shit itself(pop os), I had no idea how to fix it, due to the rube-goldberg machine of systemd, dbus, polkit, wayland AND X, etc etc that sits underneath the easy to use GUI(which was not working). On boot I was dropped into a root shell with some confusing systemd error message. The boot log was full of crazy messages from daemons I hadn't even heard of before. I was completely lost. On modern Linux distros, my significant experience is effectively useless. On FreeBSD, it remains useful.
Second, when it comes to OpenBSD, I don't actually agree that security is its main selling point. For me, the main selling point of OpenBSD is as a batteries included server/router OS, again extremely well documented in manpages, and it has all the basic network daemons installed, you just enable them. They have very simple configuration files where often all you need is a single digit number of lines, and the config files have their own manpages explaining everything. For use cases like "I just want an HTTP server to serve some static content", "I just want a router with dhcpd and a firewall", etc, OpenBSD is golden.