Why I run FreeBSD
SunOS, Solaris, Linux? No, thanks!
Rich explains why FreeBSD is the superior OS for him. (1,500 words)
ast 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 Walnut Creek CDROM, I use FreeBSD. 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 Mac (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 (by current standards, at least) little 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 filesystem), 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'll 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 was 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 filesystem, 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. There must be 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..." Uh-huh. 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 isn't 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'm told that it exists, but that it doesn't really work. This isn't to say that Linux is a bad system; it isn't. I just like the solid feeling I get from FreeBSD.
Having said all this, I should point out that the open source community isn't a static environment. The Linux developer community is large and active; I'm quite certain that the "important" bugs will be 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's 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 2,500 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 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, which contains 150-plus 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.4 BSD-Lite system. Years of careful software engineering have given it robustness, clean organization, and all the features its team of experienced hackers can provide.
Solaris, in contrast, seems to be hobbled by a range of nontechnical 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 this, I should point out that Solaris serves some needs that FreeBSD does not. Full-on SMP and realtime support, for example, are still in their infancy on the FreeBSD side.
So, I'm not saying 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 check into the way 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
Rich Morin operates Prime Time Freeware (www.ptf.com), a publisher of books about open source software. He lives in San Bruno, CA, on the San Francisco peninsula.
If you have technical problems with this magazine, contact email@example.com