In defense of BSD (was: something else)

[Henry Spencer]

> ... This is not an attempt to pick on Henry Spencer...

Who, me, criticize Berkeley?  Nah. :-)

> ...I am just about fed up with all of the
> gratuitous Berkeley-bashing that has been going on here the last couple
> of months.  I know of quite a few people out there who put in long, hard
> hours (with little or no pay) to benefit every person who uses any Unix
> system today (even SV versions)...

Actually, I will (and do) admit that Berkeley has done a lot of useful
things.  In particular, there is one VERY IMPORTANT thing they did that
they almost never get credit for, because it's not flashy and obvious.
It's easy to notice, and praise, new features (although a bit less of
that might be a good idea...).  It's not so easy to notice and properly
appreciate a solid system.  32V, as released by AT&T, was a very raw and
incomplete port.  After releasing it, AT&T basically spent several years
dithering over whether to do anything further for outside consumption.

At around that time, an awful lot of people were interested in Unix on a
VAX, since the good old 11's limitations were getting pretty painful.
However, most of these people wanted a *production* system, something
they could use to do real work, not a flaky experimental system.

The significant thing that Berkeley and its outside contributors (e.g. DEC)
did was to shake 32V down into a solid system that coped with and exploited
the VAX hardware effectively.  This is NOT trivial, as anyone who's read
the VAX hardware manuals will testify.  The eventual System V releases
for the VAX didn't do nearly as good a job on it.  Note that I am not
talking about virtual memory; I'm referring to hardware error recovery,
configuration procedures, proper device handling for a wide variety of
devices, bad-block support for disks, and so on.  None of this is glamorous
and sexy, but it makes an enormous difference to people who want a system
that *runs* reliably without endless tinkering.

In my opinion, this particular effort was what *really* established UCB
as a credible "supplier" of Unix.  And it was Berkeley's willingness to
do this work, and AT&T's unwillingness to do it (or at least, to release
the result), that really led to the current schizophrenic situation in
the Unix world.  For several years, 4BSD -- silly incompatibilities and
all -- was the only Unix that a sensible, production-oriented shop would
run on a VAX.  When AT&T finally got around to doing something along
those lines, 4BSD had a large head start.  AT&T has been fighting to
catch up ever since.

We now return you to our normal Berkeley-bashing... :-)

> Without them driving the development
> process through the 1098's, we'd all still be using V7 systems...

Frankly, with a couple of reservations, that doesn't strike me as an
enormously bad thing.  Going that route would have avoided an awful lot
of unnecessary compatibility headaches.  There wasn't a lot wrong with
V7 that couldn't have been fixed in a backward-compatible way.

> ... Sure, they introduced
> some incompatible changes and features that were difficult and awkward
> to use, but before you criticize them for it, remember that in many
> cases they had *no prior art* to use as a guideline.

I'll go along with that argument, more or less, for semi-botched new
features.  I fail to see that it applies to silly, incompatible changes
to existing ones.

> They gave it the gift of paging.  (Yes, I know that the Vax paging
> code originated with 32V.  When was the last time you used 32V?)

Actually not true; 32V used the paging hardware in a limited way but did
not do virtual memory, which is what most people think of when they hear
the word "paging".  By the way, 4BSD virtual memory is a mediocre design
with wretchedly messy innards that few dare touch, because they are
so cryptic and fragile.  It's not an accident that the virtual memory
is much the most popular target for re-implementation by Unix-box makers.

> They added networking code that has
> become an indispensible part of today's mini and workstation setups.

However, they were not the first to do this, so this hardly counts as a
massive argument in their favor.  They also did a number of things that
almost got them lynched by the rest of the TCP/IP community; we're still
living with the aftereffects of some of those botches.


To sum up:  Berkeley has made some quite valuable contributions.  However,
they have also introduced a lot of stupid, incompatible changes that have
made life much harder than it needs to be.  If the effort that went into
unnecessary meddling with working software had gone into useful projects
instead -- or even into tossing a Frisbee around on the lawn -- we'd all
be even better off.  AT&T's problem is inertia and lack of interest in
useful changes; Berkeley's problem is an excess of enthusiasm for new
and nifty ideas, without adequate consideration of whether they are
*good* ideas.  This enthusiasm is no problem -- indeed, it's desirable --
in a research lab that produces papers instead of software.  But when the
end product is software that thousands of sites end up depending on, one
could wish for a bit more restraint.
-- 
"For perfect safety... sit on a fence|  Henry Spencer @ U of Toronto Zoology
and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henry