A few years ago, I found myself looking for a new OS for day-to-day use. I'd been using Mac OS X for several years because my employer provided a MacBook Pro and I really loved the nice, clean Aqua UI on top of a POSIX compliant core. However, I was setting up a desktop, didn't want to spend a fortune on Apple hardware, and wasn't sure I liked the direction Apple was heading with OS X by making it more like iOS. My requirements pretty much boiled down to security (including support for full-disk encryption), stability, flexibility, software freedom, and a thriving community for those inevitable times when I would need some wisdom. If you're reading this blog, I probably don't need to tell you why Windows was ruled out before the competition started.
I had years of experience with Linux, but it had been long enough since I used it for a desktop OS that I was able to justify taking a fresh look at the leading distros. I compared the "market leaders" at the time including Red Hat, Ubuntu/Kubuntu, Mint, Debian, and others. I had almost settled on the old classic, Debian, when I saw that it now supported 2 kernels: Linux and kFreeBSD. Since OS X also had BSD roots, I decided to research it a little. Why was Debian bothering to support another kernel? Why had NeXT chosen to use BSD code for what later became OS X? In my research, I found that many other companies had chosen to use BSD code or BSD in whole either for their servers or as a base for their products including The Apache Software Foundation, Netflix, Juniper, NetApp, Sony (for the PS3 and PS4), and Experts Exchange. Among the BSD information I read was Matt Fuller's BSD for Linux Users, which is a great read that caught my attention right off the bat with this common BSD adage:
BSD is what you get when a bunch of Unix hackers sit down to try to port a Unix system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a Unix system for the PC.
The goal of Linux was to provide a kernel for the GNU Project that was attempting to create a free Unix-like environment for the PC. While it has done an excellent job of achieving that goal and I have much admiration for it, why not use a true Unix descendent if it's available? Linus Torvalds even stated that he probably never would have created Linux if 386BSD, the precursor to modern *BSD projects, was publicly available at the time (it was released a year later).
I had enough incentive to try BSD at that point, but actually using it and getting to know it has reinforced that decision. It wouldn't be the right choice for everyone, of course (e.g., if you need drivers for a bleeding edge video card, are averse to being hands-on with your system, or aren't comfortable at a command line). I won't try to convince anyone to switch, but I'll describe some of my favorite FreeBSD features here in case it helps others decide whether it's right for them. You can find many of these features or something comparable on other platforms, but bringing them all together is one reason FreeBSD shines. They're all huge topics on their own, so this article will provide a high-level summary and many links to get more information.
ZFS
If you're an IT professional who's not using ZFS, it's probably only because you haven't tried it. The benefits and features are so numerous that this section almost outgrew the blog post, so I had to trim it down significantly. ZFS combines the filesystem and volume manager while bringing both into the 21st century. It was designed from the ground up with a focus on data integrity, growth/expansion, and truly astonishing flexibility. Every block and block pointer are checksummed on write so the data can be verified when it's read. It also provides native mirroring and RAID-Z capabilities without the need for RAID hardware, which allows faulty or corrupted data to be corrected if any data does not match its checksum. That's just a start on what ZFS can do, but verifiable data integrity is a great place to start when it comes to your filesystem.
ZFS uses zpools rather than drives (where a zpool can contain many drives) and datasets rather than partitions. Datasets can be added or removed at any time on any mount point without having to move/resize existing datasets the way you do with old-fashioned partitions. When you add a disk to a pool, the pool grows to include that space (with exceptions related to RAID configurations) and the datasets in the pool do not need to be resized. Each dataset has its own set of properties that allow you to customize the behavior of reads/writes for it. Tired of compressing files to save space? Enable compression on a dataset and let ZFS take care of it automatically each time a file is written. You can choose from a handful of compression algorithms to suit your needs including the newest addition, LZ4, that can determine on-the-fly whether it's worthwhile to compress a file at all and leave it uncompressed if there isn't sufficient benefit. Another way to save space is to enable deduplication, which requires a lot of RAM but prevents duplication at the block level. You can also configure per-dataset, per-user, and per-group quotas.
ZFS allows the creation of snapshots to preserve the state of a dataset at any given point in time. Creation or deletion of a snapshot is a "cheap" operation, so it makes sense to leverage them any time you make potentially dangerous changes such as installing a new software package. Since ZFS is a copy-on-write filesystem, a file that's modified after a snapshot is created will be written to new blocks on the disk, the block pointers for the dataset are updated to point to the new locations, and the snapshot continues to point to the old blocks rather than freeing them as would normally occur with copy-on-write. This means creation of a snapshot doesn't require copying the current files at all and the space required for a snapshot is negligible at first with growth dependent upon the files that are created or modified afterward. Of course, the entire point of snapshots is that you can easily roll back the entire dataset or an individual file at any time.
Disk Encryption
There are multiple commonly used disk encryption solutions for FreeBSD. Both gbde and geli act as a layer between the disk and the filesystem encrypting data as it's written and decrypting as it's read. Private Encrypted File System, or PEFS, sits on top of the filesystem encrypting data before it's sent to the filesystem to be written to disk. While you might choose gbde or geli for full-disk encryption, PEFS would be used to encrypt users' home directories or any other directory where privacy is a concern. To visualize the data flow, writing to disk would take the following path (and reading takes the reverse, of course): file contents -> PEFS encryption -> UFS/ZFS -> gbde/geli encryption -> physical disk. You can use either full-disk encryption or PEFS, but you can also use them in combination to provide layers of security that fit a wide range of environments and use cases.
Wholly-Owned Base System
The idea of a base system isn't unique to FreeBSD, but the approach reflects its Unix heritage with everything on it being owned and managed by the FreeBSD project. The base system doesn't include as many components as Windows, such as a desktop UI, but solely what you need to get up and running so you can install the software you need for your purposes. It's a complete multi-user Unix environment right out of the box. Contrast that to most Linux distributions where a fresh installation has the Linux kernel, which is solely what makes it Linux, and numerous components from other projects added by the distro publisher. Many of the userland tools/utilities for common Linux distros come from the GNU Project. Past that, the components of a Linux base system could be managed by many different upstream vendors.
What makes FreeBSD's wholly-owned base system great? Besides just "feeling right," there's an inherent stability to it. It's the foundation upon which everything else is built, and it's engineered to be as reliable as possible. The userland utilities installed on any given FreeBSD system were part of the release cycle for that version of FreeBSD. They go through the same QA cycles and security audits. When an update is available for any part of the base system, it comes directly from the FreeBSD project as an OS patch. The freebsd-update utility enables you to easily update every component of the base system or even perform in-place upgrades to new minor or major OS versions. If you install 3rd-party software that results in a system problem, you can remove it and expect your base system to continue to work reliably.
Ports and Packages
What about software that isn't part of the base system? Any software created and maintained by a third party is considered a port. The FreeBSD ports collection is comprised of over 24,000 applications and libraries that have been verified to work on FreeBSD. It's like an "app store" in the sense that it brings everything together in one convenient location except that all of the apps are open source. Although you could download source code directly from the publisher's site and expect it to work in many cases, using ports has many benefits including automatic management of build/runtime dependencies, easy updating of every piece of installed software, and proper file placement during installation. FreeBSD's file system is very organized: e.g., /etc contains configuration files for the base system and /usr/local/etc contains config files for 3rd-party software. While the same may be true for many Linux distros, it boils down to whether the software respects the standards. With FreeBSD ports, those discrepancies are fixed as part of the porting process to foster a cleaner, easier to maintain system.
If you've ever built a large software project such as X, KDE, or even Firefox from source, you know how time consuming it can be. For that reason, FreeBSD also offers packages that are managed using the next generation package manager, pkgng. You could compare pkgng on FreeBSD to apt on Debian or yum on Red Hat. Packages are pre-compiled ports available for download, so you get the benefits of ports without the hassle of compiling the binaries yourself. The FreeBSD project compiles all ports (with very few exceptions) once per week to keep the packages up-to-date. Any software installed using ports or packages can be managed using the other tool, so you can mix compiling from source with binary installs as needed. For example, you might prefer the speed and ease of installing packages, but you could choose to compile a port yourself if you want to consume a patch for a known vulnerability before the package gets recompiled.
Jails
Unix and Linux are both known for their security, and FreeBSD lives up to that reputation. Regardless of inherent security, any system open to external access requires special consideration. FreeBSD provides jails as an elegant solution to exposing a service in a potentially dangerous environment such as a web server on the Internet. A jail is like a chroot on steroids where everything installed or running inside a jail only has access to the jailed file system, processes, users, groups, etc. It's similar to a virtual machine but with far less overhead since it shares the host's kernel and RAM. If a service such as a web server running inside a jail gets compromised, the attacker only gains access to the jailed environment. Even getting root inside the jail wouldn't allow the attacker to do any damage outside the jail. This makes recovering from a breach much simpler, because you can set up a new jail on the same host (possibly from a backup), reinstall the necessary components, and delete the compromised jail.
Support and Community
Most of the best support options for FreeBSD are made possible by the fact that the base system is entirely owned by the FreeBSD project. Notice a pattern for the links in this post? Many of them refer to the FreeBSD Handbook—a veritable treasure trove of information. It's a complete, in-depth manual for FreeBSD system administrators and users. More than once, I've embarrassed myself by spending too much time on something only to find that it was clearly detailed in the handbook. There are a variety of more specialized handbooks available online including one for system developers, software developers, porters, and more.
Aside from the wealth of documentation, FreeBSD also has an active community in the forums and on the mailing lists. Additionally, I use Atom/RSS to subscribe to the News Flash for release notifications and quarterly project status reports, Security Advisories and Errata Notices to stay on top of security updates, and the appropriate UPDATING feed for my system to remain aware of important changes related to ports. No discussion of the FreeBSD community would be complete without mentioning BSD Now, a weekly podcast filled with news, interviews, and tutorials related to BSD.
Licensing
The most well known open source license is probably the GPL, a copyleft license that requires derivative works to share their source under the same license. That's great for the open source movement, but it's not always a good fit for a company that wants to build upon the original work. With the BSD licenses, there are no restrictions placed on derivative works—including whether or not the source must be made available. Some might argue that it gives companies an unfair advantage to be able to leverage open source software without giving back, but history has shown that it doesn't generally happen like that. It's understandable for a company to keep their proprietary changes confidential, but using FreeBSD as their foundation means they have a vested interest in improving it. The result is that companies give back to the project through code and monetary contributions. While the goal of the GPL is to "keep software free," the goal of the BSD license is to "set software free" by allowing it to be used anywhere it can have an impact.
Summary
These are some of the major features that either convinced me to try FreeBSD or reinforced the decision to use it as my primary OS. I appreciate having the security and stability of a server OS on my desktop. It does everything I need and so much more that I've barely scratched the surface. The fact that FreeBSD has a Linux compatibility layer, Wine support, and a VirtualBox port are all icing on the cake. If you're on the fence about trying any *BSD, don't be afraid to release your inner daemon. If you decide to take the plunge (or already have), please share your thoughts in the comments below.
