It seems FreeBSD is becoming more talked about in enthusiast communities simply because Linux is a lot more mainstream now and there’s a joy in contrarianism rather than any real changes with either of the two operating systems.
FreeBSD is also extremely conservative by comparison to Linux. It's not just systemd; things change less in general, and it's closer to old school Unix. Some people like it for nostalgia reasons, some just got tired of having rug constantly being pulled from under them (seems to be a common thing when people get older).
Dismissing the FreeBSD community as contrarians feels uncharitable. I can think of at least a few other contributing factors for the increase in popularity of late:
1) Linux's popularity has enlarged the pool of users interested in Unix-like operating systems. Some proportion of users familiar with Unix genuinely like FreeBSD and the unique features it offers.
2) The rise of docker and the implosion of VMWare has driven an increase of interest in FreeBSD Jails and the Bhyve hypervisor.
3) Running a homelab is a popular hobby. ZFS is popular for RAID, and pf is popular for networking.
My interest has been piqued of late. I've been a Linux enthusiast since the late 90's. I don't think it's a sense of contrarianism that motivates my interest anew.
As I've aged, what I've come to value most in software stacks is composability. I do not know if [Free]BSD restores that, but Linux feels like it has grown more complicated and less composable. I'm using this term loosely, but I'm mostly thinking of how one reasons and cognates about the way the system work in this instance. I want to work in a world where each tool on the OS's bench has a single straightforward man page, not swiss army knives where the authors/maintainers just kept throwing more "it can do this too" in to attract community.
I can’t speak for whole communities but my interest in FreeBSD has been renewed over the past couple of years. It has been a very solid OS for a long time and the tight integration between the kernel and core userland has meant that it is sometimes more performant than some popular Linux distros. But its UX has not always been amazing. Seems like lately they have really improved that. Plus ZFS and root on ZFS in particular is very nice.
I would actually be interested in running it in some production environments but it seems like that is pitted against the common deploy scenarios that involve Docker and while there is work on bringing runc to FreeBSD it is alpha stage at best currently.
Still, if you just want an ssh server, a file server, a mail server, it is a great OS with sane defaults and a predictable upgrade schedule.
For me it's all the changes in Linux. Every time I upgrade they change stuff that worked fine for me. Another issue is many distros pushing their "invented here" stuff like canonical and redhat. And the huge amount of corporate influence over Linux.
FreeBSD is largely free of those. And it leaves all the agency to the operator, rather than the distro forcing stuff down (except arch, but I don't like the community there)
Disagree. Linux has been gradually changing with the push towards systemd, snap, flatpak etc.. Today's FreeBSD resembles the Linux of 10 or 20 years ago a lot more than today's Linux does.
> Today's FreeBSD resembles the Linux of 10 or 20 years ago a lot more than today's Linux does.
I'm not sure that that's the win that you think it is. Linux 10 to 20 years ago was pretty terrible, at least on desktops.
Everyone hates on systemd, but honestly I really think that the complaints are extremely overblown. I've been using systemd based distros since around ~2012, and while I've had many issues with Linux in that time, I can't really say that any of them were caused by systemd. systemd is easy to use, journalctl is nice for looking at logs, and honestly most of the complaints I see about it boil down to "well what if...", what-if's that simply hasn't happened yet.
FreeBSD is cool, but when I run it I do sometimes kind of miss systemd, simply because systemd is easy. I know there was some interest in launchd in the FreeBSD world but I don't know how far that actually got or if it got any traction, but I really wish it would.
It is a bit of a bummer if you spend quite a bit of time tracking down a very weird DNS bug and it turns out to be systemd-resolved.
And I don't want to go into all of the time spend getting systemd unit files correct. There is very active community suggesting things you can add, which then of course breaks your release for users in unexpected ways. An enormous waste of time.
The OpenSSH/XZ exploit from a year or so ago was actually a systemd exploit[1], fun fact.
Looking back on the time I spent in systemd land, I don't miss it at all. My system always felt really opaque, because the mountain of understanding systemd seemed insurmountable. I had to remember so much, all the different levers required to drive the million things systemd orchestrated... and for very little effect. I really prefer transparency in my system, I don't want abstraction layers that I have no purpose for. I don't take it as a coincidence at all that since I moved away from systemd distributions, my system has become quite a bit more reliable. When I got my Steamdeck, the first systemd setup I've used in years, one of the first things I noticed is that the jank I used to experience has showed its face once again. It might not be directly tied to poetteringware, but it's very possible that this is a simple 2nd or 3rd order effect from having a more complex system.
Any sufficiently large codebase that runs an operating system will have security exploits eventually, so finding an example of this really doesn’t change anything. I am sure FreeBSD has had security issues in the past.
I am hardly a super genius and I really didn’t find systemd very hard at all to do most of the stuff I wanted. Everyone complains about it being complicated but an idiot like me has been able to figure out how to make my own services and timers and set the order of boot priorities and all that fun stuff. I really think people are exaggerating about the difficulty of it.
I think you misunderstand the issue being raised, hence your confusion. The "difficulty" isn't the individual facets of the system, but piercing the opaqueness of the entire picture without wholly specializing into it. On the very basis of using a configuration DSL loaded with strange quirks, the init system part of systemd alone is already asking to take up more space in your head than an init system reasonably should. Having to memorize a completely different set of string expansion behaviors, for example, and all the edge-cases that introduces at the boundary of shell scripts. One small example, and only of the tiny slice that is the init part of systemd. We can talk all day about the problems with resolved, udevd, logind, and so on.
None of these issues are "difficult" and perhaps that is why you think people are "exaggerating" and engaging in bad faith. I would challenge you on this and suggest you haven't seriously interrogated the idea that the standpoint against systemd has a firm basis in reality. Have you ever asked the question "Why?" and sought to produce an answer that frames the position in a reasonable light? Until you find that foundation, you won't understand the position.
> I'm not sure that that's the win that you think it is. Linux 10 to 20 years ago was pretty terrible, at least on desktops.
For all its usability issues, Linux 10 to 20 years ago had advantages that, for a certain kind of user, were worth the cost. Frankly Linux on the desktop today is the worst of all worlds - it doesn't have the ease-of-use or compatibility of Windows or OSX, but it doesn't have the control and consistency/reliability of BSD either.
I believe this is pretty unfair. Today's Linux on desktop is pretty straightforward for any normal user, given that there are no lines anymore between local and remote software. Windows shoves ads down your throat and MacOS make you pay a premium on HW which normal people spends on phones, not laptops or desktop computers anymore.
Most Ubuntu based distros let you just double click on the deb and just install the deb file. I don’t see how that’s appreciably different than Windows.
This page presupposes that the graphics tool to install .deb packages is not preinstalled, which isn't true for either Ubuntu nor Mint. If it is preinstalled the steps are really just "double click on it and then click install".
Same thing for RPM distros. So the only real catch is knowing which package to download.
FreeBSD users definitely seem to have taken over the mantle of OS evangelicals from Linux users.
I tried using FreeBSD for two different projects (NAS and router) and it turned out to be unsuitable for both, for each one switching to Linux solved the problem. Despite having solved my problems, the FreeBSD faithful seemed to think that using FreeBSD in itself was supposed to be the goal, not to solve the task at hand.
Well said! I used to administer both FreeBSD and Linux (Debian) servers at the same time. I found them different, but couldn't say either was better or worse.
There was always some truth to that, and there are worse reasons to find joy in actual competition. How do you discover the truth about differences in quality without fuel for curiosity?
That's fine. The thing is: I am different with Linux too. So I don't quite understand that FreeBSD focus.
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.
First of all, FreeBSD has plenty of selling points compared to your typical Linux distro:
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.
Out of the box ZFS is a big selling point for me. Jails are just lovely. The rc system is very easy to reason with. I've had systems that were only stable on freebsd that would crash using windows or various Linux.
ZFS is amazing and while there are many would be clones there is only one ZFS.
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.
It is unnecessarily complex to begin with. On top of that, the maintainers are historically not the most open to criticism and try to aggressively push the adoption. So much so that Gnome for example now has very strong dependecies on systemd which makes it very difficult to adopt Gnome on non-systemd systems unless you wanna throw a bunch of patches at it. This hard coupling alone is something that I wouldn't want to rely on, ever.
THIS. Also what problem does it solve that RC scripts can't accomplish? They are much more readable and less complex. What is the benefit of all that added complexity? Even more to the point the business case for it in a professional setting? I've been wondering that for a long time.
Barging in as a Linux guy interested to learn more about the BSDs, so please bear with me.
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?
It's up to you to say check in your init script if you need to start another service before you.
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.
> which network and disk usage does it report? Just the main process or all its forks? Same problem in RC.
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.
Spin up a VM, may that be locally or a cloud VM, throw an OpenBSD or a FreeBSD. If you are into mail servers, static http etc then OpenBSD might be your jam. Or try FreeBSD and Jails. Jails are absolutely fantastic.
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.
>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.
It autodiscovers the dependency chain or shit like that? If you got 500+ services that need to be orchestrated you honestly have a very different problem.
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.
If you need to make sure that the network stack starts after the usb stack and that starts after the pcie stack and that starts after the … then systemd is considerably easier than SysV init.
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.
Addendum to my other reply: it comes down to the "not invented here" problem which always invites weirdly complex solutions to problems that don't exist.
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.
I don’t see how they can be considered “one program to so many things” when it’s 69 different binaries. Yes they’re under the same project, but the same can be said about FreeBSD itself.
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.
I can't speak for others, but I find it poorly documented and only rarely improves on the systems it replaced, and it invalidates decades of high quality documentation that you can easily find on the internet. It's possible the transition will pay off one day with eg a usable graphic interfaces for system configuration that might compete with that of mac os, but as of yet, no such thing has materialized.
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.
Yes. Over the years I've used just about every linux distro from Slackware and RH up to nix + arch, as well programming on Solaris, IRIX, SCO, OS/400 and even Tandem --look it up it's pretty obscure! But I just use FreeBSD mostly now.
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..
I once upgraded a FreeBSD system from 8 to 12 with a single command. I don’t recall having to reboot — might have needed to.
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?
> I once upgraded a FreeBSD system from 8 to 12 with a single command.
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.
