(Review) Not-actually Linux distro review: FreeBSD 12.1-RELEASE

[Karlston]

Not-actually Linux distro review: FreeBSD 12.1-RELEASE

Does the power to serve include serving up desktops? Let's find out.

Enlarge / We could have used one of these FreeBSD stress balls while trying to get a desktop running.

FAndrey / Flickr

170 with 89 posters participating, including story author

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

First image of article image gallery. Please visit the source link to see all 4 images.

 

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

First image of article image gallery. Please visit the source link to see all 4 images.

 

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.

 

First image of article image gallery. Please visit the source link to see all 6 images.

 

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.

 

Initial FreeBSD configuration

First image of article image gallery. Please visit the source link to see all 3 images.

 

After FreeBSD finishes the base installation, the time has come for a little post-install configuration. Root password and network configuration are pretty obvious, although users who choose DHCP may be confused at being asked to select a DNS resolver anyway.

 

But then you get to the time zone selection, which brought back some unpleasant memories for me. First, you must choose your country or region—and "United States of America" sorts to 49th in the alphabetical list of choices, so my fellow Americans had better limber their finger up for lots of rapid down-arrowing.

 

After selecting your country, you're presented with a list of time zones contained in that country. Did you know that there are 10 different time zones that fall within "Eastern"? Well, FreeBSD is here to teach you—or at least expose you to the concept, while forcing you to find your own in a jaw-droppingly long list of regional variants.

 

First image of article image gallery. Please visit the source link to see all 3 images.

 

FreeBSD treats adding a user as an optional additional step during installation—but omitting it would be kind of criminal. If you say no here, root will be literally the only user on the system, and your friends will make fun of you.

 

Adding a user here is nowhere near as quick and simple as it should be. You'll need to answer a full two pages' worth of question-and-response dialog—and you should understand at least one FreeBSDism ahead of time.

 

Instead of using sudo to manage privilege escalation, FreeBSD uses the simpler su command to literally become root (or any other user). The catch is, only users who are in the wheel group are allowed to become root with su. When you create your user account here, be sure you also add it to the wheel group.

 

Once you've added a non-root user, you're ready to reboot into your FreeBSD system.

Will it desktop?

I can already hear the experienced FreeBSD fans grumbling here. "This isn't fair! FreeBSD's not for desktops, it's for servers!" I have bad news for you malcontents: the FreeBSD Foundation disagrees with you.

FreeBSD is one of the most popular BSD distributions. It is used on desktop, servers and embedded devices for more than two decades.

