On the Use of NetBSD for Computer Science Education

Introduction

This is really a paper about almost any BSD derived operating system. I believe the following to be true for at least NetBSD, FreeBSD, and OpenBSD, and may well extend to commercial implementations such as BSD/OS. For brevity, I will use `*BSD' to stand for these, but any specific examples have been verified on NetBSD and FreeBSD unless otherwise noted.

The purpose of this paper is to convince you:

1. that certain specific beliefs about *BSD are not true,
2. that *BSD systems possess certain features that other operating systems, such as Windows and Linux do not, and
3. that these features make *BSD well suited for roles in Computer Science education, and especially the teaching of Unix and/or network programming.

Dogma (not Myths)

I disagree with the term `myth' being used to describe incorrect beliefs about software. A myth is usually a belief that was held because it was not testable at the time, and most of the things we call myths are not believed anymore. I prefer the term `dogma'. A dogma is a belief that is testable, but the believer either has not put it to the test or will not acknowledge refuting evidence. (With respect to operating systems, the latter case is usually referred to as `religion'.) Here I present common dogmas about *BSD and refuting evidence.

Dogma 1: *BSD has poor hardware support.

What particular piece of hardware are you worried about? Is it:

Video Cards?

This is certainly the single largest item people are thinking of when they worry about hardware support. However, the video cards supported by *BSD are exactly the same ones supported by Linux and always will be. The standard graphical user interface for Linux (XFree86) supports exactly the same video cards on Linux, *BSD, several other Unix flavors, and even OS/2 [XF8600]. And since the XFree86 Project went out of their way to develop an OS-independent method for dynamic module loading, this will continue even if hardware makers begin to release `closed source' XFree86 drivers [XF8699]. As for the commercial X server companies, Xi Graphics supports FreeBSD in addition to Linux [XG00], and Metro Link supports FreeBSD and BSDI in addition to Linux, as well as some other operating systems such as QNX [ML00].

Sound Cards?

This is certainly considered the second most important type of hardware by the home market at least. By far the largest collection of sound card drivers is the (commercial) Open Sound System from 4Front Technologies, which includes many more cards than are supported by any of the free operating systems on their own. The Open Sound System supports at least 9 Unix operating systems including Linux and *BSD, and even Lynx and VxWorx. My point of listing operating systems with far smaller user bases like OS/2 and VxWorx is to refute the dogma that Linux is more popular implies that Linux has significantly better hardware support.

Network Cards? SCSI Cards? ATAPI Disk Drives?

In general, the important ones of these are all supported by *BSD as well as Linux with one exception. The SCSI support of NetBSD (but not FreeBSD) is behind. In particular, NetBSD does not currently support the Adaptec Ultra2 Wide series of SCSI interfaces. Although this is hardly a concern with most PCs (which use IDE), it is a big problem with file servers and recent workstation-class PCs from Dell and Gateway, and probably other manufacturers. For workstations, NetBSD can easily be installed by adding either an IDE disk or a narrow-SCSI (50-pin) disk specifically for NetBSD. A 1GB disk (tiny by today's standards) is easily large enough for NetBSD, so the extra expense is a small percentage of the total system cost. For recent file servers, you don't have a choice since you certainly want your server operating system to be able to access the faster SCSI bus. Hopefully the NetBSD team will fix this soon. [Note: As of 3 Feb 2000, NetBSD now supports Ultra2 Wide SCSI controllers from AdvanSys.]

Scanners? Digital Cameras? CD Recorders?

The standard software for all of these (SANE for scanners, gPhoto for digital cameras, and cdrecord for CD recorders) is Unix software. It runs on *BSD (and usually many other flavors of Unix) just as well as it does on Linux.

Other?

It's true that if we ignore all platforms other than Wintel, the raw number of pieces of hardware supported by Linux is larger than for *BSD, for example floppytapes are supported by Linux but not *BSD (there is minimal support in FreeBSD). On the other hand, *BSD is beating Linux in what I consider to be some very significant areas:

Firewire

(Also known as i.LINK (Sony trademark) or IEEE-1394.) FreeBSD has included Firewire support in stable versions as old as 2.2.6 (April 1998) [KK99]. Work on Linux is just beginning, and there will be no Firewire support in a stable (vs. developer) version of Linux until version 2.4 [EP00]. We do know that Linus Torvalds considers Firewire to be unimportant [DS99], which is certainly news to anyone working with high-end digital video equipment.

USB

NetBSD has had USB support in stable versions for about a year, including support for console devices (i.e. keyboard and mouse), and recently announced support for USB Ethernet interfaces. Linux has partial and `mostly stable' USB support in developer kernels only, but supports far fewer USB devices than NetBSD, and does not yet support even mass-storage peripherals (e.g. Zip drives) [LU00]. Although there is a `back-port' of this driver to the latest stable (version 2.2.x) Linux kernel, it is apparently even less complete than the developer one [VP00].

Older Platforms

I wasn't going to mention the fact that NetBSD runs on 23 platforms, because most people are so Wintel-centric that they dismiss it as irrelevant. However, I decided that I wanted to note two things. First, I consider it a very good thing that a student can pick up an old SPARCstation 10 at a surplus sale on a budget and have a useful, very dependable, and fast-enough machine without having to worry about getting their hands on a operating system for it. Second, I think it says a lot about the ease of working with *BSD that has been ported to older and especially rare hardware (e.g. the pc532 of which fewer than 200 are known to exist).

Newer Platforms

Again, Wintel-centric people will dismiss this, but NetBSD is way ahead of Linux in running on new platforms such as MIPS-based handheld PCs which normally run WinCE. The NetBSD/hpcmips port is already supporting some Ethernet and SCSI interfaces. NetBSD is also already running on the Hitachi Super-H CPU (the other major handheld PC platform), but on a remotely controllable camera interface rather than a handheld PC.

Given the above evidence and given that the number of USB devices is growing quickly, it is safe to say that for a given hardware device your chances of finding a driver are as good or better for *BSD than they are for Linux. In any case, it should be clear that hardware support in *BSD is actually very rich. In fact, it was not until I started researching this that I realized just how well *BSD is doing in this area compared to Linux, because I was constantly assuming that Linux already supported things like USB and Firewire.

Dogma 2: *BSD is old/outdated/obsolete

I've heard this dogma in many variations, but I think they are all based on a small set of misconceptions. In particular:

*BSD `looks' old

What this actually means is: ``The *BSD machine I am looking at is not running GNOME or KDE at this time''. But GNOME and KDE are not Linux software, they are Unix software. This is an important point for me because this has specifically been said about the NetBSD PCs running in the UNLV College of Engineering. (the exact quote was ``NetBSD looks like vintage 1980s Unix''.) Those PCs are running the ctwm window manager, which has been used in the college since about 1994 or so. Some of us like ctwm enough to be running it on our Sun Ultra 10s (yes, me), but the point is that it is hardly valid to discount any operating system based on the fact that it is running a single application (in this case a window manager). There is a web page of NetBSD screenshots running various `modern' user interfaces, the most obviously refutative are:

http://www.netbsd.org/gallery/in-Action/ag-quake-native.jpg: NetBSD running KDE (and incidentally, QuakeWorld)
http://www.netbsd.org/gallery/in-Action/rh-gnomewm.png: NetBSD running GNOME (and scanning a photo with XSane scanner software)

It is the case that it may be more difficult to install GNOME or KDE on a *BSD system due to the fact that there is not (currently) as much development being done on making *BSD install procedure simple for end-users. For advanced users (anyone reasonably familiar with the Unix make program for example), installing something huge like GNOME is a matter of:

   # cd /usr/ports/x11/gnome
   # make install PREFIX=/opt
   

and waiting for some number of hours while the system automatically downloads all of the source code necessary for GNOME and the standard applications from the Internet, unpacks and patches them (when necessary), and installs it all.

*BSD is based on BSD which makes it old

It would be equally valid to say that Solaris is based on AT&T Unix and so it is even older than BSD, or that Windows NT is based on MS-DOS (or VMS if you prefer). BSD Unix has an admirable history, and it is one that is full of innovation. And innovation has continued to flourish in the post-4.4Lite days. Specific examples include the new UVM virtual memory subsystem that runs across most all NetBSD platforms, the CAM I/O abstraction layer of FreeBSD, and the encrypted swap system in OpenBSD.

*BSD should in no way be considered outdated or obsolete. Aside from having beaten Linux to at least two important hardware interfaces (USB and Firewire), the *BSD teams continue to make important innovations in the core operating system.

Dogma 3: *BSD has poor application support

It's not completely fair to call this a dogma, since whether it is or not is mostly a matter of opinion depending on how much you care about the ability to run commercial, closed-source programs natively. (For the purposes of teaching Computer Science, there are almost none of these.)

On the other hand, it seems that many people dismiss the *BSD operating system compatibility support far too easily. OS compatibility is nothing like cross platform emulation such as SoftWindows on SGI MIPS. In particular, it is not at all slow or flakey. The *BSD OS emulation is simply a way of mapping the system call interface of one Unix system to another. Not only does this allow *BSD systems to run commercial Linux software very well but software compiled on other systems as well. For example, NetBSD running on SPARC and UltraSPARC architectures is able to run SunOS and Solaris binaries, NetBSD running on DECStations is able to run ULTRIX binaries, etc. This allows organizations to upgrade to a modern OS while keeping their legacy applications (ULTRIX does not support shared libraries, but NetBSD running on a DECStation does, and will still run your old ULTRIX programs).

I am routinely running the Linux versions of Adobe Acrobat Reader 4.0, Netscape Communicator 4.7 with RealPlayer G2, and StarOffice on my FreeBSD system without problems. Installation of these programs is as simple as:

 
# cd /usr/ports
# make search key=acroread 
Port: acroread-4.0 
Path: /usr/ports/print/acroread4 
Info: View, distribute and print PDF documents 
Maint: dima@FreeBSD.org 
Index: print 
B-deps: 
R-deps: gdbm-1.8.0 linux_base-5.2 rpm-2.5.6

# cd print/acroread4
# make install PREFIX=/opt
>> linux-ar-40.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://ftp-pac.adobe.com/pub/adobe/acrobatreader/unix/4.x/.

[...Automatic download and install here]

If I hadn't had the Linux compatability module installed already, that would have been done automatically also. Compared to the Linux method of locating an RPM (assuming one exists), downloading it, and running RPM on it, this is a breeze.

If we do not consider `application support' in the commercial-third-party sense, then *BSD actually has greater support than Linux. Besides running all of the same Unix software that Linux can, *BSD is continually beating Linux in implementing the new software interfaces that applications rely on. For specific examples, FreeBSD was the first free OS to support T/TCP a.k.a TCP for Transactions (3 years before the first Linux implementation), while NetBSD was the first free OS to include IPv6 support.

Dogma 4: *BSD is a `fringe' operating system

Undoubtedly, there are fewer (maybe even far fewer) users of *BSD than there are of Linux. On the other hand, there are a good deal of companies using FreeBSD. Here's a quote from a July 1999 ZDNN story:

The list of big-name companies and Web sites that use BSD is impressive. Yahoo, UUNet, Mindspring and Compuserve are on the list - in fact, perhaps 70 percent of all Internet service providers use BSD. Also on the list - Walnut Creek CDROM Inc. and its CD-ROM FTP download site, which the company says delivers more than 1 terabyte of data to visitors every day. [BS99]

Suppose you are a Computer Science student. With which operating system would you like to have gained 4 years of experience by the time you graduate? If you are thinking of working for an Internet service provider, then the obvious answer is *BSD (even Microsoft has job openings that require FreeBSD experience [MS00]). But even if you aren't, having experience with systems other than Linux will set you apart from the droves of applicants who have `Run Linux at home' on their resumes.

Why *BSD?

The most important reason why I consider *BSD to be a superior choice for teaching Computer Science can be stated as ``Because *BSD serves as an excellent example.'' I believe that students can learn programming skills faster and better if they are taught using a *BSD operating system than other systems, for a lot of reasons, but two in particular.

The Source Code

One of the nice things about *BSD is that you can always find the source code. On Linux systems, finding the source code for the kernel is trivial, but what about the source for the ping, traceroute, or even telnet programs? Because `The Linux Operating System' is actually the combination of the Linux kernel with the GNU system's standard Unix tools, finding the source to a specific program requires first deducing which package it is contained in (SRPMs for Red Hat systems), then downloading and installing the package. If it is important to have the exact version that is currently install, then add a separate step for checking that.

On *BSD systems, if you know where the program is, then you can find the source. If I want to look at the source code for the exact version of telnet that is installed on my FreeBSD machine, this is all I have to do:

[~]0$ which telnet
/usr/bin/telnet
[~]0$ cd /usr/src/usr.bin/telnet
[/usr/src/usr.bin/telnet]0$ ls
Makefile        defines.h       main.c          sys_bsd.c       tn3270.c
README          externs.h       network.c       telnet.1        types.h
authenc.c       fdset.h         ring.c          telnet.c        utilities.c
commands.c      general.h       ring.h          terminal.c
[/usr/src/usr.bin/telnet]0$ 

I can even build the entire system from scratch by doing make world in /usr/src. This is very powerful. When source code is this available, students will refer to it all the time. And they'll be gaining knowledge of how real Unix programming is done every time. [Note: On some systems, the source code is stored on a file server to avoid duplicating it on all machines. For the UNLV College of Engineering, the location of the BSD source is /src/1/OS/NetBSD/<version>/src. Of course the systems could be configured so that /usr/src was linked to this directory if desired.]

Being able to locate the source with such ease is great, but where *BSD really shines is in their commitment to code quality and clarity. The NetBSD kernel is built with switches cc -Wall -Werror, which basically means that the code will be absolutely free of compiler warnings, or it won't compile at all.

But having the source code is useless if it is difficult to understand, so using a system where the developers have a real commitment to clarity is important. As a simple example, let's look at the definition of the sockaddr structure. This structure is a part of the standard Unix socket interface (of which *BSD is universally considered to be the reference implementation), and is normally located in /usr/include/sys/socket.h. On my FreeBSD system, it is defined as:

/*
 * Structure used by kernel to store most
 * addresses.
 */
struct sockaddr {
        u_char  sa_len;                 /* total length */
        u_char  sa_family;              /* address family */
        char    sa_data[14];            /* actually longer; address value */
};

which is exactly what you will see on most Unix-like systems, and in almost any textbook. On Linux or other GNU-based systems, what we find in /usr/incude/sys/socket.h is:

/* This is the type we use for generic socket address arguments.

   With GCC 2.7 and later, the funky union causes redeclarations or
   uses with any of the listed types to be allowed without complaint.
   G++ 2.7 does not support transparent unions so there we want the
   old-style declaration, too.  */
#if     (!defined __GNUC__ || __GNUC__ < 2 || defined __cplusplus || \
         (__GNUC__ == 2 && __GNUC_MINOR__ < 7))
# define __SOCKADDR_ARG         struct sockaddr *
# define __CONST_SOCKADDR_ARG   __const struct sockaddr *
#else
/* Add more `struct sockaddr_AF' types here as necessary.
   These are all the ones I found on NetBSD and Linux.  */
# define __SOCKADDR_ALLTYPES \
  __SOCKADDR_ONETYPE (sockaddr) \
  __SOCKADDR_ONETYPE (sockaddr_at) \
  __SOCKADDR_ONETYPE (sockaddr_ax25) \
  __SOCKADDR_ONETYPE (sockaddr_dl) \
  __SOCKADDR_ONETYPE (sockaddr_eon) \
  __SOCKADDR_ONETYPE (sockaddr_in) \
  __SOCKADDR_ONETYPE (sockaddr_in6) \
  __SOCKADDR_ONETYPE (sockaddr_inarp) \
  __SOCKADDR_ONETYPE (sockaddr_ipx) \
  __SOCKADDR_ONETYPE (sockaddr_iso) \
  __SOCKADDR_ONETYPE (sockaddr_ns) \
  __SOCKADDR_ONETYPE (sockaddr_un) \
  __SOCKADDR_ONETYPE (sockaddr_x25)

# define __SOCKADDR_ONETYPE(type) struct type *__##type##__;
typedef union { __SOCKADDR_ALLTYPES
              } __SOCKADDR_ARG __attribute__ ((__transparent_union__));
# undef __SOCKADDR_ONETYPE
# define __SOCKADDR_ONETYPE(type) __const struct type *__##type##__;
typedef union { __SOCKADDR_ALLTYPES
              } __CONST_SOCKADDR_ARG __attribute__ ((__transparent_union__));
# undef __SOCKADDR_ONETYPE
#endif

The author of this code has made very clever use of C preprocessor macros to make it easier to write sloppy programs. Specifically, it is done so that any of the sockaddr_* structures may be passed to a function having a sockaddr parameter without using a typecast. Unfortunately, this has also means that the file is useless as a learning tool. By searching through all of the include files, we finally find the definition of sockaddr in /usr/include/bits/socket.h:

/* Structure describing a generic socket address.  */
struct sockaddr
  {
    __SOCKADDR_COMMON (sa_);    /* Common data: address family and length.  */
    char sa_data[14];           /* Address data.  */
  };

but with yet another clever macro. We find the definition of the __SOCKADDR_COMMON macro in /usr/include/bits/sockaddr.h, and can finally begin to decipher what it all means.

Research

There seems to be a belief that there much more research being done on Linux than *BSD (see Dogma 2). As an informal test, I looked at all of the papers presented at the FREENIX Track of the 1999 USENIX Annual Technical Conference to see which of them pertained to (or were substantially developed on) *BSD vs. Linux. The score is *BSD: 16, Linux: 4, Other/Neither: 11. Although there may be far fewer *BSD books of the form ``Learn *BSD in 21 Days For Dummies'', it is apparent that `the literature' prefers *BSD. See the Appendix for a list of papers with comments.

Conclusion

*BSD is a good choice for teaching Computer Science. The *BSD projects maintain a strong commitment to code quality and clarity, while continuing to do innovative and ground-breaking work without covert agendas or hype. Most of the reasons normally given for not choosing *BSD are based on dogma or popularity contests. But since any argument beginning with ``Linux is more popular...'' reduces to ``...therefor we should use Windows'', it would be better to concentrate on the technical merits.

References

Appendix: Papers from USENIX 1999 FREENIX Track

^*Opinions in this document are those of Steve Lumos only, and not the Information Science Research Institute or the University of Nevada, Las Vegas.