While I can see where both kernel and userland being built by a single team can have advantages, why is it necessarily the Linux approach to bolting the userland items as needed necessarily a bad thing? If a fictitious userland app such as `hnget` doesn't have good documentation is that a weakness of the linux distro or the makers of `hnget`? Sure, having one team brings the opportunity to leverage peer pressure to improve documentation or even to impose a "system level of docs quality".... but is it really so bad in Linux-land?

But with that being said, what I love about FreeBSD is that the core utilities are very well documented. I believe the quality of FreeBSD's documentation is an artifact of the BSDs long-standing culture of providing high-quality documentation; some of the man pages have origins in AT&T Unix and the days of BSD up to 4.4BSD, but it's been updated over all these years to reflect changes. The AT&T Unix versions and the Berkeley-developed BSDs always had wonderful documentation, much of it written by Unix legends like Ken Thompson, Dennis Ritchie, Bill Joy, Marshall Kirk McKusick, and others. Even the post-Berkeley documentation still captures this spirit. Plus, I happen to prefer man pages to the info pages that GNU utilities tend to prefer since I can never remember the keys used for navigating the hyperlinks found in info pages. I also like how FreeBSD ships with some traditional supplementary Unix documents, which have helpful tutorials for classic Unix tools. The FreeBSD handbook is very well written, and it can be easily downloaded. For people who sometimes need to do kernel hacking, there's Marshall Kirk McKusick et al.'s wonderfully written "The Design and Implementation of the FreeBSD Operating System, Second Edition," which I have a copy of. I find the source code of FreeBSD easier to read than the source code of Linux.

FreeBSD reminds me a lot of PostgreSQL, another high-quality open source project with excellent documentation that happens to also derive from UC Berkeley.

Linux land can certainly be bad in the sense that many distributors don’t document the system. They just bolt stuff together, sometimes with multiple layers of bolting (Distro X is based on Ubuntu that’s based on Debian, so which method am I “supposed to” use? If I use this new shiny package manager front end, will that interfere with the old command-line tool that works on Debian?)

For this reason I shy away from derivative distributions. But even then, the Linux user land and kernel are not models of superior documentation.

As an example, OpenBSD gives you a HTTP server, load balancer, and firewall right out of the box – and they all make use of pledge(2) and privsep and other security designs in a very consistent manner. And the documentation for the whole system is top-notch: you can read their manpages and not have to resort to Googling things.

I'd recommend you spin up OpenBSD on a VPC (try Vultr or DigitalOcean) and kick it around.

That's a blessing and a curse. While the BSD approach leads to more consistency, the Linux approach allows the ecosystem to move faster. In BSD projects, progress is often hampered, because proposals to drastically change subsystems is met with inertia, and then nothing happens. In Linux the inertia is there, but nobody stops people from implementing an alternative implementation, because the pieces are relatively decoupled, and then convince distributions to adopt the replacement.

This is why Linux ecosystem went from System V init -> Upstart -> systemd. Similarly, X11 -> Mir/Wayland -> Wayland (although Wayland could be adopted as a default on BSDs as well). Or chroot -> LXC -> Docker (or more generally cgroups + user namespaces). Although controversial (every change leads to some controversy), technically systemd and Wayland are substantial improvements to their predecessors.

Of course, the downside is that the integration is left to the distributors and the documentation may be inconsistent or uneven.

---

Another thing to take into accounts when looking at BSDs is that the BSDs have far fewer contributors than the Linux ecosystem. So, you might find that it lacks basic things such as 802.11ac support (though there has recently been movement in FreeBSD again) or support for the newest GPUs.

