I have mixed feelings about FreeBSD. Some stuff is genuinely good: major/minor release branches, the best ZFS experience you can get OOB, actual man pages, overall a lot "cleaner" than most Linux distros.
OTOH when you compare it to e.g. OpenBSD (or in many instances, even Linux), it's an actual mess. The default install leaves you browsing thru the handbook to get simple things to work; it has three (three!) distinct firewalls; the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file; even the tiny things such as some default sysctl value being an XML snippet - actually, WTF?
The desktop story is also pretty bad. OpenBSD asks you during installation, whether you'd like to use X11 - and that's it. You boot to XDM, you get a basic window manager, things like volume buttons just work, all in the base system - no packages, no config files. You can install Gnome or XFCE from there, and rest assured you'll always have a working fallback. FreeBSD still feels like 90's Linux in that area. Regarding usability, both are behind Linux in things like connecting to Wifi networks, but in OpenBSD's case you just save a list of SSIDs/passwords in a text file, and the kernel does the rest for you.
The author is praising jails. I think it's nice that you can trace the lineage all the way back to 6.x, it sings a song of stability. You can also put each jail on a separate ZFS dataset to get snapshot/restore, cloning, etc. But I think it's still a poor middle ground between OpenBSD and OCI. OpenBSD keeps making steps (privsep, pledge, unveil) to provide isolation, while remaining conceptually simple for the developer and imposing no extra maintenance burden on the operator. Containers by design are declarative, separate the system image from state, etc - it's a wholly different concept for someone used to e.g. managing stateful jails or VMs, but it reinforces what already were good design principles.
> the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file;
Isn't it just that /etc is the base OS and /usr/local is all packages added on top?
The base/packages split is one of the main reasons why I appreciate the BSDs (that includes macOS). However /usr/local/etc in particular violates several assumptions:
- I can make /usr read-only, exclude it from backups, put it on an NFS share, or otherwise treat it as immutable during normal operation;
- I can nuke /usr/local any time, fall back on the base system, and reinstall packages from there;
- I can put /etc in version control and track all configuration changes;
- I don't need to think whether to look for /etc/nginx or /usr/local/etc/nginx, this also simplifies automation like scripts or Ansible roles; etc
Notably, OpenBSD takes the effort to ensure all packages install their configs in /etc.
I don't think those first two are violated? I'm pretty sure you can make /usr read-only, mount it from a shared source, and nuke /usr/local at will. I do agree that splitting config files by base and not-base means there are two places, but given this particular system design it seems like a bad assumption rather than a bad design.
Symbolic links can be made, but test test test and make sure anyone else administering that host knows exactly what has been linked and why. Purists might scream, but its none of their business if it doesn't get in anyone else's way.
> the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file
I started with FreeBSD and it never was a problem to me until I started to use Linux too. Now I just make symlinks from /usr/local/etc to /etc for software I use both on Linux and FreeBSD. The rule is simple - if an app is from the base system it is in /etc and if you installed some software from packages (ports) then configs will be in /usr/local/etc.
FreeBSD is more of an admin's system than a user's system and this perfectly illustrates one of the reasons why. Outside of this forum, in regular consumer land, OS users don't want to know or care about the distinction between base and ports, and nothing anyone says about it is going to change that. So I run lots of BSD at home but I recommend Mint to family.
May be I'm biased but a distinction between base OS and 3rd party software is a simple concept to me, also it is not unique to BSD. E. g. in Windows there were different menu sections to install/uninstall optional Windows components and to uninstall 3rd party software.
If aynthing Linux is an outlier in that core OS components and 3rd party apps both come in similar packages which makes it hard to distinguish which is a part of the base OS and which and optional 3rd party software. In FreeBSD I know that I can delete all packages and still have a system remotely accessible via SSH (with rare exception a normal user will not come across). In Linux to tell which package can be uninstalled without breaking the system one have to be an expert. Can I delete iproute package if I don't use ip command, can I remove NetworkManager, is systemd-container optional? Where the OS stops and 3rd party apps start?
In regular consumer land, nobody is going to care that some config files are in /etc and others are in /usr/local/etc because a regular consumer has no idea what either one is, anyway.
I have had BSD as my router for a few years in the past and used Linux for a few decades but I never got this “BSD is cleaner” argument. Linux has man pages and Google gives you plenty more practical resources when in doubt and nothing felt unstable compared to “BSD is more tightly integrated” statement.
Lack of community resource such as documents, blogs, StackOverflow answers and docker ecosystem just drove me away from BSD as I lose nothing by using Linux. The only thing I miss could be OpenBSD’s pf.
Maybe "cleaner" really means "more uniform", compared to the wide variety of Linux distros and their incompatibilities? Or like the word "intuitive", really just means "what I'm used to".
More uniform most likely. With FreeBSD can google some issue you’re encountering and the solutions you find are likely to be applicable, even with differing hardware, OS version, etc.
With Linux there’s been many times I’ll google some problem and the only solution that turns up is for distro Y which is mostly or entirely irrelevant to distro X that I’m running at the moment. This happens even with the big mainstream distros like Ubuntu and Fedora, but of course it’s worse with more niche ones.
> I think it's nice that you can trace the lineage all the way back to 6.x
It's 4.0 actually - March 2000. For jails and kqueue.
> actual man pages
Let's start with: there is no such thing as "Linux" man pages. There's <https://docs.kernel.org> but that only concerns the kernel itself.
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.
> Let's start with: there is no such thing as "Linux" man pages. There's <https://docs.kernel.org> but that only concerns the kernel itself.
Actually, there is.
https://web.git.kernel.org/pub/scm/docs/man-pages/man-pages....
It's included with many default distro installs.
This is technically true, but this pretty much exactly illustrates my point. The SCM URL you've provided, you have to dig it up. It refers you to <https://man7.org/linux/man-pages/index.html>, which again, is a personal website of a member of the community. Then e.g. the fnctl(2) page comes from the 6.10 kernel release - AFAICT I can't browse the past releases or track HEAD. Compare with <https://man.openbsd.org> or <https://man.freebsd.org/cgi/man.cgi>, you can find both straight from the landing pages.
Meanwhile if you can't find man7.org (Google search results are only getting worse) and start browsing <https://docs.kernel.org>, it refers you to <https://www.kernel.org/doc/man-pages/> which refers you to <https://www.kernel.org/doc/man-pages/maintaining.html>, <https://www.kernel.org/doc/man-pages/missing_pages.html>, and Wikipedia - none of which seem to be relevant, can't tell because it's a wall of text rather than a man page browser.
Now imagine you have to fix a b0rked system that can't display its own man pages. You're now stuck with this mess.