Unix & Multics

[RSanders.Pascalx at USGS2-MULTICS.ARPA]

re: Unix & Multics

Having hacked first Multics, then Unix, for about 3 years each, I have
some strong opinions.  Please don't refer to Multics in the past tense;
there are still a few running, and Honeywell (miraculously) manages to
leave them on loading docks once in a while (they sure don't try to
sell them!)

The things I miss most from Multics:

--- Clean, well-documented, layered, modularized, [fill in the blank
with good words] source code.  Unix sucks in this area, compared to
Multics.  This is my single biggest gripe about Unix.

--- A consistent user interface.  Multics is much more consistent than
Unix ( -brief or -bf means less verbose output for *every* Multics
command).

There's no way Unix, in the hands of hackers worldwide, lacking user
interface and internal programming standards, can approach Multics in
these 2 areas.  I think it's too late for AT&T to do anything about
Unix in these areas now.

---  Dynamic linking.  On Multics, a program that calls subroutine
libraries compiles to just the program.  When a library subroutine is
called the first time, Multics looks in a standard set of directories
(like Unix shell path), and puts a pointer to the subroutine in a
static area.  From then on, that subroutine call is nearly as fast as a
compiled-in-same-unit subroutine call.  I've been wanting this
capability in Unix for years.  No flames about drawbacks from people
who haven't used this.

I'm not about to switch from Unix back to Multics (can't anyway).

What I like about Unix compared to Multics:

The list is long - I'll skip details on obvious things like I/O
redirection, portability, and a dynamic user community - these were all
correctable faults of Multics.  PL/1 is to Multics as C is to Unix.

Some deeper differences:

--- The use of pipes in Unix, and the way pipes shaped command output
is incredibly valuable for building new tools (shell scripts) without C
hacking.  To do something new on Multics almost requires PL/1 hacking.

--- In Multics, each login is one gigantic process.  Running a command
is almost *exactly* like calling a subroutine.  The presence of
(conceptually) zillions of static variables leads to outrageous,
baffling side effects - irreproducible results are quite common.
Standard advice to users with mysterious bugs is "newproc and try
again" (newproc zaps all the static variables).  Unfortunately,
extensive use of environment variables, tty states, etc. in Unix is
heading down that path.

Sorry this went on so long, but Unix hackers seem to refuse to learn
things from other operating systems.

BTW, this diatribe was prepared on a VAX/4.2 BSD Unix, then transmitted
to Multics (my ARPAnet connection) for blasting off to you-all.  Of
course, these opinions never existed anywhere else.

-- Rex
   RSanders @ USGS2-Multics

Historical note:  Primos (Prime minicomputer operating system) is
supposed to be a re-implementation of Multics (I've never used Primos).