BSD: The Other Free UNIX Family

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. Berkeley Software Distribution (BSD) has grown into almost a complete replacement for UNIX, with numerous enhancements. David Chisnall explains why the BSD family has found its way into a large number of systems and what these systems can do for you.

Like this article? We recommend

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.