BSD: The Other Free UNIX Family

• By David Chisnall
• Jan 20, 2006

Like this article? We recommend
Design and Implementation of the FreeBSD Operating System, The

There are a lot of options in the Free UNIX market at the moment. Everyone’s favorite buzzword is Linux, and Sun is in the process of releasing Solaris under a Free Software license. One family, however, receives less attention than it is due.

On March 9, 1978, the University of California at Berkeley released a set of patches to the Sixth Edition of the UNIX Timesharing System. These patches were licensed very permissively—you could do pretty much anything with them, but you had to state that a product that used them did so. The advertising clause was later dropped, and any distribution in source or binary form was allowed, providing the copyright notice was retained.

The name of this patch set was the Berkeley Software Distribution—BSD for short—and it gradually grew into almost a complete replacement for UNIX, with numerous enhancements.

A few years later, the owners of the UNIX original copyright decided to try to cash in on their system’s success, and sued UCB. The upshot was a small number of files containing original UNIX code were rewritten, and a completely unencumbered version of BSD—UNIX being dropped from the name for trademark reasons.

In the early ’90s, Intel released a microprocessor that was capable of running a real operating system. The Intel 386 included features such as support for paged virtual memory, so it became a potential target for running BSD. In 1991, Bill Jolitz released 386 BSD and then neglected the project. A group of people, frustrated by the difficulty of getting patches accepted to 386 BSD, began distributing a patch set and then a complete system known as FreeBSD.

At about the same time, BSD Networking Release/2 (one of the last releases by UCB) was adopted by a group known as NetBSD. While the FreeBSD team focused on supporting the Intel 386, the NetBSD team was keen to retain the portable nature of the original BSD code.

In 1995, a clash of personalities lead to one of the NetBSD core developers, Theo De Raadt, forking the project and creating OpenBSD. OpenBSD, being based in Canada, was not subject to the stringent export laws that the USA placed on cryptography at the time, and so became a popular operating system among the security-conscious. This lead to a thorough code review, which found a large number of bugs and security holes in the code imported from NetBSD. This code review is an ongoing part of the OpenBSD development process and allows them to boast an excellent security record.

Over the years, BSD code has found its way into a large number of systems. Many commercial UNIX variants began as forks of BSD code, and a BSD TCP/IP stack was used in earlier versions of Windows. BSD was also very popular in academia. One project, the Mach Microkernel at CMU, used a modified version of BSD to run UNIX programs. The Mach project was used by a company called NeXT as the foundation for their operating system. When NeXT was bought by Apple, a lot of the old BSD code was replaced with code from the NetBSD and FreeBSD projects. Mac OS X can be thought of as a close cousin to the BSD family: Although it uses Mach as an abstraction layer, much of the kernel is BSD-derived.

It is worth noting that the BSDs are complete systems. Linux is just a kernel, and to be useful it is usually combined with the GNU userland. The BSDs include their own userland—although some parts, such as the compiler, are imported from the GNU project. A BSD system can be installed with no third-party applications—and work. It is more common, however, to add additional packages such as X.org and a desktop environment (the same applications traditionally run atop Linux).

The FreeBSD project underwent some radical changes between versions 4 and 5. Much of the kernel was redesigned to better support multiprocessor systems. One developer, Matt Dillon, was unhappy with the direction it was going, so he set up Dragonfly BSD, a fork of FreeBSD 4. While FreeBSD 5 and later use a system of shared resources and locks, Dragonfly BSD uses message passing between concurrent threads—a process common on microkernel operating systems including Amiga OS (where Matt Dillon first made a name for himself).

Dragonfly BSD is designed as a cluster operating system, and should be able to be installed on a cluster of machines, presenting the appearance of a single large multiprocessor machine to end users.

FreeBSD

FreeBSD is the most popular of the BSD family. It is traditionally known for stability and performance. Many web servers are still around running versions of FreeBSD from years ago without a reboot. FreeBSD is developed in three branches: -CURRENT, -STABLE, and -RELEASE. Anything new is added to -CURRENT, which may or may not work at any given time. Once a new feature has undergone testing by the development team, it is added to -STABLE. Periodically, a release is created. These releases have a version number and their own branch in the CVS tree. Only bug fixes are allowed to be introduced into -RELEASE branches—no new features. This makes tracking a -RELEASE branch the thing to do if you want a completely stable system.

FreeBSD development underwent something of a hiccup around version 5. The release schedule was feature-based, and a large number of new features were planned. Gradually, the release date for FreeBSD 5 slipped farther and farther back. During this time, the project moved to the same six-month release schedule as NetBSD and OpenBSD.

The current release version is 6.0, which is the system used on the laptop on which this article is being written. The 5.x series was highly ambitious and the lack of immediate success gave it a reputation for being unstable and slow—the lack of speed coming from the large quantities of debugging code found in releases.

The 6.x series is intended to avoid the stigma associated with the 5.x series. One of the most noticeable improvements is the new scheduler, known as ULE. ULE is not enabled by default because it does not achieve quite as good throughput as the traditional 4BSD scheduler, making it worse for server roles. For desktop (or laptop) use, it is much better. ULE prioritizes processes that spend most of their time waiting: interactive processes. On this somewhat aging laptop, it is possible to do a large compile in the background without any loss of responsiveness in X applications.

Installation of third-party software is done using the ports system. Each port is a Makefile, containing the files that must be downloaded to build the program and a set of patches to make it run on FreeBSD. The ports system will automatically resolve dependencies when installing programs.

Every port can be compiled into a binary package, and there are copies available from the FreeBSD FTP mirrors (although they often lag behind the port version by several days).

For the few closed-source programs that require Linux, FreeBSD includes a Linux ABI compatibility layer, which translates system call vectors into their equivalent on FreeBSD. It also includes a Linux-style /proc file system for programs that depend on it. Shared libraries used by Linux programs can also be installed—the ports tree contains copies of the basic packages found in several popular Linux distributions.

FreeBSD has a couple of features that make it attractive for home users. First, nVidia release graphics drivers for it, giving it the same level of 3D acceleration available to Linux on nVidia hardware. Second, it includes Project Evil, a reimplementation of the NDIS driver API used by wireless networking cards on Windows, allowing many WiFi cards to be used without direct hardware support.

Project Evil is also being ported to NetBSD, which also has Linux ABI support. Note that ABI support is not full emulation. All UNIX systems have a set of system calls—functions handled by the kernel—which are all assigned numbers. These numbers and the system call arguments vary depending on the kernel. The ABI compatibility layer simply remaps the arguments and changes the number, giving almost no performance penalty—in some cases, even faster performance than native due to a better kernel implementation. Linux is not the only non-native ABI supported by these systems—NetBSD even includes a rudimentary Darwin ABI that allows some OS X applications to run.