Copyright (c) 1999-2001 by Rich Morin
published in Silicon Carny, May 1999
Last month's column (Serious FTP) discussed an industrial- strength FTP site, based on a 200 MHz P6 ("Pentium Pro") and a pile of special-purpose I/O hardware. Although my main server isn't trying to serve thousands of simultaneous FTP sessions, I still want it to be robust, easy to maintain, and convenient to enhance.
So, like Wanut Creek CDROM, I use FreeBSD (www.freebsd.org). Specifically, I'm using FreeBSD 2.2.8; I'll switch over to FreeBSD 3.x in a while; for now, I'm just lurking on comp.unix.bsd.freebsd.*, watching the new development track's bug reports quiet down.
It's not that I haven't tried Sun's offerings; I have. In fact, I have both SunOS and Solaris running here, as well as a Power Macintosh (supporting the www.mklinux.org web site).
However unwillingly, I have been initiated into the administrivia of a variety of Unixish systems. And, for a variety of reasons, I believe that FreeBSD is a clear winner over the others I have installed.
Why SunOS and Solaris Lose
I tried hard to retain the SunOS machine as my server. SunOS is a tidy little (by current standards, at least :-) BSDish operating system. Also, I am very familiar with its BSDish quirks and it has been amazingly reliable, so I was strongly motivated to keep it going.
Unfortunately, SunOS has had no real support from Sun for several years. As a result, the system software is quite out of date. It has gaping security holes (e.g., ancient Sendmail), annoying limitations (a "mere" 2 GB per file system), archaic development tools (no C++ or Perl), and some real oddities (no DNS without (yurggh) NIS).
Patches and add-on packages could solve much of this, but there is no guarantee that they would all play nicely together. In any case, I'm not into that degree of pain, so the SunOS box has been relegated to "experimental" use.
I have managed to avoid Solaris for several years, but I recently had reason to set up a Solaris system. I attached a CD-ROM drive and a pair of disk drives to the SCSI bus of a spare ELC and fired it up.
Everything went fine until Solaris looked at the disks. Then, because the disks didn't have Sun labels (Well, Duh!), the GUI installation procedure printed a nastygram and dropped me in front of a command-line prompt.
If this were a SunOS system, I would have known exactly what to do at that point: find a utility to get the exact size of the disks, fake up a plausible disk geometry to match the size(s), and edit the mess into the /etc/format.dat file.
You see, SunOS inherited the 4.2 BSD file system, which tries to employ disk geometry as a way to reduce head movement and rotational latency. Modern SCSI disks don't have fixed track sizes, however, so some parameter faking is required.
This, however, is Solaris 7, Sun's latest and greatest operating system. Surely there is a magic command to set things up on an "alien" disk drive. The fact that the GUI didn't call the appropriate routine is a bit annoying, but surely just an oversight.
So, I asked a friendly Sun support person for the answer. "Well, you have to find or create an entry in the /etc/format.dat file, matching the geometry ..." Uhuh. After years of development and millions of dollars, Solaris still can't figure out how to label a disk drive. Give me, as they say, a break...
I won't even get into the issues of Solaris support tools, save to say that a Unixish system without a C/C++ compiler and Perl 5 is not up to any standards I'd wish to set.
Why Linux Loses (for me)
Part of my problem with Linux is subjective; As a long-term BSD administrator, I am simply more comfortable with BSD-style control files, etc. In short, it's a matter of taste and/or familiarity.
There are other issues, however, that run deeper. BSD has had an immense amount of work put into it by large numbers of very knowledgeable people (e.g., Bostic, Joy, Karels, McKusick, ...). It has, in fact, been tuned and polished until the entire system works remarkably well.
All too often, when I ask about a Linux driver or facility, I am told that it exists, but that it doesn't really work. This is not to say that Linux is a bad system; it isn't. I just like the solid feeling that I get from FreeBSD.
Having said all this, I should point out that the Open Source community is not a static environment. The Linux developer community is large and active; I am quite certain that the "important" bugs will get fixed over time.
Aside from fundamental engineering issues and solving problems like labeling off-brand disks (FreeBSD's GUI installer handles unlabeled disks, of whatever size, without complaint), FreeBSD has a number of pleasing amenities.
First, there is the basic command set. Perl 5 and GNU C/C++ are provided, of course, but there are other pleasant surprises. The other day, I wanted to know whether pic(1) was provided. Silly question; of course it was! And, because it was GNU pic, it had support for both troff and TeX. Nice.
If a command isn't provided by default, I can usually find it in the FreeBSD Ports Collection (www.freebsd.org/ports). This delightful piece of software engineering provides automated downloading (FTP or CD-ROM) and installation for about 2500 Open Source packages.
The system handles several kinds of dependencies, source and/or binary distribution and installation, distributed CVS, oddball configuration questions ("Does your system support RFC 9876's second-level EWOMBAT handling in frobnitz(2)?"), and most of the other pain involved in installing (and removing!) packages.
Some industrious (and suitably capable) party should look into porting the Ports Collection infrastructure to Solaris. Part of the necessary work has already been done: the NetBSD (www.netbsd.org) folks have already added one variant set of definitions. I understand that OpenBSD is riding along, as well.
Any suitably competent make and Solaris wizard should be able to get things working fairly quickly. Although some packages would require tweaking, many should simply work "out of the box".
Control scripts are another area where FreeBSD shines. As an "occasional" (read, marginally competent) administrator, I am particularly fond of FreeBSD's /etc/rc.conf file. This contains 150+ annotated definitions of the form:
defaultrouter="10.0.0.1" # Set to default gateway (or NO).
Because this file is used by all of the other "rc" files, I have a single place to find (and set) key system parameters. The rc files are still available (and editable), but I seldom need to look at them directly.
I could go on, but I think you get the idea. FreeBSD is an up-to-date incarnation of the 4.4BSD-Lite system. Years of careful software engineering have given it robustness, clean organization, and all of the features that its team of experienced hackers can provide.
Solaris, in contrast, seems to be hobbled by a range of non-technical concerns. Putting GNU C/C++ on Solaris might require support; worse, it could (and does, in any case) keep customers from buying Sun's commercial C/C++ development solutions. Similarly, allowing the system software to recognize and label random disks wouldn't help Sun to sell its own drives.
In short, Sun appears to have a conflict of interest between short-term revenue and helping its customers. FreeBSD, with no such conflict, is free to pick the best technical solutions, and does. Finally, as an Open Source project, FreeBSD benefits from the efforts of thousands of volunteer developers.
Having said all of this, I should point out that Solaris serves some needs that FreeBSD does not. Full-on SMP and real-time support, for example, are still in their infancy on the FreeBSD side.
So, I'm not saying that you should dump your Solaris systems (let alone your Sun stock!) in favor of FreeBSD and Walnut Creek CDROM. I do recommend, however, that you look over the way that the FreeBSD (and Linux, if you prefer) communities are doing things.
The Solaris community (and Sun, for that matter) could stand to pick up a few pointers...
About the author