(That's Deb Goodkin, the executive director of the FreeBSD Foundation.)

 

FreeBSD is, however, much better at being a headless server distro than it is at providing a usable desktop. So please don't let the pain I'm documenting here convince you that you shouldn't use FreeBSD at all. Netflix uses FreeBSD to power its content-delivery network, which should tell you all you need to know about whether it can handle load in a reliable and maintainable way.

 

With all of that said, let's get back to the hilarious masochism involved in installing a FreeBSD desktop.

 

First image of article image gallery. Please visit the source link to see all 3 images.

 

Logging in to the system for the first time, the new FreeBSD user is presented with a Bourne shell. Note: Bourne is not Bash, and experienced Linux users will rapidly be frustrated at much of their muscle memory being useless or outright harmful at a FreeBSD Bourne prompt. Auto-completion features, whether tab or up-arrow, will not work the way you expect them to. Neither will the delete key, which just makes tildes now.

 

I already knew that pkg was the binary package management command for FreeBSD and that I wanted to install xorg, the modern version of the X11 display system. So the first thing I tried was pkg search xorg.

 

The pkg management system itself isn't installed yet on a new FreeBSD installation. Fortunately, the system at least knows what you want and asks if it should install pkg for you.

 

Once pkg is installed, pkg search xorg returns too many hits to fit on a single page of a text-mode console. Following up with pkg search xorg | less, we can see that there are tons of xorg-related packages, but there appears to be no package simply named xorg.

 

The apparent lack of a simple xorg package turns out to be a big, fat lie—if I had just typed pkg install xorg, it would have worked. But as I eventually discovered, pkg search doesn't return meta-packages. Yay.

 

First image of article image gallery. Please visit the source link to see all 5 images.

 

At this point, I gave up on yolo-ing my way through a desktop installation and hit the FreeBSD Handbook for advice. It recommended that I pkg install gnome3 and also warned me of some necessary configuration tweaks to get it to work.

 

First of all, you'll need to edit a /proc mount into /etc/fstab. This also means you'll need to know what editors are available—FreeBSD doesn't include nano or pico, so if you're not a vi fan the choice for normal humans is ee, the FreeBSD Easy Editor.

 

Once you've created a /proc mount according to the Handbook's instructions, you can manually mount it to save yourself a reboot, then pkg install gnome3.

 

I do not recommend you go grab a coffee at this point or even put on a pot. Instead, you should buy a small patch of land and grow your own coffee from scratch. Gnome3 is a 3GiB download, give or take, with a disturbing amount of it being extremely small .txz files.

 

Adding insult to injury, FreeBSD's package servers frequently dipped to 100KiB/s or less, even on large files. This was not a quick procedure, even by "download and install a desktop environment from scratch" standards.

 

Once Gnome3 is installed, you're still staring at a command prompt. Eventually, we'll want a desktop login manager, but for now, I tried startx on a whim. Nothing doing. Luckily, the banner message at the end of the gnome3 installation referred me to https://www.freebsd.org/gnome3 for instructions on starting Gnome3 and answers to common questions—so back to a working browser I went!

 

FreeBSD's Gnome documentation includes tips on enabling gnome3 (add gnome_enable=YES to /etc/rc.conf) and installing the Gnome Display Manager. Frustratingly, like every other bit of documentation so far, it doesn't say a peep about xorg—and installing gdm didn't bring xorg in as a dependency.

 

Finally, in frustration, I tried pkg install xorg, despite pkg search xorg having failed to find any such package. And it worked.

 

 

First image of article image gallery. Please visit the source link to see all 2 images.

 

On reboot, gdm loaded as it should, and I was presented with a graphical login prompt. Unfortunately, the mouse didn't work. Retreating to a system with a working browser, I found advice to set kern.evdev.rcpt_mask=6 in /etc/sysctl.conf. Well, OK.

 

What I should have done here was hit ctrl-alt-F2 to pull up a text-mode terminal in my working system and edit /etc/sysctl.conf from there. Unfortunately, what I chose to do instead was reboot and select single-user mode from the boot menu.

 

Rebooting into single-user mode worked but required suffering another frustrating round of paper cuts. The root filesystem was mounted readonly, so I couldn't edit /etc/sysctl.conf yet. No problem, just mount -o remount,rw / and—oh, wait, that doesn't work. Now what?

 

Eventually, I realized that FreeBSD's mount command didn't really understand my ZFS root filesystem. The correct answer was to zfs set readonly=off zroot/ROOT/default, after which I could ee /etc/sysctl.conf, change my evdev handling, and reboot once again.

 

First image of article image gallery. Please visit the source link to see all 4 images.

 

After changing evdev masking in /etc/sysctl.conf and rebooting once more, I finally had a graphical login and a working mouse, and I could log in. But wait—where's the launcher? FreeBSD's version of Gnome3 does not have a launcher visible on the main desktop; instead, you must click Applications in the global top menu bar. Presto, there's the missing launcher!

 

From there, clicking the obvious "this is Internet" icon gets you... Web. Welcome to Web. What in tarnation is "Web"? It's not particularly easy to find out—as far as I could tell, there's no About menu, and at this point, the system has thousands of installed packages. So I gave up on figuring out Web's taxonomy for the moment and browsed here to Ars.

 

The good news is, now I know what "Web" is—it's "GNOME Web by the FreeBSD GNOME Project." The bad news is, I know this because the attribution is on the crash page—and Web crashes at the drop of a hat.

More desktop problems

At this point, I installed Firefox from the pkg repositories. This was relatively uneventful, if painful, due to the slow speed—much of the browser package downloaded at an eye-watering 42KiB/sec. Once installed, it was Firefox, and it did not crash—even on relatively complex sites like YouTube. The Chromium browser is also available from pkg, but Google Chrome is a no-go.

 

At first, the sound on my FreeBSD system appeared to be broken—the Sound applet in Gnome3's settings showed /dev/dsp0 as a working, connected sound card, but clicking the speaker test buttons produced no actual audio. To my surprise, I got audio in YouTube videos anyway.

 

FreeBSD is also extremely sluggish to launch new graphical applications. This isn't a problem on the command line—it's specific to the desktop. It was a problem in the early 2000s when I first tried running X11Free86 on FreeBSD, and it's still a problem now with Xorg on FreeBSD. Even on a fast system, expect odd delays of 500-1500ms while the "wait" icon flickers in the global menu bar before new application windows render.

 

While there's much that can be said for FreeBSD as a server operating system, it's frankly pretty pants-on-head crazy to try to use it as a desktop daily driver. The desktop portions of FreeBSD are neglected, buggy, poorly documented, and underperformant.

 

FreeBSD downstream distros like GhostBSD (which we will review here soon) have fixed most, if not all, of these problems. But those fixes have not made it upstream into FreeBSD itself.

Conclusions

Desktop layer aside, the entire FreeBSD operating system doesn't seem to get as much developer love and attention as the typical mainstream Linux distribution. It doesn't take much use before you discover minor errors and paper cuts that really shouldn't exist—like pkg search not returning metapackages, or the disk partitioner not accepting its own example arguments as valid.

 

My personal biggest frustration with FreeBSD—and the major reason I switched from it to Linux in 2008—is the lack of automatic security upgrades. FreeBSD does have tools to discover vulnerabilities in packages and update them, but they aren't designed to run in the background. They demand either interactive operation by an active and knowledgeable admin or significant tooling that the FreeBSD operating system itself does not provide.

 

Worse yet, FreeBSD has at least two and often three entirely separate package systems to maintain. The source-based ports tree, the binary package system, and the base FreeBSD operating system itself—each uses entirely different tools for maintenance. If that's not bad enough, ports and packages actually conflict with one another, requiring even more care to make sure neither gets clobbered during upgrades.

 

 

Source: Not-actually Linux distro review: FreeBSD 12.1-RELEASE (Ars Technica)  

 

(To view the article's image galleries, please visit the above link)