dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (05/01/91)
In <1991Apr30.142053.2313@sctc.com> stachour@sctc.com (Paul Stachour) writes: >Gee, with that kind of understandings, its no wonder that those of >us who have used Multics are kind of upset when we are forced to migrate >to systems where [non-Multics things happen]. So why are we all using UNIX and its derivatives? Why isn't Multics a commercial success even though it seems to have a unique place in history? More specifically, where can we buy Multics to run on our favorite hardware? Why can't we buy it? Inquiring minds want to know. -- Rahul Dhesi <dhesi@cirrus.COM> UUCP: oliveb!cirrusl!dhesi
exspes@gdr.bath.ac.uk (P E Smee) (05/01/91)
In article <3096@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >In <1991Apr30.142053.2313@sctc.com> stachour@sctc.com (Paul Stachour) writes: > >>Gee, with that kind of understandings, its no wonder that those of >>us who have used Multics are kind of upset when we are forced to migrate >>to systems where [non-Multics things happen]. > >So why are we all using UNIX and its derivatives? Why isn't Multics a >commercial success even though it seems to have a unique place in >history? Mostly because of internal politics at Honeywell. (Trust me, I worked there.) Centered around an internal power struggle (after HIS bought GE's large computer division) between the group that had been in Honeywell, and the group that had been bought in with the GE purchase. Honeywell finally took the machine off the market a couple of years ago because it wasn't selling. Not surprising that it wasn't selling, as they never really tried to sell it. HIS sales reps were, for example, given quotas of GCOS machines to sell, but no quotas for Multics sales. Some sales branches didn't even know about them. When University of Southwestern Louisiana decided they wanted to buy a Multics (because they used some MIT-developed courses) they called up their local HIS sales office and said they wanted a Multics. The sales rep they got replied along lines of 'Multics? Someone else must make that. This is HIS, we make GCOS machines.' USL actually had to put in a fair amount of work just to convince the salesman to check and see if HIS did have such a product. (In the end, they got one, but my friends there said it was clear the sales rep didn't like the idea, because it didn't count towards his sales quota.) When HIS stopped producing Multics, a number of companies expressed interest in acquiring the system source code so that they could take over production. (Building compatible hardware would have been fairly easy, as the requirements were well documented.) These included both a small (hypothetical) startup company mooted by a friend of mine (who had solid venture capital backing lined up), CDC I believe, and for sure (and ironically) HIS' French 'subsidiary', CII/Bull. For a while HIS looked like they might go for the idea, but then they backed down and stated that they would not release or sell rights to the source code. Most of the system bowels were developed under government contract and so were in the public domain, but most of the tools, compilers, utilities, ... were not. The would-be takeover groups felt (probably rightly) that they could not implement a profitable Multics replacement in reasonable time if they had to reimplement the entire user interface and support levels from scratch. This last bit explains why the concepts still show up everywhere, but the system itself does not. A lot of us feel that having to move from Multics to anything else represents a giant step backwards. Unix is just about OK. (There are, in fact, SOME things that Unix does better. There are a very large number where it falls short. My current annoyance is with the limitations on Unix access control, but that's another story.) (Followups directed to alt.folklore.computers.) -- Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132
igb@fulcrum.bt.co.uk (Ian G Batten) (05/01/91)
In article <3096@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: > So why are we all using UNIX and its derivatives? Why isn't Multics a > commercial success even though it seems to have a unique place in > history? The anecdote that I heard was that this was a typical interaction with an HIS salesman: Customer: Now about Multics, should I look at it? HIS SM: Multics is a fine product to which we are totally committed. Now about the GCOS box you were going to buy. It was always said that the Multics and GCOS people in Phoenix barely spoke to each other, and GCOS had the ear of the management. It always needed hacked hardware (ie DPS8/M rather than DPS8). In the seventies I believe the market for batch --- for which Multics is not best suited --- was larger than that for large scale timeshare (for which it is still the finest thing seen). > More specifically, where can we buy Multics to run on our favorite > hardware? Why can't we buy it? I know that someone (who I suppose should be named by those who know the current position rather than me) tried to buy Multics from Honeywell. I never heard quite what the outcome was, or what he was planning to do about hardware. The death knell was when the DPS8 successor (DPS88? DPS9? I forget) didn't have a /M derivitive. I heard theories as to how much magic would be needed to make it run on a modified 386 platform, but there would be an awful lot of FIXED BIN(25) declarations to change. Sad day when I stopped using Multics. Sad day. ian
coren@osf.org (Robert Coren) (05/01/91)
In article <Z}F_HC=@uzi-9mm.fulcrum.bt.co.uk>, igb@fulcrum.bt.co.uk (Ian G Batten) writes: [a pretty accurate description of why Multics was never a major commercial success.] As a member of the Multics development team for many years, I can give a bit of an "inside" view. Multics was, in fact, regarded by most of Honeywell's marketing as competition for GCOS (which had a much larger customer base), and, especially in the early years (1973-78 or thereabouts) a prospective customer had to push pretty hard to get someone to sell him one. |> It was always said that the Multics and GCOS people in Phoenix barely |> spoke to each other, and GCOS had the ear of the management. It always |> needed hacked hardware (ie DPS8/M rather than DPS8). Yes, each of the various machines that ran Multics at one time or another was a "modified" version of the then-current GCOS machine, and it often took a while to get the modifications shaken out. There was a project (or at least a "study") started in about 1983 to design and build hardware specifically targeted for Multics, but its funding was cut before anything real happened. |> > More specifically, where can we buy Multics to run on our favorite |> > hardware? Why can't we buy it? |> |> I know that someone (who I suppose should be named by those who know the |> current position rather than me) tried to buy Multics from Honeywell. I |> never heard quite what the outcome was, or what he was planning to do |> about hardware. There were a couple of attempts to interest Honeywell (and then Honeywell Bull --> Bull HN) in a deal whereby an entrepreneur would take it off their hands and concentrate on selling just Multics, but nothing ever came of it. Honeywell was never willing to completely let go. [It's not entirely clear that such an effort would have been commerically viable in any case.] There are a few Multics systems left in the world, and Bull has contracted with a company in Calgary named ACTC (Advanced Computing Technology Centre?) to provide maintenance (I'm a little hazy on the details of this deal). I don't think you can buy it from Bull anymore (they've stopped making DPS8/Ms); maybe you can pick up a used one at a "distress sale" :-). |> I heard theories as to how much magic would be needed to make it run on a |> modified 386 platform, but there would be an awful lot of FIXED BIN(25) |> declarations to change. I assume that's a typo for "fixed bin(35)"; likewise "fixed bin(17)", "bit(18)", "bit(36)", etc. Multics ran on 36-bit hardware, and in fact was not designed to be portable; there were a number of explicit and hidden assumptions about the capabilities of the hardware. Making a portable version of Multics would have been a *big* job. Even simply porting it to some specific 32-bit machine would have been a major undertaking. |> |> Sad day when I stopped using Multics. Sad day. |> Indeed. But, as it turns out, there *is* life after Multics (something I might not have believed 7 or 8 years ago). Robert
smith@sctc.com (Rick Smith) (05/01/91)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >So why are we all using UNIX and its derivatives? Why isn't Multics a >commercial success even though it seems to have a unique place in >history? Because Honeywell owned it and their marketing types didn't understand it, and it competed against the big, dumb IBM 7094 clones that Honeywell was selling in competition against IBM 360/370/30xx, etc boxes. Perhaps the marketing geeks figured that since IBM didn't design MULTICS, it mustn't be a real system. People held strange beliefs back then. >More specifically, where can we buy Multics to run on our favorite >hardware? Why can't we buy it? It ran on custom hardware. Some people say, "In Unix, everything is a file." In MULTICS, everything was a segment. It took special memory management hardware to make segment handling run efficiently. But a crucial thing to remember is that MULTICS was designed to meet several requirements that Unix failed to seriously address until quite recently. Security especially. And it's hard to retain "classic Unix" when you are trying to incorporate a new requirement with such vast ramifications. Rick. smith@sctc.com Arden Hills, Minnesota
car@trux.UUCP (Chris Rende) (05/02/91)
From article <3096@cirrusl.UUCP>, by dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi): > In <1991Apr30.142053.2313@sctc.com> stachour@sctc.com (Paul Stachour) writes: > > So why are we all using UNIX and its derivatives? Why isn't Multics a > commercial success even though it seems to have a unique place in > history? > > More specifically, where can we buy Multics to run on our favorite > hardware? Why can't we buy it? > > Rahul Dhesi <dhesi@cirrus.COM> > UUCP: oliveb!cirrusl!dhesi Problem number one is that Multics requires cetain support from the hardware that it is running on. A normal Honeywell DPS8 could run GCOS, but not Multics. Multics requires the addition of an "appending unit". This unit adds extra security "stuff" to the CPU. Things like ring brackets, etc... Other computers don't have these custom features that Multics requires. Problem number two is that Multics was written for a 36 bit architecture. Since Multics was invented in the 1960's, portability wasn't a big thing yet. It would be a pain to port the 36 bit, 17 bit, and 72 bit stuff over to today's 32 bit world. Problem number three is Multics' size. Multics was designed to be everything to everyone at the same time. That means that it has all-the-nice-OS-features- that-you-would-ever-want-and-known-to-mankind builtin to the system. That makes Multics quite huge in terms of RAM, disk, and CPU usage. The creators of Unix chose the opposite path: small is beautiful. So, they took out things like access control lists and gave us rwxrwxrwx instead. With the advent of smaller computers it became possible to fit Unix on a smaller computer. Smaller computers poped up all over the place. Since there was no way to put Multics on the smaller computers, people used Unix instead. (Or MSDOS, etc...). The fun part is that even low end computers aren't so small any more. And there is enough extra RAM, disk, and CPU time to add this or that feature to Unix. Over the course of time we will probably add back into Unix everthing (and more) that was carved out of Multics in the first place. Unfortunately, it will likely be a hack job. This is where Multics had the advantage: Multics was clean and consistent from top to bottom. For example, the command line switch "-all" means <<all>> for all commands. And, for all commands, "-a" is short for "-all". car. -- Christopher A. Rende Central Cartage (Nixdorf/Pyramid/SysVR2/BSD4.3) uunet!edsews!rphroy!trux!car Multics,DTSS,Unix,Shortwave,Scanners,UnixPC/3B1 car@trux.mi.org Minix 1.2,PC/XT,Mac+,TRS-80 Model I,1802 ELF trux!ramecs!car "I don't ever remember forgetting anything." - Chris Rende
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/02/91)
From article <3096@cirrusl.UUCP>, by dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi): >>Gee, with that kind of understandings, its no wonder that those of >>us who have used Multics are kind of upset when we are forced to migrate >>to systems where [non-Multics things happen]. > > So why are we all using UNIX and its derivatives? Why isn't Multics a > commercial success even though it seems to have a unique place in > history? > > More specifically, where can we buy Multics to run on our favorite > hardware? Why can't we buy it? 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). Multics wouldn't run on non-Honeywell hardware, unlike Unix, which was a multi-machine OS almost from the beginning. When Honeywell did the crash-and-burn with their Multics marketing, there wasn't anybody around to take up the slack. No Sun Microsystems equivalent to turn Multics into something ubiquitous in its market segment (like Sun did for Unix and workstations). There did exist some other problems, of course. For one thing, some aspects of the Multics design were inherently less efficient than "normal" design practices (things such as the dynamic linking, where the first run of a program would produce a whole lot of traps to pull in routines from other segments). The OS was big, for another thing (one reason why it was so late to be released), and somewhat resource-hungry for its day (though "X" puts it to shame any time of the day). The PL/1 compiler did a decent job of optimizing for its day, but the underlying architecture was the pits to begin with (a single accumulator? sheesh!). And of course the whole OS was designed in the late 60's and early 70's, and it showed... there were some half-hearted attempts at MIT and elsewhere to bag on support for graphics terminals and such, but a real professional job of it was never accomplished. 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). 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. Datedness and poor marketing were what eventually did Multics in. Both are probably attributable to Honeywell's befuddlement at what to do with an OS that didn't "fit in" with their existing lineup. One can assume that they would have eventually updated both the hardware and the OS if Multics had turned out to be a "best seller", or, for that matter, if they'd ever come up with a marketing slant on what to do with the silly machine. As it turned out, they sold a few to the DoD (it was the most secure system in the world for quite some time, perhaps still is), a few to universities here and there, and that was it. Multics-inspired derivatives live on here and there. A friend describes Primos as "what Multics would have looked like if designed in the USSR". The folks at Stratus (fault-tolerant computing) made their system look a lot like Multics. I seem to recall that Apollo's Domain OS stole a few things here and there from Multics, also. But Multics in its original conception seems to be dead, period. 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. There's few current architectures which could adequately handle Multics in its full segmented and ring'ed glory, anyhow... the '386/486 family come to mind as the most obvious. -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg Looking for a job... tips, leads appreciated... inquire within...
coren@osf.org (Robert Coren) (05/03/91)
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
exspes@gdr.bath.ac.uk (P E Smee) (05/04/91)
Gosh, a 'Multics' response from someone I don't recognize offhand. :-) I agree with most of your points, but there are a couple I'd like to try to 'clarify' -- or maybe put another viewpoint on. In article <00673160066@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: >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... 72-bit pointers, actually. :-) By the end, very little of the software was in ALM, the vast majority in portable PL/1. Opinions varied on how easy it would port to a different word length, but my opinion was that making it work shouldn't be too bad, but making it efficient might be. For example, any 36-bit ints would have been declared either fixed bin (35) or fixed bin unsigned (36). On a 32bit machine, you just need a compiler that will perform whatever kludges are necessary to make you a 36 bit integer field using (presumably) 2 32-bit words. Then, in parallel with checking that it works at all, you could have a team running through to convert such declarations as didn't REALLY need 36 bits. (Most int's were declared to take 18 bits (fb(17) or fbu(18)), so the waste in converting to a 32-bit machine would have been less dramatic.) The instruction set was nothing to write home about (something only a mother could love), for all the reasons you mentioned. (The above, by the way, is a feature of PL/1 which I wish C had, as I think it aids portability no end. You declare a variable in a form which actually tells how many bits or digits of precision you need, and it's up to the compiler to find you a piece of the machine big enough to hold it. None of the worries about 'how many bits in an int', which take up so much space in this group. You say 'I need 19 bits', and it's up to the compiler to either find it, or tell you that's too big for the implementation.) >When Honeywell did the >crash-and-burn with their Multics marketing, there wasn't anybody around to >take up the slack. No Sun Microsystems equivalent to turn Multics into >something ubiquitous in its market segment (like Sun did for Unix and >workstations). There were, however, people who expressed interest in trying.. >There did exist some other problems, of course. For one thing, some aspects >of the Multics design were inherently less efficient than "normal" design >practices (things such as the dynamic linking, where the first run of a >program would produce a whole lot of traps to pull in routines from other >segments). The OS was big, for another thing (one reason why it was so late >to be released), and somewhat resource-hungry for its day (though "X" puts >it to shame any time of the day). There were also compensations. It was a point of pride for the dev team that they managed to get so much efficiency out of such crude hardware. There was even a GCOS emulator, which would allow you to run GCOS programs under Multics. Many GCOS applications ran faster in the emulator than under native GCOS, primarily because the 'segment' mechanism DID allow simulations of GCOS I/O to run faster than real GCOS I/O. The mechanism also had a REALLY nice feature (which could bite), in that it amounted to what are now called 'shared libraries' but which could be personalised in whole or in part. If you didn't like the way printf made things look, for example, you could write your own version of printf (making sure its args and return values worked the same), put it somewhere in your PATH, and every time ANY program (your own or part of the system) made a printf call in your process, it would use your version rather than the standard one. Contrarily, if you found a bug in the date-printing routine (as a developer) you could install a fixed version of the date-printing routine into the system, and it would automatically, no muss, 'fix' the problem in every program which called that routine. (This capability goes a long way to explaining why there were a LOT of system subroutines supplied, which you were expected to use AS DOCUMENTED for virtually any primitive task. The goal was to minimize the number of things you had to touch to fix any given problem. Compare that with what would be required to get a new version of, say, atoi() into every program on a Unix system that uses it.) We were REALLY happy when HIS announced it was finally going to actually design a set of Multics hardware from scratch; and equally down when they cancelled the project. >Multics-inspired derivatives live on here and there. A friend describes >Primos as "what Multics would have looked like if designed in the USSR". >The folks at Stratus (fault-tolerant computing) made their system look a >lot like Multics. I seem to recall that Apollo's Domain OS stole a few >things here and there from Multics, also. All three of the named companies were, at least in their early stages, staffed by tech people hired away from HIS. (Most of whom left because they liked Multics, but perceived earlier than the rest of us that HIS would never be persuaded to like it.) Not surprising you can find so many Multicious concepts in them. :-) This is all a bit far from unix.wizardry, but the issues are the sorts of things that I think the Unix developers should at least be thinking about. Picking up a few more Multics concepts (the correct few, of course) could really add to the power of the Unix beast. -- Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132
rickert@mp.cs.niu.edu (Neil Rickert) (05/04/91)
In article <1991May3.170518.14757@gdr.bath.ac.uk> P.Smee@bristol.ac.uk (Paul Smee) writes: > [ much discussion on Multics deleted ] >(The above, by the way, is a feature of PL/1 which I wish C had, as I >think it aids portability no end. You declare a variable in a form >which actually tells how many bits or digits of precision you need, and >it's up to the compiler to find you a piece of the machine big enough >to hold it. None of the worries about 'how many bits in an int', which >take up so much space in this group. You say 'I need 19 bits', and it's >up to the compiler to either find it, or tell you that's too big for >the implementation.) On the contrary, it seriously detracts from portability. Very few peoply really think about their algorithms to the extent that they will really decide that they need 19 bits. More likely they will define there needs in terms of what is needed to represent shorts or longs (18 and 36 bits in your example) and this reduces portability. Furthermore the semantics of PL/1 in its use of bit precision is such that even when a standard 32 bit word is used, FIXED BIN (31) is not equivalent to FIXED BIN (27) - just look at how division is handled. This means that a standard library package must have versions for every conceivable way that an integer could be reasonably defined. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
smith@sctc.com (Rick Smith) (05/04/91)
elg@elgamy.RAIDERNET.COM (Eric Lee Green) wrote a pretty good article, with lots of stuff about why MULTICS died, giving particular attention to its grotty hardware requirements and intrinsic incompatibility with what everyone else was doing with hardware to support OSes. Then he goes on to gripe about the interface... >there were some >half-hearted attempts at MIT and elsewhere to bag on support for graphics >terminals and such, but a real professional job of it was never >accomplished. About the only really user-friendly software that ran on the >machine was an excellent version of Emacs written at MIT, ... Now, I first encountered MULTICS just about ten years ago, having come off of TENEX, RSX, RT-11, Unix-V6-and-a-half, and various other dogs and cats. As far as "user friendliness" goes, MULTICS was equivalent and usually better than the competition. It sure beat Unix back then, though NED _was_ a terrific editor. Even PCs (mostly called "home computers" back then) were overwhelmingly line oriented. There were some wonderful technical fantasies out there (Alto, for instance) but it took another couple of years for workstations and decent graphics to be a major force. BTW, try using EMACS on a loaded KA-10... if you want to talk s.l.o.w... !! It ran much better on a loaded MULTICS, for "only" a few million bucks more. > And of course the whole OS was >designed in the late 60's and early 70's, and it showed... The same statement is true of UNIX and even of the Alto, which pioneered all those user-friendlyisms we see in modern window managers. Rick. smith@sctc.com
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/08/91)
From article <1991May3.184152.28644@sctc.com>, by smith@sctc.com (Rick Smith): > Now, I first encountered MULTICS just about ten years ago, having come > off of TENEX, RSX, RT-11, Unix-V6-and-a-half, and various other > dogs and cats. As far as "user friendliness" goes, MULTICS was equivalent > and usually better than the competition. It sure beat Unix back then, Granted. For most of Multic's life-span, it was far more user-friendly than the competition. Heck, at least it operated interactively, which was nice in an era where punched cards were still in vogue ("Can't waste those cycles waiting for user input, can we?"). By the time the end came, though... the times, they'd passed it by. One really needed thing was a standard display handling library. I don't remember whether one was ever written (something along the lines of termcap/curses), but if so, I never saw any software that used it. What Emacs used (a file full of MacLisp functions, one file for each available terminal, if I recall right) wasn't too accessible to PL/1 folks. Now, if Multics had continued to be developed... and if Honeywell had actually tried to SELL the stupid thing... the story probably would have been different. -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg
barmar@think.com (Barry Margolin) (05/10/91)
In article <00673676139@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: >One really needed thing was >a standard display handling library. I don't remember whether one was ever >written (something along the lines of termcap/curses), but if so, I never >saw any software that used it. You apparently haven't used Multics since about 1982. At about that time we introduced the Video System and the Menu Facility. The Video System is a curses-like library for doing windowed I/O to character-oriented display terminals. It includes a window_io_ I/O module that replaces tty_, implementing Emacs-style editing of input lines (complete with extensibility, with the extensions being writable in PL/I). The Menu Facility is a client of the Video System, and implements a pretty nice menu library. Both the Video System and the Menu Facility have subroutine interfaces for programs to use, and a command interface for exec_com scripts. When the Video System was released, a menu-oriented user interface to the mail system was included, and it was called Executive Mail (on the theory that non-technical users would use Multics for email if a simple UI were provided). Later there was a menu interface to the Forum conferencing system, called Executive Forum. These may have been the only released application programs that depended on the Video System (Emacs uses the Video System if it's turned on, but uses its own terminal description files when the terminal is in standard mode, because its programmed terminal descriptions are more powerful than the table-driven Video System), but I know that they were very popular in user-written applications (there would have been more shipped video applications if we included games in Multics releases). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
fetter@cos.com (Bob Fetter) (05/14/91)
In article <00673676139@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: > One really needed thing was >a standard display handling library. I don't remember whether one was ever >written (something along the lines of termcap/curses), but if so, I never >saw any software that used it. What Emacs used (a file full of MacLisp >functions, one file for each available terminal, if I recall right) wasn't >too accessible to PL/1 folks. There always was a terminal_type_tabel kept under >sc1>ttt, which had the terminal management information such as is kept in a Unix termcap file. Software could access it directly using the video_ i/o module, giving it requests like 'clear_screen', 'goto_xy', etc. Any software which used screen terminals on Multics made use of these functions. The 'window' system, which was a full-screen interactive environment did, and I'm *pretty* sure Emacs did too (but I'm probably off base on this one). >Now, if Multics had continued to be developed... and if Honeywell had >actually tried to SELL the stupid thing... the story probably would have >been different. Indeed. >-- >Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 >elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg -Bob-
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/15/91)
From article <45740@cos.com>, by fetter@cos.com (Bob Fetter): > There always was a terminal_type_tabel kept under >sc1>ttt, which had > the terminal management information such as is kept in a Unix termcap file. > Software could access it directly using the video_ i/o module, giving it > requests like 'clear_screen', 'goto_xy', etc. > > Any software which used screen terminals on Multics made use of these > functions. The 'window' system, which was a full-screen interactive > environment did, and I'm *pretty* sure Emacs did too (but I'm probably > off base on this one). Emacs didn't. I remember modifying the TVI912 MacLisp file to work with USL's hacked "USLTVI" modified TVI terminals (they had various codes and keys re-mapped to work well with Multics, but Emacs didn't know about that). Given the vast size of Multics, and the brief time in which I used it (maybe six months, at which time I was also learning how to program), it's little wonder that I never made it to >sc1>ttt :-). (Though I did encounter the 'window' system, now that I think of it... you have to remember that this was more years back than I like to recall :-}. >>Now, if Multics had continued to be developed... and if Honeywell had >>actually tried to SELL the stupid thing... the story probably would have >>been different. > > Indeed.
guy@auspex.auspex.com (Guy Harris) (05/16/91)
>(there would have been more shipped video applications if we included >games in Multics releases). Gee, just like 4.3BSD - most of the "curses" applications in 4.3BSD appear to be games, and half of the applications using "termcap" at all appear to be games, as determined by looking for "-ltermlib"/"-ltermcap" (which is used by all "curses" programs) in "/usr/src/*/Makefile" and "/usr/src/*/*/Makefile"): games linked with "-lcurses": battlestar canfield cribbage hangman hunt mille rain robots rogue sail snake worm worms games linked with just "-ltermlib" (or "-ltermcap", same thing): backgammon non-games linked with "-lcurses": "old" talk sysline systat talk non-games linked just with "-ltermlib" or "-ltermcap": clear crtplot dumbplot ex lpq more msgs tn3270 tset ul I haven't checked 4.3-tahoe nor 4.3-reno.