Linux-kernel mailing list archive 1999-23,: Why I run FreeBSD - SunOS, Solaris, Linux? No, thanks!

# Why I run FreeBSD - SunOS, Solaris, Linux? No, thanks!

Dinesh Nair (dinesh@alphaque.com)
Thu, 10 Jun 1999 08:52:32 GMT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Oleg Drokin: "2.3.6 does not compile"
- Previous message: David Luyer: "Re: Why I run FreeBSD - SunOS, Solaris, Linux? No, thanks!"

Why I run FreeBSD

SunOS, Solaris, Linux? No, thanks!

------------------------------------------------------------------------
Abstract

Rich explains why FreeBSD is the superior OS for him. (1,500
words)

------------------------------------------------------------------------

Last month's column ("Serious FTP") discussed anindustrial-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.

FreeBSD amenities

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.

URL: http://www.sunworld.com/swol-05-1999/swol-05-silicon.html
Last modified: Friday, May 07, 1999

By the grace of God, /dinesh@alphaque.com\_/\ "All dogs go to
heaven."
dinesh@alphaque.com (0 0)
+=======================----oOO--(_)--OOo----=========================+
|for a in past present future; do |
| for b in clients employers associates relatives neighbours pets; do |
| echo "The opinions here in no way reflect the opinions of my $a $b."|
|done; done |
+=====================================================================+
http://pgp.ai.mit.edu/htbin/pks-extract-key.pl?op=get&search=0x230096E9

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Oleg Drokin: "2.3.6 does not compile"
- Previous message: David Luyer: "Re: Why I run FreeBSD - SunOS, Solaris, Linux? No, thanks!"