Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: the Multics from the black lagoon :-) Message-ID: Date: 11 Feb 90 21:35:48 GMT References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 94 In-reply-to: henry@utzoo.uucp's message of 7 Feb 90 22:18:00 GMT 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