Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!paperboy!osf.org!coren
From: coren@osf.org (Robert Coren)
Newsgroups: comp.unix.wizards
Subject: Re: Why not Multics? (was Re: BSD tty security, part 3: How to Fix It)
Message-ID: <21639@paperboy.OSF.ORG>
Date: 3 May 91 14:30:46 GMT
References: <3096@cirrusl.UUCP> <15896: Apr2714:35:3991@kramden.acf.nyu.edu> <542@trux.UUCP> <1991Apr30.142053.2313@sctc.com> <00673160066@elgamy.RAIDERNET.COM>
Sender: news@OSF.ORG
Organization: Open Software Foundation
Lines: 66

In article <00673160066@elgamy.RAIDERNET.COM>, elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes:
|> Multics suffered from Honeywell Brain Damage. First of all, by the time the
|> commercial implementation was released, the hardware was totally obsolete
|> (the hardware being a late 60's GE mainframe with a bunch of bags hung on
|> the side to implement the segmentation and ring security). Worse
|> than obsolete, it was also very expensive. Second, Honeywell didn't know
|> what to do with the Multics OS once it was completed. Most of their
|> customers were already using GECOS on the un-bagged version of the
|> mainframe, had all their aps already running under that environment, and
|> saw no reason to change. And, finally, Honeywell was in business to sell
|> hardware, not operating systems. Unlike Bell Labs, which really wasn't in
|> business at all, much less the hardware business. Thus Multics was
|> intimately tied to Honeywell's hardware, to the point where many portions
|> of the system would munge on pieces of 80-bit pointers or, for that matter,
|> were written in ALM (Multics assembly language, a truly horrendous beast...
|> I seem to recall that it had more than 500 instructions, dealing with all
|> sorts of bags on the side ranging from the address unit to the decimal
|> unit).

Wellll.....

Granted the hardware was pretty dreadful -- and Honeywell never did
seem to learn that it sold software. But you might try getting your
detailed facts straight. Multics pointers were 72 bits (not 80); very
little (~ 5%) of Multics was written in ALM, and most of the truly
grotty complicated instructions were avoided.

|> About the only really user-friendly software that ran on the
|> machine was an excellent version of Emacs written at MIT, as far as I know
|> the first version of Emacs that integrated Lisp into the editor (actually,
|> it was a compiled Lisp and PL/1 program that dynamically linked to the
|> MacLisp interpreter).

I think you may be using a curious definition of "user-friendly".
We're talking about a time period (late 70s/early 80s) when no
operating system did anything to speak of with graphics. If you want
to compare the "user-friendliness" of the Multics command interface
with UNIX's, I'll take Multics any day. Single-character "flags", each
of which is guaranteed to mean something different to each command?
Give me a break.


|> Unfortunately, the antiquated Multics front-end
|> hardware was so inefficient at handling user interrupts that running Emacs
|> slowed terminal I/O to a crawl... the Multics front-end hardware really was
|> designed for an era in which complete lines were typed in on a teletype and
|> then processed upon hitting RETURN.

Although this got somewhat better as time went on (we put as much
smarts into front-end software as we could), yes, this was another
piece of hardware limitation that Multics was burdened with all its life.

|> 
|> Datedness and poor marketing were what eventually did Multics in.

Mostly the latter, I claim. To imply that Multics was already "dated"
when it first became commercially available (1973) is grossly misleading.

|> I recall hearing rumors that someone
|> was going to try to port it to a non-Honeywell machine, several years ago.
|> As far as I know, those rumors have gone nowhere.

I don't know where the rumors have gone (they still seem to be
floating about the net :-)); the efforts (there was more than one) to
get cooperation from Honeywell for such a port never got anywhere.
	Robert