Why I run FreeBSD for my home servers (2024)

How does a particular distribution handle its man pages is up to that distribution. You can browse what is generally considered to be the "standard" set of man pages online: https://man7.org/linux/man-pages/> or https://linux.die.net/man/>, but this is a third-party community effort. I've often found minor discrepancies between those resources and what I actually found installed on my system.

Debian does an absolutely amazing job: every executable in every package has to come with a man page, and if there isn't one, the maintainers will at least write a synopsis. You can also read these man pages online: https://manpages.debian.org>; you get to browse by release, section, you even get translations. Some derivatives (e.g. Ubuntu) will provide their own online browser as well.

But this is where things start to get dicey. Most distributions make heavy use of GNU coreutils, glibc, GCC, etc. Some of these (like GCC) are complex, because the problem domain is complex. On the other hand, coreutils' level of unnecessary complexity is almost byzantine; to cope with that, the GNU project mostly abandoned man pages (these mostly just contain a synopsis) in favour of an in-house "info" system https://www.gnu.org/software/texinfo/manual/info-stnd/info-s...>, which is basically TeX https://tug.org> with layers on top.

But not all distros use GNU tools nowadays; e.g. Alpine (actually pretty popular, thanks to the Docker ecosystem) uses busybox and musl libc. However for some reason Alpine not only does not provide an online man page browser, but requires installing a meta-package to add the man pages to your system. The differences between GNU and busybox+musl are non-trivial (and not unlike GNU vs BSD).

You can blame the Linux ecosystem fragmentation, and you would be correct to point out there are three popular BSDs, each with its own goals and little quirks. My final point is about the quality of the documentation. Compare coreutils chmod(1) https://linux.die.net/man/1/chmod> and OpenBSD chmod(1) https://man.openbsd.org/chmod.1>. The former is a brief, dense, and intimidating wall of text that expects you to immediately grasp what "ugoa" or "rwxXst" stand for; you will only find out that the tool manages file access permissions once you dig through the third paragraph; the text concludes by referring you to "info coreutils aqchmod invocationaq". By contrast, OpenBSD's man page has a clear introduction, then paces you through explaining the basic; goes into detail over the octal and symbolic representations (with pretty tables); warns you about a common mistake; has several examples with explanations (including equivalences between octal and symbolic forms); and concludes by referring you to the POSIX standards.

Best of it, you can expect the same high standard of quality throughout the entire base system, from user commands to device drivers and kernel internals.

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.