🚀 go-pugleaf

In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp
(Henry Spencer) writes:

   This is a rather drastic oversimplification.  Unix was not just "Multics
   on a low budget", it was also "90% of the benefits at 10% of the cost".

Or rather 10% of the benefits for 10% of the cost. I am hard
pressed to think that the cost/benefit ratio of Multics was lower
than that of V7 Unix; there are lots of things that are
impossible to do efficiently under V7 Unix, and trivially easy
under Multics (use Multics RDMS, and then read what Stonebraker
has to say about how suitable is Unix for Ingres). With Unix you
get the 10% of the benefits that are ideal for sw development
(editing, compiling), and at 10% of the cost every little CS
Dept. in the country could buy a PDP-11.

   Remember that Multics and OS/360 are the two classic examples of second-
   system effect (overconfidence after a successful first system leads to
   vast complexity and a union-of-all-wishlists approach on the second).

To put Multics and OS/360 in the same phrase is offensive.
Multics was very clearly designed to be as orthogonal and lean as
possible, and it largely succeeded. The overconfidence was in
breaking a lot of new ground, not in the inexistent morass of
features. It was a research project after all.

   With the benefits of hindsight and a much more manageable system, Unix
   ended up taking a lot of ideas much farther than Multics did.

Like that interesting but misconceived hack, pipes? As to
anything else, I cannot really imagine any Unix idea that is not
a crippling of a Multics idea (e.g. the setuid bit). The quality
of Unix stems from the extremely intelligent selection of the 10%
of the Multics functionality that could be implemented or ported
on a PDP-11. It takes real greatness to get it right, and to
provide such usefulness with so little.

The history of Unix after V7 (and before it), within and without
AT&T, is really a series of grotty attempts, culminated in SVR4,
to put in back the missing 90%, as HW architectures become less
constraining than a PDP's.

   >UNIX is just
   >beginning to implement some of the ideas which have been working in
   >Multics for two decades, such as mapping files to memory.

   Gee, how could we ever have lived without that for two decades?  :-)

Painfully. And only because much of the "progress" of CS in this
twenty years has been expansion, not advancement. The success of
Unix vs. Multics (even if this competition never quite existed)
can be seen as a colossal catastrophe, if one looks at the
slowing down in operating system evolution it has caused, much
like OS/360, or as a great success, because it has lead to an
expansion of the field. It has elevated the median, but not the
average.

   Maybe because we don't need it and it doesn't buy us very much?

Again, compare RDMS with Ingres; or confer with News.

   >  The only reason Multics is not where UNIX is today is that it was
   >developed by one company which didn't know how to sell computers and
   >then rights went to another...

   I can think of several other reasons, actually, starting with Multics
   being much larger, being much fussier about memory management and
   such, and performing very poorly by comparison.

This is entirely ridiculous. Multics performance, except on the
very early machines without hardware assist for rings, has always
been *excellent*. I have seen relatively underpowered systems (a
6000 could do 1 MIPS with 1 MW, and could still run quite a few
users) sustain dozens of users with grace. I am quite sure, but
cannot quote numbers to say this, that with Multics and SUN
machines of equivalent power, Multics will give better response
times. Mach, which is a kind of latter day, higher overhead,
Multics like Unix, is reported outperforming VM Unix.

As to Multics being much larger, let's compare the line counts
listed in the MIT TR on the kernelization of its nucleus, with
the line counts of 4.3BSD.

As to fussiness about memory management, it only really requires
virtual memory with restartable/continuable faults.

	Note: what I said about Multics applies in slightly reduced
	form to TENEX, and in a more emphatic form (modulo some
	oddity) to MUSS, and with some proviso to Accent/Mach.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk