marketing unix

[Guy Harris]

> TO Erik E Fair,
> I have not personally used BSD unix so I can't make any speed claims,
> BUT how upward compatable is 4.1 to 4.2??
> All AT&T BTL Unix's are upward compatable.

I presume you're referring to the article which read

> I'm waiting for the collective screams of those estimated 150,000
> professionals and programmers when they realize that System V on
> [insert random machine] isn't as good as 4.1/4.2 BSD on their alma
> mater's vaxen...

> ``What do you mean, ^Z and ^W don't work here?
>   Why doesn't this UNIX act like the VAX at Podunk U?''

(although there was no "References:" line in your article, and you didn't
bother including any relevant text from the article you were replying to -
as was done above), but "isn't as good as" refers to several things here:

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).

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.

3) BSD UNIX's terminal driver has a superior user interface than do any
of the BTL UNIXes (including V7) - the point made in the quote above.  Why
can't System V properly erase tab characters in ECHOE mode?  Furthermore,
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) and 2)
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.

4) 4.2BSD UNIX supports networking sensibly.  System V doesn't.  And if the
USDL people are as Berkeleyphobic as it has been claimed they are, System V
isn't likely to in the near future.  The Berkeley networking implementation
*works*, and at least seems well designed for supporting multiple protocols
(which is going to be a necessity for the forseeable future).

5) In some ways, 4.2BSD has better administrative facilities than System V.
The auto-reboot stuff and "fsck -p" for preening file systems is nice, and the
disk quota mechanism will come in very handy for some sites, to name two
examples.

I also think there are some things that System V does better.  The System III/
System V "open" and "fcntl" calls are nice; so did Berkeley, as they adopted
them for 4.2BSD.  The shared memory is useful, although Berkeley plans to add
it at some point.  I personally prefer the System V "init" because it's more
flexible than the old-style "init" (it's nice to be able to control arbitrary
daemons from "init", and it's nice not to have to run "getty" as the login
program on every terminal).  The added functionality in the libraries and some
of the commands are useful.  "Terminfo" and Mark Horton's new "terminfo"-based
"curses" are supposed to be superior to "termcap" and the earlier "curses".

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.
(Are you listening, USDL?)

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy