Why I run FreeBSD for my home servers (2024)

The main complain of the author seems to be that linux use systemd.

In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic (ex: when this and that happen, start doing this, except when such and such are present)

Most of the problems I've seen come from trying to duplicate systemd functions: in the author example, why bother with rsyslog or network-manager?

I have also seen many people refusing to learn modern tools, instead trying to make it work with the tools they know, by disabling what works better, often with poor results.

It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces).

I like the various BSD and distributions like postmarket OS, but I wish they had access to modern tools instead of having to "roll my own" with scripts or make do with what they depend on

99% of my issues with systemd are that it is a kitchen sink mentality. If it just dealt with process and service management, it'd mostly be minor quibbles - it was time to replace init with something.

But instead it also does NTP, DHCP/networking, logging, etc. There were some very annoying teething issues with a lot of these components. It became more difficult to isolate problems buried within the systemd stack. It also became a pain to do some common, basic tasks. When the first distros starting supporting it, getting the systemd/journald logs for all the services into a central logging service was extremely painful. With (r)syslog it is just one line in a config. Heck, even the config files for systemd are littered all over the place.

It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms.

And yes, by doing all this it the broke the long-held UNIX philosophy of "do one thing really well" and that continues to ruffle a lot of feathers. I've mainly accepted the fact that it won out, but it's helped by the fact that I'm now mostly using it to start a docker orchestrator and that all the networking is now handled by cloud-computing resources.

> There were some very annoying teething issues with a lot of these components

Currently, I don't have any issue at all, and I'm not aware of any either.

I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects

> It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms.

In retrospect, given how well it all works, maybe he was right to refuse to compromise.

> I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects.

Many people don't. When something more complex and integrated works it can seem perfectly fine. When something more complex and integrated fails, it often has more cascading effects that would otherwise be desired.

> In retrospect, given how well it all works, maybe he was right to refuse to compromise.

systemd's timesyncd is less accurate than ntpd and is terrible at dealing with drift; it is mostly only suitable for desktop timesyncing. As soon as you need to deal with synchronous timing with multiple machines, it's usually the number one problem. Even worse is that it doesn't tend to use less memory or cpu than alternatives.

systemd's DHCP client continues to be a nightmare for people using it with many ISPs or corporate networks due to the creators deciding to only handle one format of optional headers (in particular option 43, but also many others) resulting in networking issues in many situations. These issues are long-historical and can even be due to ancient endian issues. Every other DHCP client implementation deals with this - except systemd's. I have to cleanup my ec2 instances because systemd's dhcp client adds 032 instead of a space to resolv.conf's search field because we have more than one domain there.

In some cases these problems are because of long-established practices that technically violate an RFC. In others it's because they refuse to deal with more than one legit way of doing things. Either way, what is a service/process manager doing in this fight?

When you replace something that's been around for decades (init), you're going to ruffle feathers for good and bad reasons. It's had decades of maturity. But now one is going to do it for dozens of services and not appreciate or handle the nuances that come with such a responsibility? It's literally pure arrogance - hence the hate.

You make very good points, but I think they come from a difference in expectations.

For time sync, what you do depends on what you need: there's a long list of option: rdate, sntp, ntp, ptp and I have used all of them.

Even if rdate is technically obsolete, for embedded systems it's sufficient that the time is not grossly wrong (and it's faster to write a rdate client and server)

However, when I'm doing high precision sampling data with multiple computers and I have to reorder the observations, sub microsecond accuracy is not enough: then I use PTP with a GPS and PPS (or chrony with special NICs if I can't get a GPS signal)

Both of these are very far from the normal needs of linux installs: there is no one size fits all, there are even interesting inbetween (chrony doing hardware timestamping with ntp is very clever) but when you design a system, you have to make choices.

> But now one is going to do it for dozens of services and not appreciate or handle the nuances that come with such a responsibility? It's literally pure arrogance - hence the hate.

I'm very happy systemd exists, because I like the well thought out design it has created: I can feel how it's lacking in the BSD.

I understand systemd success was not a given, and choices had to made. I just don't think it was arrogance, but compromises needed to achieve a vision.

> it's because they refuse to deal with more than one legit way of doing things. Either way, what is a service/process manager doing in this fight?

It's making choices.

Maybe systemd could have used ntp or better (maybe it will? or maybe there's a reason it's a bad idea?) but it does most things extremely well: if I have very specific needs (ex: ptp) far outside the norm, I can concentrate on that and let systemd do everything else far better than I would.

> these problems are because of long-established practices that technically violate an RFC

For DHCP, you should suggest an update, and if it gets adopted, a patch to make systemd follow the updated RFC.

That would show some love, and it might be better (and more productive) than the hate

> Both of these are very far from the normal needs of linux installs: there is no one size fits all, there are even interesting inbetween (chrony doing hardware time-stamping with ntp is very clever) but when you design a system, you have to make choices.

There were choices/options, some of which have existed for decades. Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd. "NTP is enabled and provides time, so it gets started at this point in the dependency tree"...or "NTP with priority 1, chrony with priority 2 provide time, start NTP and if it fails, switch to chrony". This also means that systemd could lag if successor protocols for time syncing, etc take off.

Millisecond or less time syncing is not outside the norm for distributed tracing or other server-side tech stacks, especially if there's lots of traffic. I've been lucky in that AWS's modern underlying hardware seems to keep clock pretty well, meaning I've not had to personally fight with it (that and ubuntu already defaulted to chrony, doing the override work for me.), but I do know people doing on-prem kubernetes loads that have had to...

Swinging back to networking, the tight integration with systemd makes (made? I am only now starting to plan the upgrade of our ubuntu 20.04 fleet to 24.04, so maybe it is better now...) disabling components a huge pain in the ass. My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.

> For DHCP, you should suggest an update, and if it gets adopted, a patch to make systemd follow the updated RFC.

It's not mainly an issue with strict adherence to RFCs. There's quite bluntly real-world usage and industry norms.

Firstly RFCs can be vague and unclear. IPSEC is a notorious example in that vendors treat the IP restriction headers differently because the spec is nebulous to how precisely it should work (some call it a proxy-id or proxy-header, others subnet range, etc). Due to a variety of reasons that can be summed up as the consequences of committee driven design, a lot of the spec was defined with great "flexibility" in mind. Some vendors will not bring up the tunnel unless both ends agree on the ranges exactly. Others will happily bring up the tunnel, but only allow traffic that overlaps within the local restrictions. Even more infuriatingly, some vendors (cisco in particular) tie it to the firewall rules, which could include other non-vpn traffic. Some (like checkpoint) dynamically supernet the configured entries. The result is every person who's setup IPSEC VPN tunnels with third parties maintains a "quirks" record to understand how best to bring up tunnels between vendors (eg juniper srx to cisco ASA, juniper srx to palo alto, etc). You just cannot be stubborn here. You need to work with the way the real world works.

Secondly, there can be competing standards or necessary migration paths between them. I'm not sure what the IPv6 status is on systemd so this is only an example, but IPv6's autoconfiguration didn't initially include DNS and other optionally useful fields, meaning DHCPv6 was a thing. This is now mostly deprecated by SLAAC, but DHCPv6 deployments will be needed for awhile as it's all that windows' IPv6 implementation supported until recently. You can't just say "RFC now supports SLAAC...don't whine to me that DHCPv6 doesn't work as it's not part of the RFC".

> That would show some love, and it might be better (and more productive) than the hate

People have tried, but the response can be TL;DR'd to "works on my machine/setup" or to go harass AWS, Microsoft (via AD), etc to make things work the way the systemd mainainers think is right. There's a reason Lennart Poettering has a "difficult" reputation.