FreeBSD keeps its kernel, system libraries, base commands and documentation in a single source tree, under one licence derived from Berkeley’s. The stable series is 4.8, out on 3 April 2003 for the i386 and alpha architectures; 5.x, opened by 5.0 on 19 January 2003, is the development branch. What I care about here is the practical consequences of the “single system” model, not a performance comparison.

Context

FreeBSD descends from 4.4BSD-Lite, the last code distribution from the Computer Systems Research Group at the University of California, Berkeley. From that base the project keeps together three things that many other free systems keep apart: the kernel, the userland (the libraries and commands that make up the system environment) and the documentation, made of man pages and a Handbook that lives in the same repository.

The whole distance from the Linux model lies here. Linux is a kernel; what a user installs is a distribution, that is, a kernel around which a vendor assembles the C library, the shell, the base commands, a package system and the documentation, each taken from a different project with its own release cycle and its own licence. In FreeBSD that integration work is already done upstream: the /usr/src tree holds the whole system, and make world rebuilds it as one coherent product.

The architecture of the base system

The boundary FreeBSD draws runs between the base system and ports. The base system is what sits in the source tree: kernel, libc, the commands in /bin and /usr/bin, the essential daemons, the default configuration files. Everything else — a web server, a Perl interpreter, a desktop environment — is third-party software that arrives through the Ports Collection.

The Ports Collection is a tree of directories under /usr/ports. A port does not hold the application source: it holds a Makefile with instructions to fetch it, any patches, the list of dependencies and the build options. A make install in that directory downloads the original source, applies the patches, resolves dependencies recursively and installs the result, registering it in the package database. The collection gathers several thousand applications maintained this way.

The separation is plain at the first update. Updating the base system (cvsup the sources, then make buildworld / make installworld) and updating the installed applications (portupgrade, or rebuilding the ports by hand) are two distinct procedures, on independent schedules. The base system advances conservatively; the ports follow the pace of their upstream projects.

The critical point: one licence, and what it grants

FreeBSD ships under the BSD licence. In its present form it asks only that the copyright notice and the disclaimer of warranty be kept; it does not require publishing modifications, nor adopting the same licence for derived software. Anyone who takes base-system code and puts it into a proprietary product can do so without having to release the source.

That is the underlying difference from the GNU General Public Licence, which governs the Linux kernel and much of the GNU userland. The GPL requires that derivative works, if distributed, be made available under the same licence and with their source code. These are two deliberate and legitimate choices: the GPL secures reciprocity — whoever extends the code returns the extensions — the BSD licence secures the widest freedom of downstream reuse, at the price of not guaranteeing that return.

You see it in products that incorporate BSD-derived stacks without exposing their own source. The best-known case is Berkeley’s TCP/IP stack, reused in many commercial systems through the 1980s and 1990s: the same code ended up, under BSD terms, inside proprietary systems from different vendors.

Isolation: jails as a coherent extension

With a single system you can build mechanisms that act on the whole environment, not on the single program. Jails, which arrived with 4.0 on 14 March 2000, are the example. A jail closes a group of processes into a partial view of the system: its own filesystem root, its own set of users, its own network address, with no way to see or touch what lies outside.

Compared with chroot, which limits only the filesystem view and leaves the process its other channels into the kernel, a jail extends the confinement to the process list, the network interfaces and the privileged operations. The design is described in the work by Poul-Henning Kamp and Robert Watson presented at the SANE 2000 conference: the subtitle — confining the omnipotent root — states the goal precisely, to make root powerful only inside its own enclosure. The mechanism holds because the kernel and the userland grow together: the utilities that create and manage jails sit in the same tree as the kernel that implements them.

Operational implications

For those running servers, little changes from one installation to the next. Two FreeBSD machines at the same release have the same base system, the same paths, the same reference documentation. Knowledge transfers predictably, and a procedure written for one machine holds for the others too. The documentation, kept in the same repository as the code, tends to stay aligned with the versions of the system it describes.

The 5.x branch also shows the cost of the model. Rewriting multiprocessor support with fine-grained locking in the kernel (the work known as SMPng) and introducing the GEOM framework for the block I/O layer are changes that touch the whole system, and so they proceed in a separate branch while 4.x stays the conservative choice in production. Keeping kernel and userland together gives the integration its coherence, but it means that deep changes are paid for across the whole tree at once.

Limits

This note describes a distribution and licensing model; it does not measure performance: talking about behaviour under load would require a test bench and numbers of one’s own. The comparison with Linux concerns the organisation of code and licences, not a verdict between the two systems. The BSD licence is not better than the GPL in the abstract: it strikes a different bargain, and the choice depends on what one wants to guarantee downstream. The versions and dates hold as of writing; the 4.x and 5.x series are both evolving.

Cover image: The BSD Daemon, a red devil-like mascot holding a trident and wearing sneakers, the FreeBSD mascot — illustration by Khaled, public domain — https://commons.wikimedia.org/wiki/File:Bsd_Daemon.svg