marketing unix

[Henry Spencer]

In response to (some of) Guy Harris's comments:

> 1) BSD UNIX supports the VAX-11 hardware far better than System V.  For
> one thing, it correctly handles Translation Not Valid faults.  The OS isn't
> supposed to panic when that happens, it's supposed to fetch the missing
> page from the disk.  There are applications out there that *need* virtual
> memory (or, at least, run better with it than without it).

Although AT&T still has not gotten its finger out and added virtual memory
to System V, other people have.  The HCR people, in particular, gave a nice
presentation about it at Usenix.  They pointed out that virtual memory, done
*right*, is nowhere near as complex as that awful mess inside 4.xBSD.

> 2) BSD UNIX supports most of the (conventional) devices that can be attached
> to a VAX-11, even those that the BTL UNIX developers don't like.  Furthermore,
> it supports more {Uni|Mass}bus adaptor/device configurations than System III
> did (S3 was particularly dismal in this); S5 may actually realize that a
> user may want to have more than two MBAs and put some disks on one and some
> on another, or have two UBAs, or... but S3 sure didn't.

Berkeley is still guilty of being parochial about device support, although
I admit they aren't nearly as bad about it as AT&T.  Even in 4.2, one can
find drivers marked "never tested, beware", which probably means that they
don't work.  Claims to support device X should not be taken at face value.

> 3) BSD UNIX's terminal driver has a superior user interface than do any
> of the BTL UNIXes ...

Oh really?  I'm sure the people at Research snickered about this.  Real
windows are about 10000% better than Berkeley's awful "job control".
(This is not to say that the folks at AT&T have done much better; neither
4.2 job control and V.2 layers is a real window system, even though that's
what is *really* wanted.)

> the System V Release 2 "job control" mechanism is inadequate, because 1)
> there's no way to notify a program that does "funny things" to the terminal
> (screen editing, putting it in graphics mode, putting the keypad in application
> mode, etc.) that it's having control of the terminal taken away from it (so
> it can clear the screen, or put the terminal back in a "standard" mode that
> the program to whom the terminal is being given can use it) or that it's
> getting control of the terminal returned to it (so that it can redraw the
> screen or put the terminal back into the mode it was in when it left) ...

Programs should not have to know these things, ever.  The right way to do
disciplined interaction with multiple processes (which is what it's all
about, folks) is that the programs should never have to know *any* of
this stuff, any more than an ordinary program has to know whether it's
printfing to a pipe or a disk file.  The multiplexing of user interaction
should be a centralized function, not something that's distributed over
every program that ever expects to participate in it!

Yes, this means that screen redraw has to be centralized.  This is the
key item that AT&T missed.  No credit to Berkeley, though, since they
botched it much more badly.

> there's no way to stop a job - all you can do is take the terminal away from
> it.  It'd occasionally be useful to stop a job, examine it or correct an error,
> and restart it - which the BSD job control mechanism lets you do.

Adding suspension and restart to a Unix kernel should be a one-hour hack,
if you don't get it confused with multiplexing/windows/job-control/whatever.
Doing it right would also fix some of the dreadful botches in the BSD stuff,
like being able to suspend, say, passwd(1) in the middle of an /etc/passwd
update.

> 4) 4.2BSD UNIX supports networking sensibly.  System V doesn't. ...

"Supports networking", yes.  "Sensibly", well...  Many people have, uh,
strong opinions on that subject.  The lack of networking support in
System V is definitely a defect, but emulating 4.2 is not necessarily
the way to go.

> So how about declaring a truce, and both sides picking up the good ideas from
> each other?  (Or developing a system which picks up the best of both worlds.)
> These sort of debates can be fun, just like the UNIX vs. VMS debates, but
> adopting the good ideas from other systems is generally more productive than
> playing NIH games and defending your favorite system when right and when wrong.

Dumping the *bad* ideas from each is at least as important as picking up the
good ideas, and I see no sign that anyone is prepared to do that.  The AT&T
people seem bent on the "lots more features, union of all possible wishlists"
approach to Unix development.  And Berkeley's claim to fame seems to be
based on quantity of new ideas rather than quality.  "4.2BSD does everything
UNIX does, only differently."

I want V8.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry