unix on large machines

[utzoo!decvax!ucbvax!unix-wizards]

>From BH at SU-AI Tue Aug 11 09:06:37 1981
Since KLH doesn't seem to have answered the request for details on
why UNIX isn't perfect for big machines, let me try:

1.  The file system is flaky.  UCB is working on some aspects of
this problem but not all.  They seem to be fixing the problems in
which a disk block is added to one list BEFORE it's removed from
another, which is how the file system is compromised by a system
crash.  But they aren't changing the fact that overwriting a file
(a creat with an existing name) deletes the old file right away
rather than on a successful close, nor are they adding an exclusive
access discipline to the kernel.  (About once a month or so my
/etc/passwd disappears when several people try to change their
passwords or create new accounts at once, despite supposedly
foolproof lock-file code in the user programs.)

2.  Debugging facilities leave a lot to be desired.  You can't
type instuctions in to adb, so it's hard to patch code.  The
symbol table doesn't know about things like fields in a struct,
so symbolic debugging only partly exists.  You can't use adb
standalone to poke at a crashed system.

3.  Many smaller, easily-fixed things show that UNIX was designed
with a small machine in mind.  One example: the result of compiling
"foo.c" should be called "foo", not "a.out".  Clearly they designed
the naming convention for a machine without much disk space, in which
it was antisocial to have executable files for more than one program
at a time!

4.  There are terminals in the world other than the model 37 TTY.
The UCB termcap package makes it possible for there to be a few
huge, hairy user programs which support displays.  But there needs
to be kernel support (or the equivalent in shell support, with
all other user level tty interaction funneled through the shell,
which would be awkward) for things like automatically dividing the
display screen into pieces for different processes.  The user must
be able to type escape sequences of some sort to control which piece
hse's typing into right now.  It should be possible to write a
TRIVIAL user program which can still fit into this display
discipline, e.g., it shoul be able to type a control-L and have that
mean "clear my piece of the screen".

5.  Some things aren't written as efficiently as they might be.

There's more, but this will do to begin the discussion.  Mind you,
I think UNIX is wonderful in many ways.  Pipes are great, filters
are great, process trees are great, etc.  Many of the flaws in UNIX
could be fixed in a more or less compatible way.  (Not the one about
deleting the old file too soon, though.)  (By the way, yes I know
you can program around it.  The difference between an okay system and
a great system is that you don't have to program around the great
system, you can program THROUGH it!)  It's not that the future
large-computer standard operating system should look nothing like
UNIX, it's that the standard large-computer UNIX needs some redesign
before it gets ossified as a standard.