Christian Weisgerber
May 12, 2000
In recent years the enormous public success of the Linux movement has overshadowed the availability of other equally powerful and freely available Unix operating systems. This paper aims to introduce BSD as an alternative to Linux, to provide basic information, and to clear commonly encountered misconceptions.
Everybody has heard of Linux by now. What's this "BSD" thing? BSD stands for Berkeley Software Distribution. Originally developed by the Computer Systems Research Group (CSRG) at the University of California at Berkeley (UCB), BSD started out in late 1977 as a kit of additional software and patches to AT&T's UNIX version 6, which back then ran on the PDP-11 minicomputer. A description of those early days of the Unix community can be found in Peter H. Salus' book A Quarter Century of UNIX[1]. From these humble beginnings, BSD evolved over the course of 15 years into a standalone Unix operating system.
BSD has been exceedingly influential on Unix at large. Many
features we nowadays take for granted were introduced on BSD and
only later adopted by AT&T and other vendors: the (in)famous
vi
(1) screen editor, the termcap
(5)
terminal capability database and the curses
(3) screen
manipulation library, csh
(1), job control, long file
names, symbolic links, TCP/IP networking, the socket
(2)
interface, various r*
utilities, ...
Eventually BSD was freed from the shackles of the AT&T UNIX source code license requirement as all the AT&T-copyrighted code was gradually replaced. In 1993, 4.4BSD was released as a complete open-source operating system. For a comprehensive history of BSD at the CSRG straight from the horse's mouth, people's motivations for their work, and the subsequent ugly legal battle with AT&T, I refer the interested reader to Kirk McKusick's paper "Twenty Years of Berkeley Unix"[2].
Today, BSD is a freely available, fully functional Unix operating system, whose detailed development history has become impossibly intricate[3]. Broadly speaking, it is technically equivalent to Linux, although less widely known.
Since the CSRG shut down, several modern derivates of 4.4BSD have appeared, some of them wedded to commercial products.
Berkeley Software Design, Inc., was formed by former CSRG developers after their funding ran out, in order to continue the development of BSD in a commercial setting. BSD/OS has been available for multiple platforms, in particular i386 and sparc, and has mostly been marketed for embedded Internet applications.
In spring of 2000, BSDI merged with Walnut Creek CDROM, previously the main financial backer of the FreeBSD project (see below). BSD/OS will be continued as a separate product, however it is expected that eventually the BSD/OS and FreeBSD source trees will be largely merged.
is the open-source centerpiece of Apple's new operating system Mac OS X. Darwin implements a 4.4BSD personality and user land on top of a Mach microkernel, with FreeBSD as the main reference. Although primarily aimed at Apple's own ppc platform, the system is also being ported to i386.
The rest of this paper will deal exclusively with those BSD distributions that are available as free software. Although these ship with a variety of GNU tools, in particular the tool chain (compiler, assembler, linker), all core functionality is made available under the BSD license:
Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
All advertising materials mentioning features or use of this software must display the following acknowledgement:This product includes software developed by the University of California, Berkeley and its contributors.
- Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Effective July 22, 1999, the third clause has been struck from the license requirements. Most post-Berkeley work now comes with an abbreviated license that abandons both the third and the fourth clauses. In particular, the BSD license allows the creation of derivative works that can be distributed in binary-only form.
has been optimized for the PC platform. This also includes easy installation and wide support for the veritable zoo of PC hardware. FreeBSD supports the i386 and alpha architectures, and interest in porting it to several other platforms has been expressed. FreeBSD enjoys the largest user base of all BSD distributions and powers the world's busiest WWW and FTP servers, www.yahoo.com and ftp.cdrom.com, respectively.
has a focus on clean design and portability. It supports more platforms than any other operating system. From small handhelds to large alpha servers, it runs on almost any machine anybody would want to use Unix on. At the latest count (early May) NetBSD had been ported to a total of 27 platforms utilizing ten different CPU families.
focuses on security and cryptography. The project split off from NetBSD in 1995 due to unsurmountable personal differences between Theo de Raadt and the rest of the NetBSD core team. At the time of writing, OpenBSD supported nine platforms (six CPU families), with several more under development or in the process of being resurrected. The OpenBSD team gained wide recognition with their creation of OpenSSH, a free implementation of the SSH suite of secure network connectivity tools.
So, how different are the three BSDs from each other? In practice, rather little. The degree of mutual difference is roughly comparable to that between separate Linux distributions, with the differences being smaller from a user and administrator's point of view, and larger in the internals. Although little advertised, there is a lot of code sharing between the individual projects, facilitated by the same licensing.
The three projects have extensive Web pages at
http://www.
project.org/
, with
basic information, FAQs and further documentation, archives of the
rich mailing list cultures, and hypertext interfaces to the respective
CVS trees. Releases of complete distributions can be downloaded
from the net or bought on CD.
Contrary to what some Linux advocates claim, BSD development does not follow a cathedral model. It is hierarchically organized but not in any way closed. There are three tiers:
Note that this "rank" is based on the work done for the project. Anybody can be contributor. Send in a patch that gets committed, even if it corrects merely a typo in a man page, and there you are. People who contribute a lot or show particular competence for an area of the project will be promoted to committers, if only to save other committers from having to check in their work all the time. Core team members finally have shown exceptional amounts of contributions and technical skills, as well as some social ones.
FreeBSD maintains two branches, -CURRENT for development and -STABLE, which sees only bug fixes or incremental improvements that have been well tested. About three or four times a year a -RELEASE is produced, typically from the -STABLE branch. In between releases, snapshots are made available. Other than differing naming conventions for the branches, NetBSD has the same approach. OpenBSD only has a single branch with biannual releases. Errata (patches) to a release are subsequently published until the next one; meanwhile the source tree is in active development.
The key difference between BSD and Linux can be summarized in a single term: integration, meaning both a process and the result of this process.
Each BSD distribution is considered a single project. Linux distributions on the other hand are combined from a multitude of separate projects, many of which aren't even Linux-specific. There is a Linux kernel project led by Linus Torvalds. There are toolchain and C library projects. There are a host of different GNU projects that provide various tool collections. And so on.
On BSD, the developers are also the integrators. If somebody
wanted to change the output of, say, ls -l
, he would
also feel responsible for taking care that any scripts in the system
that depend on a particular format for the ls
(1) output
would also be adapted. In the Linux world, the system integrators
who combine many different projects into a distribution are generally
not developers of those projects. The resulting system integration
of BSD is tighter. Man pages are more complete, programs interoperate
better, there is a more consistent look and feel to the system.
Some often mentioned differences between BSD and Linux are merely
the result of BSD's single project mindset: All of the base system
is contained in a single CVS
tree, i.e. all of it is under version control. From there, the
complete source tree can be checked out and re-compiled in one go.
This is generally known as make world
, from the single
command that can be used to rebuild the system. So far, no Linux
distribution has been able to provide its source in a CVS tree,
and in fact not even the Linux kernel is under proper version
control, resulting in a rather cumbersome (from a BSD perspective)
development process.
Another resulting difference is the clear demarcation between base system and additional software under BSD. Many Linux distributions now ship half a dozen CDs full of packages. There is little guidance which parts belong to the core system and which are optional, which have been rigorously tested and audited, and which were just added because the source was available on the net.
There is a wealth of Unix software freely available as source on the net. In fact, much of the software that is typically associated with Linux isn't specific to Linux at all, but can be built and run on any Unix system, including BSD. To facilitate the installation of this third-party software, BSD has the ports and packages system, which was originally introduced by FreeBSD. It has since been adopted in somewhat modified form by NetBSD and OpenBSD. (To avoid confusion with the "port" of the system to a different hardware platform, NetBSD has chosen to call ports "packages" and packages "pre-compiled packages". I'll stick with the FreeBSD terminology here.) At the time of writing, the software count supported by this framework was approximately 3300 for FreeBSD, 1300 for NetBSD, and 700 for OpenBSD. New ports are added daily.
A package is a piece of software, pre-compiled
to run. It is equivalent to the packages used by Linux distributions,
e.g. the popular RPM format. Technically, the distribution format
used for BSD packages is a compressed tar ball (.tgz
),
which includes the files to be installed plus some additional meta
information. For example, the contents of the FreeBSD
xlogout-1.1.tgz
package are these:
+CONTENTS +COMMENT +DESC +MTREE_DIRS man/man1/xlogout.1.gz bin/xlogout lib/X11/app-defaults/XLogout
Packages are installed into a configurable ${PREFIX}
,
defaulting to /usr/local
, /usr/X11R6
, or
/usr/pkg
(NetBSD). Installation is registered into a
database directory tree at /var/db/pkg/
package.
Package management is performed by a variety of pkg_*
tools, such as pkg_add
(1), pkg_delete
(1),
and pkg_info
(1).
A port is the framework from which a package
is created. Functionally, a port is equivalent to an SRPM, however,
it doesn't contain the actual source tarball. Writing a port is
equivalent to writing an RPM spec file. Ports are typically stored
as /usr/ports/
category/
port
(/usr/pkgsrc
on NetBSD). A port skeleton consists of a
small directory tree with several files. For transport purposes it
is put into an archive using tar
(1) or shar
(1).
Here is a trivial example, /usr/ports/x11/xlogout
from
FreeBSD:
xlogout/Makefile xlogout/files xlogout/files/md5 xlogout/patches xlogout/patches/patch-aa xlogout/pkg xlogout/pkg/COMMENT xlogout/pkg/DESCR xlogout/pkg/PLIST
BSD didn't create a new tool like rpm
(1) to build
ports, rather a make
(1)-based infrastructure was
introduced. The Makefile
is the key part of a port.
It mostly assigns values to a variety of variables and includes
some 2000..3000 lines of system makefile that contains all the
necessary magic to actually perform any actions. This
bsd.port.mk
file makes heavy use of the powerful
extensions in BSD make
(1), which are quite different
from those in GNU make
.
# New ports collection makefile for: xlogout # Date created: 1998-11-06 # Whom: Christian Weisgerber <naddy@mips.rhein-neckar.de> # # $FreeBSD: ports/x11/xlogout/Makefile,v 1.4 2000/04/30 18:36:54 knu Exp $ # PORTNAME= xlogout PORTVERSION= 1.1 CATEGORIES= x11 MASTER_SITES= ftp://ftp.tu-darmstadt.de/pub/X11/other/ EXTRACT_SUFX= .tar.Z MAINTAINER= naddy@mips.inka.de WRKSRC= ${WRKDIR}/xlogout USE_IMAKE= yes MAN1= xlogout.1 .include <bsd.port.mk>
Further files contain cryptographically secure checksums to verify that the distribution tarball is indeed the expected one, optional patches that may be required to adapt the target software to BSD and/or the ports system, both single-line and more verbose descriptions, and a list of files that will be installed by the port.
Actually building and installing a port is trivial:
# cd /usr/ports/x11/xlogout # make install clean
This will proceed to
configure
,Here's the log:
>> xlogout-1.1.tar.Z doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp2.de.freebsd.org/pub/FreeBSD/ports/distfiles/. Receiving xlogout-1.1.tar.Z (3466 bytes): 100% 3466 bytes transferred in 1.9 seconds (1.75 Kbytes/s) ===> Extracting for xlogout-1.1 >> Checksum OK for xlogout-1.1.tar.Z. ===> xlogout-1.1 depends on shared library: X11.6 - found ===> Patching for xlogout-1.1 ===> Applying FreeBSD patches for xlogout-1.1 ===> Configuring for xlogout-1.1 imake -DUseInstalled -I/usr/X11R6/lib/X11/config make Makefiles make includes make depend rm -f .depend gccmakedep -f- -- -I/usr/X11R6/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -- xlogout.c > .depend ===> Building for xlogout-1.1 cc -Os -pipe -I/usr/X11R6/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -c xlogout.c xlogout.c: In function `main': xlogout.c:52: warning: return type of `main' is not `int' rm -f xlogout cc -o xlogout -L/usr/X11R6/lib xlogout.o -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lxpg4 -Wl,-rpath,/usr/X11R6/lib /usr/X11R6/lib/libXaw.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() ===> Installing for xlogout-1.1 ===> xlogout-1.1 depends on shared library: X11.6 - found /usr/bin/install -c -s xlogout /usr/X11R6/bin/xlogout /usr/bin/install -c -m 0444 XLogout.ad /usr/X11R6/lib/X11/app-defaults/XLogout install in . done rm -f /usr/X11R6/man/man1/xlogout.1* /usr/bin/install -c -m 0444 xlogout.man /usr/X11R6/man/man1/xlogout.1 gzip -n /usr/X11R6/man/man1/xlogout.1 install.man in . done ===> Generating temporary packing list ===> Registering installation for xlogout-1.1 ===> Cleaning for XFree86-3.3.6 ===> Cleaning for xlogout-1.1
Subtargets are available to execute each step separately. An
installed port is indistinguishable from an installed package and
make package
will create just such a package from the
port.
Just how immensely useful the ports/packages system has proved
to be is also exemplified by the ongoing effort to make the NetBSD
package collection available on Solaris and Linux with the zoularis
[4] package.
Unix flavors differ most in the details of system administration. Like the other systems, BSD has its very own style.
To start out, BSD comes without any admin tool such as SMIT on
AIX, SAM on HP-UX, Linuxconf, or SuSE YaST, to name a few. Instead,
the configuration of the system is necessarily handled by editing
a variety of text files under /etc
. However, lots of
startup configuration options have been centralized in a single
/etc/rc.conf
file, e.g.
sendmail
, lpd,
ntp,
...A commented list of default options is provided and allows for easy customization.
Although all systems ship with a default kernel that supports a wide range of hardware and features out of the box, building a custom kernel is often preferred to remove unused drivers and thus save memory, or to add rarely used features. The procedure is straightforward:
/sys/arch/
arch/conf/
KERNEL
(FreeBSD: /sys/
arch/conf
).GENERIC
files which specify
the default shipping kernels. FreeBSD also has a LINT
file which includes all available options. Further
documentation is provided by the section 4 man pages.config
(8) and make
.The basic procedure is just the same as on Linux, although the details are quite different. For completeness sake I'll point out the BSD projects also support a varying degree of kernel modularization.
While we would all like to believe that our systems are perfect,
bugs do exist. Fortunately, BSD provides an easy and
professional way to report and track problems and user feedback.
Starting send-pr
(1) (OpenBSD: sendbug
)
will present a self-explanatory, easy to fill out form which can
then be sent by mail to the respective BSD project's central GNATS
bug tracking database. Of course the preferred bug reports, if
there is such a thing, are those that include a fix...
BSD has its own partition table format. On many platforms this
is the native format, but not on the PC. There BSD doesn't
directly use the IBM/Microsoft partition scheme like Linux does.
Instead, part of the disk has to be set aside for BSD. FreeBSD has
coined the term "slice" for this. Inside the BSD slice, the BSD
partitions are created. Note that this use of the terms "slice"
and "partition" is exactly the opposite to Sun's terminology. BSD
partitions are numbered a
to h
.
Traditionally, a
is the boot partition, b
swap, and c
is a pseudo-partition covering the whole
disk.
BSD's preferred native file system for local disks is FFS, the Berkeley Fast File System. It supports filesystems up to 16TB and, depending on some parameters, files up to several terabytes in size. 64-bit file offsets, i.e. files larger than 2GB, on 32-bit platforms have been supported since 4.4BSD (1993). BSD FFS and Linux ext2fs are generally very similar, which comes as no surprise considering that ext2fs was designed with FFS in mind.
One difference between FFS and ext2fs that draws a lot of attention are the defaults for a particular safety/performance trade-off. ext2fs defaults to writing metadata asynchronously, FFS to synchronously. Both file systems write normal data asynchronously. This gives ext2fs superior performance for operations involving metadata manipulations. ("Metadata" refers to all data not contained within the files themselves: directory information, inodes, block allocation maps, etc.) In degenerate cases, such as extracting a large number of small files from an archive, the difference is remarkable. On the other hand, asynchronous handling of metadata exposes ext2fs to a substantial risk in case of a system crash or power outage. The filesystem may end up in an inconsistent state, which can entail severe data loss including loss of the complete filesystem.
Of course it is possible to mount a filesystem async on BSD too,
however this is generally considered an unacceptable risk. For some
time now, a superior solution has evolved: soft
updates[5]. Ordered writes guarantee filesystem
consistency and performance is similar to that of asynchronous
metadata writing. The BSD implementation was done by Kirk McKusick,
the creator of FFS. It is still under a special license which
prevents it from being enabled by default, however it will eventually
be switched to the BSD license. No structural changes to the on-disk
filesystems are required. If available in the kernel, soft updates
can be enabled for each filesystem simply by tunefs -n enable
fs (OpenBSD: tunefs -s enable
).
FFS introduced all what we have come to expect from a modern Unix file system. A more advanced feature are the additional file flags, which allow setting a file append-only, immutable, undeletable, etc. Some of these are also available on Linux ext2fs. The commands to access the file flags are different, though:
Operation | BSD | Linux |
---|---|---|
show flags | ls -lo |
lsattr |
set flags | chflags |
chattr |
The BSD filesystem hierarchy is quite similar to the Linux
FSSTND/FHS specifications, which drew heavily from BSD. There is
no /lib
, as the executables in /bin
and
/sbin
are statically linked. /usr/share
is more consequently used for sharable data, e.g. man pages, and
/usr/libexec
contains executables that are never
directly called, such as getty
(8) and a variety of
network daemons. On any BSD system, the hier
(7) man
page will give an overview of the filesystem layout.
BSD has retained a simple init
(8) and system startup
model. There are no runlevels other than single-user and multi-user
mode. If the system is booted up into single-user mode, init
spawns a shell on the console. Exiting this shell will bring the
system into multi-user mode by executing /etc/rc
. By
default, init
boots the system into multi-user mode
by calling /etc/rc autoboot
. /etc/rc
performs various initializations such as checking the filesystems,
reads in /etc/rc.conf
, and executes a variety of
modular /etc/rc.*
subscripts. There is no
/etc/inittab
, getty
(8)s are started from
/etc/tty
.
The init
(8) process assigns a particular meaning
to many signals:
Signal | Command | Action | Remarks |
---|---|---|---|
HUP | rescan /etc/ttys |
||
TERM | shutdown |
single-user mode | |
TSTP | block logins | ||
INT | shutdown -r |
reboot | |
USR1 | shutdown -h |
halt | |
USR2 | shutdown -p |
power off | FreeBSD only |
A unique BSD feature is the securelevel concept. Any superuser
process can raise the securelevel of the system, but only
init
(and not even that on FreeBSD) can lower it.
Higher securelevels restrict operations such as changing append-only
or immutable file flags or access to raw disk devices.
-1 | permanently insecure mode |
0 | insecure mode, single-user |
1 | secure mode, multi-user |
2 | highly secure mode |
3 | network secure mode (FreeBSD) |
The point of securelevels is to keep even root
from
doing some things. An obvious application would be a firewall
machine, which could keep running securely with a nailed-down
configuration even if an attacker managed to breach the system and
gain superuser access. Without console access he could not break
out of the securelevel restrictions.
One of the most frequently asked questions is about where documentation on BSD can be found. Fortunately, this is easy to answer:
There are many small differences that people with a Linux background keep stumbling into when they first install a BSD system. I will mention a few of those, just to reinforce the point that the systems are in fact quite similar although some details differ.
Where Linux uses the generic eth0
for a network
interface, on BSD interfaces are named according to the driver,
e.g. fxp0
(Intel EtherExpressPro), xl0
(3Com 3C905), de0
(DEC 21040 "Tulip"). Network-related
commands also display various syntax differences, e.g.
Action | BSD | Linux |
---|---|---|
show interfaces | ifconfig -a |
ifconfig |
show routes | netstat -r |
route |
User information including the encrypted passwords are stored
in /etc/master.passwd
. From this file /etc/passwd
is generated for backwards compatibility, along with
/etc/spwd.db
and /etc/pwd.db
, which
contain the secure (including encrypted passwords, super-user only)
and insecure (passwords stripped, world-readable) password databases
respectively, in a format that allows for faster access than linear
search through a text file. To edit the password file, use
vipw
(8). It calls the user's preferred editor
($EDITOR
) to edit the master.passwd
file,
performs a syntax check, and regenerates the other files.
Occasionally it is necessary to determine the hard way just what
actions a program takes at runtime. SVR4 offers truss
,
Linux has strace
for system call tracing. The equivalent
BSD toolkit consists of ktrace
(1), which writes a
trace dump to ktrace.out
, and kdump
(1)
to decode the trace dump into human-readable format. Additionally,
NetBSD has a ktruss
(1) command that combines both,
and FreeBSD has a procfs-based truss
(1).
Many comparisons between BSD and Linux concentrate on minute technical details. Since both systems are in very active development, those differences tend to go obsolete within a few months at most. For example, NetBSD was the first open-source operating system to incorporate USB support, and the other BSD projects followed suit before Linux did.
BSD is a full-fledged Unix operating system, which shares Linux' technical prowess and open-source development drive, and with an an unbroken line of descent back to AT&T UNIX version 1 to show as prime pedigree. Although many details are different from Linux, but not necessarily more so than among different Linux distributions, similar problems breed similar solutions and the basic approaches are the same. Many differences may boil down to a matter of taste. Next time you are despairing over the choice of Linux distribution, add to your considerations BSD as another type of Linux. You may like the taste.
zoularis
package