Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mordor.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!ut-sally!mordor!jdb
From: jdb@mordor.UUCP (John Bruner)
Newsgroups: net.micro
Subject: Re: Unix and the future
Message-ID: <1441@mordor.UUCP>
Date: Fri, 12-Apr-85 14:49:13 EST
Article-I.D.: mordor.1441
Posted: Fri Apr 12 14:49:13 1985
Date-Received: Mon, 15-Apr-85 02:47:58 EST
References: <9809@brl-tgr.ARPA> <148@yetti.UUCP>
Organization: S-1 Project, LLNL
Lines: 48

UNIX is my favorite operating system, but I've had the good fortune
to work with people from MIT who don't care much for it (and who
continually complain about its shortcomings).  I've also been
privileged to have used MIT-MULTICS (after studying its concepts
in I-don't-know-how-many courses when I was at Purdue).  MULTICS is
not without shortcomings either (I like UNIX better), but the chance
to compare the two side-by-side and seriously examine both has been
very beneficial to me.

UNIX was developed on very small systems.  It runs well (or at least,
it once did) on small machines like PDP-11's.  Many of its concepts
are tuned toward small systems.  To some degree, as UNIX moves up to
larger and larger hardware its development is hampered by these
small-system assumptions.

Example: core dumps.  My understanding of core dumps on the PDP-7 is
that they were restartable.  On a PDP-11, having a process dump core
and poking around in it post-mortem is awkward, but compared to
other mechanisms of the time (on similar hardware) it probably wasn't
too bad.  At least the core file couldn't be larger than 64K.  However,
on today's machines a giant (multi-megabyte) core file is a big
liability.  Once the kernel starts dumping core there is no way to
stop it, and it does a good job of tying up the buffer pool while it
is running.  The debugging environment on MULTICS is a clear winner.

Another example: temporary files.  The C compiler (for instance) runs
in five separate phases (preprocessor, compiler proper, optimizer,
assembler, linker) [six on the PDP-11 where the compiler is split
into "c0" and "c1"].  This is a lot of fork()s and exec()s, and
the intermediate results are passed between phases by temporary
files (or, more recently, by pipes).  This isn't unreasonable
when the machine has only a 64K address space (or less!), but why
do compilers for larger machines still follow this model?  Why
not incorporate the preprocessor, compiler, optimizer, and assembler
into one program?  (An assembler, if desired, can be separate.)  The
interphase information would then be passed in main memory.

I can come up with more examples, but this article is getting long
already.  There are ways to address these issues in UNIX, but such
changes come at the expense of muddying an originally-clean concept
and producing a system whose overall design is full of warts.  At some
point it becomes desirable to start over from a new set of basic
ideas.  UNIX has been available outside of Bell (oops, AT&T) for
more than ten years now, and its age is starting to show.
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor.ARPA [jdb@s1-c]	(415) 422-0758
  UUCP: ...!ucbvax!dual!mordor!jdb 	...!decvax!decwrl!mordor!jdb