FreeBSD has noticeably higher performance, more packages, and is great for things like databases, virtualization, or application servers that are behind a load balancer or firewall. It has a lot of the OpenBSD applications ported to it though, so you can run pf or relayd on FreeBSD just fine. It's a bit more convenient to run FreeBSD for some things because of extensive packages (FreeBSD has things like C++ actor framework in packages, doesn't currently compile on OpenBSD). The jetbrains IDEs are better supported on FreeBSD than on OpenBSD too. (I've made some personal modifications to get things working on OpenBSD). Integrated ZFS is really nice for databases and storage servers as well.

I don't have much experience with NetBSD, but it is portable to all kinds of things (e.g. toasters), and they have done some neat things with rump kernels.

Dragonfly BSD has some cool experimental stuff with SMT and hammer filesystem, but I haven't played around with it much.

EDIT: A few nice things in comparing BSD to Linux. ZFS on FreeBSD is nicely integrated w/ the kernel. In general, I think solutions in BSD take longer to come around than Linux, but when they do they are well designed and thought through. Things just seem to fit better. From what I've observed, the community thinks things through and often recommend that someone use Linux if it would work better for the use case. That is a fantastic level of maturity; like when the hardware store guy recommends the competitor store down the street, because they will have what I need.

* Hardware support is great for me because I use a Thinkpad: most OBSD devs use Thinkpads as their laptops. I tried on a work-issued Dell and the driver support wasn't there + some odd kernel panics happened. Target "current generation - 1" and you'll likely have less to worry about.

* Expect performance to take a hit – every so often Chrome exhibits graphical tearing, slows down, etc. The pages I frequent don't tend to cause this issue, but if your browsing is JS to the max you might have some headaches.

* You'll find tons of packages, but should expect support to be lagging behind Linux. Just a function of adoption, really. Additionally, OBSD compiles some packages with security functionality that isn't present in other OSes, so expect a SIGABRT or two that you might otherwise not see.

Really though, it depends on your needs. It fits mine perfectly.

Force HW acceleration in Chromium (about:flags) and tweak a bit the /etc/login.conf (cap_mkdb /etc/login.conf as root after editing).

I’ll resist the fanboi post and just say the usual things you hear about BSD vs. Linux (good and bad) are true. Personally I appreciate the rock solid consistency (configuration, file system, runtime) I’ve gained from FreeBSD, but it’s not a commercially supported OS and there are times I’ve had to fall back to Linux (GOG games are one example).

Would you suggest FreeBSD for my use case? Or another BSD? Or something else altogether?

After some reflection, I think the number one reason I’ve stayed with FreeBSD all this time is it’s so dang stable and it just works. Historically speaking, I can’t think of anything radical ever happening since I’ve been using it. When it comes time to upgrade it’s been fairly painless which boils down to making a backup and running a couple commands (crossing your fingers is optional, but I think it helps).

TrueOS may be tempting but my experience with it was not very good. In fairness maybe it’s better now. I just use the vanilla release and chug along and won’t deviate again. No point.

But for you – not sure. I write code for my bread and butter and am steeped in technology – I most certainly have blinders regarding the complexity involved, but again, if you’ve been using Linux for 10 years this may not be an issue for you.

*Edited for ramble.

TrueOS development has been discontinued as of May (?) 2020.

Xfce is more than sufficient for my needs - I've been experimenting with TWMs, i3 most recently.

As a long term linux user, I'm well accustomed to spending exponentially more time working on the system rather than actually using it. As biologists, our computational skills tend to be middling, so dogfooding linux as my daily driver was a means to learn. If a BSD daily driver takes my learning up a notch, worth it. The top level comments reference to "elegance" and "well designed" is what struck me - these are not things I'd associate with any of the linux distros I've used.

edit: I think one of the most important and convenient things is to get a NAS or build a small fileserver. That way you can decouple most of your personal stuff from the systems you are using via NFS/SMB/CIFS and give a damn about interoperability of filesystems, thereby gaining the ability to try out what works best for you without much hassle.

The thing that gives me the most pause is how fractured the academic bioinformatics software scene is, and how poorly they're maintained once published. I've often run across requirements for GCC beyond what's included in the current Ubuntu LTS, for example. In my old lab I kept a CUDA workstation running the latest Manjaro for these eventualities, among others.

* no filesystem support for ext4 or btrfs

* no working adb package (at least not for USB)

* printing is hard to setup

* no rustup (you must use current to not fall behind the Rust community)

* no native Discord app, which means screenshare doesn't work (neither sending nor receiving). I can still do text and voice chat with Firefox.

That said, I have been using it as my daily driver for over a month now. Last time I tried it as a daily driver back in 2016 I had to switch back to Linux.

edit: I like NetBSD, but that meme is just non-sense.

My desktop machine runs OpenBSD (after getting off of OS X) but I have a few headless Linux machines for things that only run on it.

I also had to custom compile the pty4j and purejavacomm libraries to get the jetbrains IDEs to work to my satisfaction.