Not-actually Linux distro review: FreeBSD 12.1-RELEASE

This month's Linux distro review isn't of a Linux distribution at all—instead, we're taking a look at FreeBSD, the original gangster of free Unix-like operating systems.

The first FreeBSD release was in 1993, but the operating system's roots go further back—considerably further back. FreeBSD started out in 1992 as a patch-release of Bill and Lynne Jolitz's 386BSD—but 386BSD itself came from the original Berkeley Software Distribution (BSD). BSD itself goes back to 1977—for reference, Linus Torvalds was only seven years old then.

Before we get started, I'd like to acknowledge something up front—our distro reviews include the desktop experience, and that is very much not FreeBSD's strength. FreeBSD is far, far better suited to running as a headless server than as a desktop! We're going to get a full desktop running on it anyway, because according to Lee Hutchinson, I hate myself—and also because we can't imagine readers wouldn't care about it.

FreeBSD does not provide a good desktop experience, to say the least. But if you're hankering for a BSD-based desktop, don't worry—we're already planning a followup review of GhostBSD, a desktop-focused BSD distribution.

BSD’s not Linux

Linux is, itself, just a kernel—you need a software distribution wrapped around it to make a complete operating system. By contrast, FreeBSD is and always has been a complete operating system—both the kernel and software ecosystem are managed and maintained by the same group of people.

In the past, this allowed FreeBSD to have a significantly more coherent layout than the typical Linux distribution. With a central committee overseeing design and maintenance of the entire OS as a whole, distinctions such as what goes in /bin, /usr/bin, and /usr/local/bin were more consistently and easily enforced.

With that said, the importance of this difference has eroded significantly over the last 20 years. Modern Linux distros tend to have large and very professional organizations behind them—it's difficult to see how the FreeBSD committee's oversight of FreeBSD as an entire operating system differs significantly from Canonical's oversight over Ubuntu or Red Hat's over CentOS and Fedora.

One thing that remains different between the two camps is the kernel license. The Linux kernel is licensed GPLv2, and the core Linux kernel developers can be notoriously cranky about potential violations of that license. FreeBSD's kernel, along with most code authored by the FreeBSD project, is licensed under the two-clause BSD license.

If you're not completely up to speed on open source licenses, we can sum up the difference in a nutshell—the GPL requires derivative code to also be licensed GPL, and the BSD license does not. The GPL also has a curious definition of what it means to be "derivative"—under the terms of the GPL, any code that links to GPL code is "derivative" and subject to compatible licensing requirements.

The ZFS filesystem is a famous example of the GPL's definition of "derivative" being turned on its head. ZFS was originally developed for Solaris and had been ported to FreeBSD before eventually getting ported to Linux. It is clear that ZFS isn't "derivative" of Linux in any normal usage of the word.

Since a kernel module must link to the kernel, any kernel module—regardless of its actual development history—is therefore a "derivative" work according to the GPL. This is controversial, and in practice, there are many outright proprietary kernel modules—such as Nvidia's proprietary binary driver module. Regardless, it's a sticking point for many kernel developers.

By contrast, the BSD 2-Clause license merely requires that any redistribution of BSD-licensed code must include the code's original copyright. This allows the reuse of BSD code within non-BSD-licensed projects, as well as vice versa. If you wanted to make ProprietaryBSD and sell it as a product with no user access or rights to the source code, the BSD license would permit you to do so—you'd simply need to acknowledge the BSD copyright when you did.

Installing FreeBSD

Installing FreeBSD has a distinctly old-school feel to it. The entire process is text-mode, like a Debian or an Ubuntu Server installation. That's not necessarily a bad thing; it means you've always got keyboard shortcuts, fast menu rendering, and you can defer potential hardware-driver issues until later, after the OS itself is installed.

For about a decade—1997-2007, give or take—I was a staunch FreeBSD user and strongly preferred it to Linux. Very little has changed about the installation process since then, although I don't remember a LiveCD environment.

Be warned, however, that the LiveCD environment is really only useful for operating system rescues—there's no desktop and very little pre-installed software. You're simply dropped at an "Amnesiac" login prompt. From there, you can login as root (with no password, though nothing gives you a hint about that) and get a plain shell.

Once you begin the actual installation, you'll choose a keyboard map, a hostname, and then any optional components to install.

Will it ZFS? You’re darn right it will

FreeBSD has supported the ZFS filesystem for longer than any operating system but its native Solaris. So of course I'm going to do a ZFS on root install here—and a proper one, on multiple disks, at that.

This didn't require me to dig into the manual partitioner, but I tried it anyway. You need to know what you're doing in FreeBSD's partitioner more than you do in most—for example, if you create a partition table with the "BSD Labels" scheme, you'll have accidentally consigned yourself to BSD "slices" rather than proper partitions, and no other operating system will be able to read your disks.

I also found a bug in the partitioner almost immediately—despite giving me "freebsd-zfs" as an example of a valid field to free-type into its Type: text box, it complained of an invalid argument when I tried it. You also can't simply cancel out of this dialog—the only way to get out was to free type "freebsd" instead, after which I could choose to nuke the whole partition table and go back to the guided installer.

The guided ZFS installer still has a few warts in it but no actual pitfalls. Organizing a full and potentially complex ZFS pool in a simple menued installer is not a trivial task. FreeBSD, unfortunately, doesn't get through the process without reinforcing some conceptual errors.

First and foremost, a pool is not made of disks—a pool is made of vdevs, and individual vdevs are in turn made of disks. Let's say you have 12 disks available to you—you might arrange them all in a single RAIDz2 vdev, with roughly 10 disks' worth of usable storage capacity and two disks' worth of parity. Or perhaps you'd choose a RAIDz3 vdev instead, with roughly nine disks' worth of capacity and three disks' worth of parity.

What escapes many users is that a pool does not have to consist of a single vdev. You might choose instead to have two six-disk-wide RAIDz2 vdevs in the pool, or four three-disk-wide RAIDz1 vdevs. More commonly, we see a pool of mirrors—in our 12-disk example, typically this would mean six two-disk-wide mirror vdevs.

The FreeBSD developers wanted to enable automatic provisioning of this common pool-of-mirrors scenario, but it broke their paradigm of selecting a virtual-device type. So they shrugged, ignored the conceptual error, and offered "raid10" as a "virtual-device type."

Selecting "raid10" here got me a pool of mirrors. It also made me cry a little on the inside.

Once you're done configuring your disk setup, there's one more minor wart to deal with on the way out. The main disk-configuration menu's bottom button isn't an OK—it's a Select. I took a confused second or three to realize that I needed to arrow all the way back up to the very top of the menu, highlight >>> Install, then go back and hit Select to proceed.