From uucp Fri Aug 14 11:39:22 1981 remote from pur-ee
NAucbvax.2619
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NTue Aug 11 09:14:54 1981
Nunix on large machines
N>From BH@SU-AI Tue Aug 11 09:06:37 1981
NSince KLH doesn't seem to have answered the request for details on
Nwhy UNIX isn't perfect for big machines, let me try:
N
N1.  The file system is flaky.  UCB is working on some aspects of
Nthis problem but not all.  They seem to be fixing the problems in
Nwhich a disk block is added to one list BEFORE it's removed from
Nanother, which is how the file system is compromised by a system
Ncrash.  But they aren't changing the fact that overwriting a file
N(a creat with an existing name) deletes the old file right away
Nrather than on a successful close, nor are they adding an exclusive
Naccess discipline to the kernel.  (About once a month or so my
N/etc/passwd disappears when several people try to change their
Npasswords or create new accounts at once, despite supposedly
Nfoolproof lock-file code in the user programs.)
N
N2.  Debugging facilities leave a lot to be desired.  You can't
Ntype instuctions in to adb, so it's hard to patch code.  The
Nsymbol table doesn't know about things like fields in a struct,
Nso symbolic debugging only partly exists.  You can't use adb
Nstandalone to poke at a crashed system.
N
N3.  Many smaller, easily-fixed things show that UNIX was designed
Nwith a small machine in mind.  One example: the result of compiling
N"foo.c" should be called "foo", not "a.out".  Clearly they designed
Nthe naming convention for a machine without much disk space, in which
Nit was antisocial to have executable files for more than one program
Nat a time!
N
N4.  There are terminals in the world other than the model 37 TTY.
NThe UCB termcap package makes it possible for there to be a few
Nhuge, hairy user programs which support displays.  But there needs
Nto be kernel support (or the equivalent in shell support, with
Nall other user level tty interaction funneled through the shell,
Nwhich would be awkward) for things like automatically dividing the
Ndisplay screen into pieces for different processes.  The user must
Nbe able to type escape sequences of some sort to control which piece
Nhse's typing into right now.  It should be possible to write a
NTRIVIAL user program which can still fit into this display
Ndiscipline, e.g., it shoul be able to type a control-L and have that
Nmean "clear my piece of the screen".
N
N5.  Some things aren't written as efficiently as they might be.
N
NThere's more, but this will do to begin the discussion.  Mind you,
NI think UNIX is wonderful in many ways.  Pipes are great, filters
Nare great, process trees are great, etc.  Many of the flaws in UNIX
Ncould be fixed in a more or less compatible way.  (Not the one about
Ndeleting the old file too soon, though.)  (By the way, yes I know
Nyou can program around it.  The difference between an okay system and
Na great system is that you don't have to program around the great
Nsystem, you can program THROUGH it!)  It's not that the future
Nlarge-computer standard operating system should look nothing like
NUNIX, it's that the standard large-computer UNIX needs some redesign
Nbefore it gets ossified as a standard.
N
N
N