BSD: Linux With a Twist

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.


Table of Contents

  1. Introduction and History
  2. Overview of Available Distributions
  3. The Development Model
  4. Integration
  5. Third-Party Software: Ports and Packages
  6. System Administration
  7. The File System
  8. Init
  9. Miscellaneous
  10. Conclusion

Introduction and History

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.

Overview of Available Distributions

Since the CSRG shut down, several modern derivates of 4.4BSD have appeared, some of them wedded to commercial products.

BSD/OS

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.

Darwin

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:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. 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.
  3. 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.

  4. 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.

FreeBSD

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.

NetBSD

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.

OpenBSD

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.

The Development Model

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:

  1. Contributors submit code or documentation but don't have write access to the source tree. For their work to be included, it must be checked in by a committer.
  2. Committers are developers with write access to the source tree or, in CVS parlance, commit rights. Typically a committers works only on a selected part of the project, his area of responsibility.
  3. The core team guides the overall direction of the project and makes the final decisions in case of disagreement among developers. (OpenBSD doesn't have a formal core team, but Theo de Raadt serves as project leader.)

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.

Integration

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.

Third-Party Software: Ports and Packages

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

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.

System Administration

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.

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:

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...

The File System

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.

Init

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.

Miscellaneous

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.

Conclusion

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.


Footnotes

  1. Peter H. Salus, A Quarter Century of UNIX, Addison-Wesley, 1994.
  2. Marshall Kirk McKusick, "Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable",
    in Chris DiBona et al. (eds.), Open Sources, O'Reilly, 1999.
    http://www.oreilly.com/catalog/opensources/book/kirkmck.html
  3. Wolfram Schneider et al., "The Unix System Family Tree/BSD History Chart".
    ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree
  4. Christos Zoulas' zoularis package
    ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/cross/zoularis/README.html
  5. Gregory R. Granger and Yale N. Patt, "Soft Updates: A Solution to the Metadata Update Problem in File Systems", U.Michigan Report CSE-TR-254-95.
    http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/
  6. The FreeBSDMall: Software, Books, and Promotional Items for FreeBSD.
    http://www.freebsdmall.com/
  7. Greg Lehey, The Complete FreeBSD, Walnut Creek CDROM, 1999.
  8. Marshall Kirk McKusick et al., The Design and Implementation of the 4.4BSD Operating System, Addison-Wesley, 1996.

Christian "naddy" Weisgerber <naddy@mips.inka.de>
$Id: bsdlinux.html,v 1.5 2006/01/26 16:31:34 naddy Exp $