paragraphs by THVV unless indicated
Many statements about Multics on the Web and USENET are partly or completely incorrect. This note lists some of the most common myths and provides more accurate information.
- Myth: Multics failed in 1969 Bell Labs quit, Multics survived.
- Myth: Multics failed Multics met its goals.
- Myth: Unix was operational before Multics. False.
- Myth: Multics was big and slow. True at first.
- Myth: Multics was vastly expensive You get what you pay for.
- Myth: Ken Thompson wrote Multics Ken was one of many.
- Myth: Multics was built by the waterfall method Closer to spiral method.
- Myth: Multics was closed source We shipped with source.
- Myth: MULTICS was designed with military security in mind. MLS was a separate project.
- Myth: You had to give a password to log out. User app, terminal locker.
- Myth: Multics error messages were in Latin. One was.
- Myth: A 10 year old job. False.
- Myth: Multics used multiple processes per user, and a two process debugger. Never true.
- Myth: Every procedure executed in Multics consumed two segment numbers, one for code and one for linkage. Only pre-production.
- Myth: The Multics file system provided a "trap" access control attribute. Never true.
- Myth: Multics was the first interactive timesharing system. CTSS, BBN, JOSS, SDC, DTSS, Berkeley.
- Myth: Multics was the first system to use virtual memory. Atlas, Burroughs.
- Myth: Multics was the first system written in a high level language. Burroughs B5000.
- Myth: Multics was "virus proof." Very virus resistant.
- Myth: Multics never needed to shut down for maintenance. Part way there.
Myth: Multics failed in 1969
"...the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier." Dennis Ritchie, The evolution of the UNIX time-sharing system, Bell System Technical Journal 63, 8, Oct 1984.
"A group of four Bell Labs programmers continued on in their efforts, however, and worked to create a system that would succeed where Multics had failed. They named their operating system UNIX." Kevin Martin, Pair Networks Insider, "History of FreeBSD," Sept 2001
"MULTICS failed, but it did inspire Ken Thompson, who was a researcher at Bell Labs, to have a go at writing a simpler operating system himself." Dr William J. Knottenbelt, Class notes, Intro to Unix , accessed Dec 2002
"1969 Unix is born at Bell Labs to replace the failed Multics operating system" anonymous, , accessed Dec 2002
"Thompson and Ritchie were pulled out of the original MULTICS collaboration after the failure of 1966/7 era hardware to support its implementation" anonymous, Wikipedia, "Unix," accessed Dec 2002
"The MULTICS project was abandoned. The GE 645 system was too slow and proposals for new equipment were rejected as too expensive." anonymous, "Linux Overview" , accessed Dec 2002
"Commercial development of the MULTICS project is abandoned after four years intense development. Multics involved MIT, GE and Bell Labs in an attempt to build a large scale time-sharing system for computer utilities." Prof. Thomas Haigh, ST297 Readings Timeline , accessed Dec 2002
Germ of Truth
From Bell Labs' point of view, Multics did fail to produce the timesharing system they wanted when planned.
Bell Labs joined the Multics effort in 1965 through a "murky process" [Vic Vyssotsky] and chose to withdraw a few years later. Their goal in joining was to obtain a timesharing system for use by members of the technical staff at Bell Labs. When the planned time had passed, Multics was not ready to use, and it was clear that there was a lot more work to do. Bell was paying rent on its GE-645 and dedicating valuable people to the Multics effort, and continuing would continue these costs with no trustworthy end date. They opted out in 1969.
MIT and GE/Honeywell continued development of Multics. MIT began using Multics for "paying" academic and research customers in October 1969, and continued to run a Multics system for almost 20 years. Honeywell and its affiliates developed a new generation of hardware for Multics, announced it as a commercial product in 1973, marketed it until the mid 80s, and got several hundred million dollars worth of revenue from Multics.
The Multics project certainly didn't fail in 1969. It suffered a disappointing setback when Bell departed, but the project continued, the operating system continued to exist, to be used, and to grow and evolve, for many more years.
Myth: Multics failed
"The roots of UNIX date back to the late 1960s. Ken Thompson joined Bell Labs in 1966 in the Computing Research Department, which is when he started working on the Multics project, a very ambitious effort to create a next-generation portable operating system that eventually failed. " Ken Milberg, UNIX turns 40, Article in IBM DeveloperWorks, accessed 03 Dec 2009
"Bell Labs pulled out of the project when Multics displayed signs of bloating into an unusable white elephant (the system was later marketed commercially by Honeywell but never became a success). " Eric Raymond, Open Sources, date?, also in Jargon file
"Multics, a terrific and influential failure. Once upon a time in the mid-Sixties, three companies, MIT, Bell Labs and General Electric, decided to create a "computer utility" sort of like a power company, which would provide computing resources to an entire city or area. Their project, called MULTICS for Multiplexed Information and Computing System, was a failure due to the enormity of the project and the vast budget overruns." anonymous, canisius.edu, "A Short History of Unix", accessed Jan 2003
Germ of Truth
Multics didn't sell to as many customers as its builders and advocates had hoped. Honeywell Bull stopped development of the system in 1987. No Multics sites are now running. The last one shut down in October 2000. (An open source Multics simulator is available.)
[JWG] Bull canceled Multics development after 21 years. Multics continued to be used by customers for an additional 14 years. In several cases, the lengthy period of use after cancellation was needed to find and develop the capabilities provided by Multics on other systems.
Dick Hill's story of Honeywell corporate politics shows how the cancellation of the system had nothing to do with its technical abilities or its sales: it simply had no champion in the executive suite.
In Corby's Turing talk, he said, "That Multics succeeded is remarkable for it was the result of a cooperative effort of three highly independent organizations and had no administrative head." I could stop right there. Corby, our leader, said we succeeded. He also said,
"we were misled by our earlier successes with previous systems such as CTSS, where we were able to build them "brick-by-brick," incrementally adding ideas to a large base of already working software.
We also were embarrassed by our inability to set and meet accurate schedules for completion of the different phases of the project. In hindsight we should not have been, for we had never done anything like it before. However in many cases, our estimations should have been called guesses.
The UNIX system  was a reaction to Multics. Even the name was a joke. Ken Thompson was part of the Bell Laboratories' Multics effort, and, frustrated with the attempts to bring a large system development under control, decided to start over. His strategy was clear. Start small and build up the ideas one by one as he saw how to implement them well. As we all know, UNIX has evolved and become immensely successful as the system of choice for workstations. Still there are aspects of Multics that have never been replicated in UNIX.
As a commercial product of Honeywell and Bull, Multics developed a loyal following. At the peak there were about 77 sites worldwide and even today many of the sites tenaciously continue for want of an alternative."
Concerning "bloating:" our pre-implementation design of Multics was too complex, and we spent great effort in the first few years of development on simplification and major optimizations (e.g. single sized items in most system structures, binding, single process per user, mini-shell, etc.) and in the early 70s with hardware support for rings and string processing. These transformations were largely accomplished by the mid 70s. See below.
As described in the 1965 paper Introduction and Overview of the Multics System by Corbató and Vyssotsky, there were nine major goals for Multics:
|Convenient remote terminal use.||Met. Set the standard.|
|Continuous operation analogous to power & telephone services.||Partially met. Never as reliable as power and phone.|
|A wide range of system configurations, changeable without system or user program reorganization.||Met. A single system boot tape worked on any Multics configuration. User programs were insulated from the configuration.|
|A high reliability internal file system.||Met. First modern file system.|
|Support for selective information sharing.||Met. Set the standard.|
|Hierarchical structures of information for system administration and decentralization of user activities.||Met. Still the fanciest.|
|Support for a wide range of applications.||Met.|
|Support for multiple programming environments & human interfaces.||Met.|
|The ability to evolve the system with changes in technology and in user aspirations.||Met. Continued to evolve for over 20 years.|
Berkeley Tague, who worked on Multics at Bell Labs, wrote "Multics was one of the seminal efforts in computing science and operating system design. It established principles and features of operating system design that are taken for granted today in any modern operating system."
(Further concerning "bloating," it is fair to remark that some of the more baroque features of the MSPM design and early implementation, say 1966-67, were provided by Bell Labs members of the team. The multi-process shell design, the concept of an I/O system general enough to support an online peripheral oil well, and some of the initial concepts for core allocation come to mind.)
[JWG] Multics met the goals it originally set out to meet. In addition, it had modest commercial success, and many of the customers used it for a wide range of to-them mission-critical applications for which there were no suitable alternatives available.
Multics had a degree of (marketing) success in the late 1970s and early to mid 1980s. Those successes were followed by (marketing) failures, for many reasons. It's a long story.
There's no way to get around it: we failed to attain permanent success. People are now using other systems.
So, did Linux version 1.0 fail? Few if any people are now using it.
Myth: Unix was operational before Multics
"an early version of UNIX was operational several months before MULTICS" Garfinkel and Spafford, Practical UNIX & Internet Security date?
Germ of Truth
Unix first execution in 1969 may have preceded the first use of Multics at MIT for "paying" users in October 1969.
This is comparing apples and oranges. The Multics Phase One milestone was the first time Multics actually worked. This came in late 1967, years before Unix was started; Ken Thompson and Dennis Ritchie were working on Multics then.
Multics was self-hosting since late 1968; that is, system programmers used Multics to work on Multics.
Myth: Multics was big and slow
"... development of an operating system called Multics which aimed to improve the performance of multi-user time-sharing computer systems. But the resultant system was too big and too slow, so Bell labs withdrew leaving the computing science group without a computer." Mr. Liam Madden, www.ee.ic.ac.uk, Unix for the first time , accessed Dec 2002, now missing
"In the 1960?s, several monopolies teamed up to create the greatest operating system that never was. General Electric, MIT, and Bell Labs collaborated on the 'Multics Project' -- a fast, efficient operating system. The trouble was, Multics was too big. It didn't fit well on any existing hardware. (Just like IBM's OS/360 -- bloat, bloat, bloat.) Multics solved many engineering problems in software, but did too many things. " Bill Leahy, Intro to Object Oriented Programming , accessed Dec 2002, now missing
"Bell Labs wasn't quick to oblige them, however. Multics was one of the biggest hogs for system resources and had grown out of control during its development there. The administration didn't want to see another Multics happen so long as they were alive." Nick Moffitt, Nick Moffitt's $7 History of Unix , accessed Dec 2002
Germ of Truth
Multics was slow in its infancy, like many systems. The story "How Many Users?" describes how slow it was before initial release. This is the performance that Bell Labs observed in the late 1960s.
In the 1990s, Multics was still running at several sites on obsolete and comparatively slow hardware.
There's a time skew here: often people talk about the problems of the 60s and apply then to the Multics of the 70s and 80s, a much more mature system on different hardware.
Multics (then) was small compared to e.g. Linux and Windows (now). (The Multics "kernel" was about 250K SLOC in 1983. The Linux kernel was > 4.5M SLOC in 2002.)
Multics was big compared to (most) of its peers in the 70s, and there were those who thought it too big to ever build. But it did get built, and met its objectives. Now, it seems remarkably lean compared to systems such as Windows.
On slow hardware, with many users, Multics was slow. And the ability to easily build much bigger programs than on other systems led users to demand more.
Multics was slow compared to less capable systems: for example, DTSS could run many more users, each typically using a 16K (words) memory partition. A Multics process was much bigger.
Multics won many competitive benchmarks, showing that it out-performed other systems that could do what Multics did. For example, we won USGS, EOP, DND, Bell Canada, and multiple university site benchmarks.
[MND] Part of this myth may also stem from Multics being written in a high-level language. Today, this is commonplace, but in the mid-60s to 70s, an OS written in a HLL would, a priori, be judged to be big and slow. Especially since Multics was written in PL/I, which had the reputation of itself being big and slow. Of course, the quality of code produced by the compiler improved significantly over time.
(Monopolies. What's up with that? What was MIT a monopoly of? GE had a lot of divisions but I don't think it was a monopoly of anything. Maybe Bill is thinking of Western Electric.)
Myth: Multics was vastly expensive
"$6M/yr for 5 years" Prof. Eric Brewer, Berkeley, Berkeley CS262 Lecture Notes , accessed Dec 2002
Germ of Truth
Perhaps this figure was estimated from $2M/yr for all of Project MAC from ARPA and "comparable" from BTL and GE, but MAC included a lot of other research activities, and BTL/GE budgets would be hard to pin down.
I think this is high; I wrote Eric to ask where he got the number; he can't remember.
(Should get the Kenneth Flamm book and see what it says.)
Writing operating systems is expensive. The Multics effort had fewer people than teams for other comparable systems. The Multics team had maybe 150 developers at its largest, counting all organizations. IBM had thousands of programmers working on OS/360. There were over a thousand working on IBM TSS, according to Lynn Wheeler.
Myth: Ken Thompson wrote Multics
"If I remember my UNIX history correctly, Ken Thompson wrote MULTICS, which was supposed to be a multi-user OS. However, it failed quite miserably at the multi-user level." Mike Digdon, Dalhouse University, Halifax NS, , unix-wizards mailing list, 1992
"Ken Thompson, co-author of Multics" anonymous, IC Selection Guide article on Unix , accessed Dec 2002, now missing
Germ of Truth
Ken worked on Multics.
Ken was a respected equal, one of about 25 members of the Bell Labs Technical Staff who worked on Multics in 1965-1969.
Ken was a great programmer. He didn't write all of Multics. He contributed a piece to it, like a lot of others.
Myth: Multics was built by the waterfall method
"Multics, in contrast, was a painstakingly planned and coordinated system of enormous ambition." Prof. Thomas Haigh, Review of Multics and Multicians web site , Oct 2002
Germ of Truth
1. We wrote 3000 pages of the Multics System Programmer's Manual first, while waiting for the PL/I compiler promised by BTL. Some of this was science fiction. (One early I/O System design section mentioned the "on-line peripheral oil well.") Other parts of it provided high level functional specs for facilities we never built. Other parts had low-level PL/I declarations of code that might or might not compile.
2. People working on Multics were paid to do so, and had managers who directed their efforts. We thought before we coded.
Painstakingly planned and coordinated? That's not how it felt at the time. We wrote planning documents, not to too great a level of detail, but the implementation often departed from the original plan. Most projects were carried out by small teams, one or two people, who designed and implemented an improvement to the current version of Multics. Our process was more like the "spiral" process, iteratively discovering requirements and implementing partial solutions. As described in "The Multics System Programming Process", we
- Defined the problem. In its purest form this was done in a white paper, repository document, or MCB/MTB. (e.g. MTB-017.) That is, a document that divided this problem from all the other possible problems.
- Spent some time working out the "ideal" solution. Designers often wrote MSPM sections in the early days; later an MCB or MTB describing the problem and its ideal solution. Often the ideal solution was impractical. Sometimes we built a prototype anyway, tried it out, and measured its problems.
- Criticized and refined the initial design, and selected a subset of the ideal solution for first implementation, through a series of design and management conversations. The revised design was ideally documented in MSPM sections or MCBs or MTBs, but not always. Sometimes, after publication of an MTB, we held design review meetings and published follow-up MTBs describing issues raised and their solution. Depending on the size of the project, more or fewer documents would be written. This was the exciting part.
- Obtained formal project approval for the feature. At first, this was from Bob Daley. Later, from the Multics Change Review Board. There might be iteration at this point. In order to get approval from the MCR Board, draft user documentation was required and reviewed.
- Implemented, debugged, and tested a first version. More design iteration happened sometimes during this process, and sometimes additional design documents were produced. If major changes to the original design developed during coding, additional MCRs were sometimes submitted.
- Had the code reviewed by at least one other team member. This process, known as "auditing," often resulted in rewrites for better maintainability and reliability.
- Submitted a change request form to the system integration team. The "yellow form" required signoff from the code auditor, the documentation group, and the development manager. (Later these submissions were done electronically using Multics.) The integration team rebuilt the code, ran a standard bemchmark to check that system performance wasn't hurt, and installed it on the exposure system. (This is important: programmers couldn't push code into the integration system; the integration team pulled it in, and could reject a change that didn't work.) User-ring changes could be installed while the exposure system was running; hardcore changes were packaged as an MSS system. One or two MSS systems a week for hardcore changes was a typical rate.
- Observed how the new code worked in practice, and repeated the process to enhance it, to simplify the design, to meet new or newly understood requirements, or to implement more of the original ideal.
- Released large batches of changes and documentation to external customers in an MR system, about once a year.
Naturally a one-line bug fix went through a streamlined version of this process, and a large project elaborated on it. The Data Management project, for instance, had at least 40 MTBs associated with it.
In effect, our practice tried to treat all development, new features and bug fixes alike, as incremental maintenance, somewhat like the current development practices for Linux, but with fewer players: e.g. the distribution team was part of the same organization as the development team.
IBM had thousands of people working on OS/360. The Multics software development team, counting everybody, was barely over a hundred at peak. Of these, a small group led development.
During the initial development of the system, one person, Bob Daley, was the chief development engineer. He decided how things would be implemented and what features were in and out. He decided whether to spend time speeding up a module or live with it. etc. When Daley left for RCA, the MCR Board was formed.
Understandable wrong impression, since it wasn't written up anywhere. Need to correct web site.
Myth: Multics was closed source
"Multics died mostly from being proprietary and running on proprietary hardware." anonymous poster, Slashdot posting
Germ of Truth
Multics source is not GNU licensed. The hardware was proprietary.
Our original plan was for Multics to be open and portable. In "Introduction and Overview of the Multics System" (1965), Corbató and Vyssotsky write:
It is expected that the Multics system will be published when it is operating substantially and will therefore be available for implementation on any equipment with suitable characteristics. Such publication is desirable for two reasons: First, the system should withstand public scrutiny and criticism volunteered by interested readers; second, in an age of increasing complexity, it is an obligation to present and future system designers to make the inner operating system as lucid as possible so as to reveal the basic system issues.
Bull HN has made the entire source available "for any purpose and without fee" at MIT as of November 2007.
[MND] It may be helpful to point out that Multics predates the GNU project. Using contemporary definitions of open source to judge software from the mid-60s to 70s is comparing apples to oranges.
[Joachim Pense, Mainz] The source was delivered together with Multics. There even existed a "library_fetch (lf)" command that provided easy access to the source of any multics program. As most of the source was written in well-structured and well-commented PL/1, it was a real source of knowledge. Info segment for library_fetch command.
It's open now.
Myth: MULTICS was also designed with military security in mind
"MULTICS was also designed with military security in mind, both to be resistant to external attacks and to protect the users on the system from each other. By design, Top Secret, Secret, Confidential and Unclassified information could all coexist on the same computer: the Multics system was designed to prevent information that had been classified at one level from finding its way into the hands of someone who had not been cleared to see that information. Multics eventually provided a level of security and service that is still unequaled by many of today's computer systems -- including, perhaps, Unix." Garfinkel and Spafford, , Practical UNIX and Internet Security, 2003, page 12.
Germ of Truth
Security was important from the beginning, and Project MAC was funded by ARPA. Classification features were added later.
Multics inherited the notion from its CTSS roots that hardware-enforced security is much more reliable than security provided by software alone.
There was never any discussion of military-style classification when the fundamental Multics security mechanism was being designed. (The Ware Report, which discussed security controls for computer data, had not been written yet. Descriptor-based security supported by ACLs is very different from the military system. Multics rings of protection are hierarchical, but work differently from the military classification hierarchy.
Military security, Top Secret and so on, was added in the mid-70s, by Project Guardian's introduction of the Access Isolation Mechanism. Because Multics security centralized the security enforcement, adding additional rules to the access mechanism was an extension to the existing design. The article B2 Security Evaluation describes the evolution of Multics security.
[JHS] If one interprets "military security" to mean "multilevel security", then the myth is false. If one interprets "military security" to mean military-strength security, then the picture changes a bit: Ted Glaser (who was a consultant to the National Security Agency) wanted Multics to have security that was good enough that it could be used in military and even NSA applications. He advocated ACLs as being a close match to the military security principle of need-to-know. Ted's security design principle, again arising from a military security perspective, was that you can't add security later, it has to be designed in from the beginning.
Ted Glaser's military-inspired approach to security motivated the Multics team to use a rigorous approach to security design. Multics did not add military-style classification features till the mid 70s.
Myth: You had to give a password to log out
"among other things, on some versions one was commonly required to enter a password to log out." Eric Raymond, , Jargon file, accessed Dec 2002
Germ of Truth
There was an author-maintained command at MIT called lock_console (lkc).
If somebody ran lock_console, then you had to give the password so you could issue a command. (This kept people from "putting you on the cookie monster" if you stepped away from your terminal.) You could hang up the phone to disconnect the current session, and then reconnect and log in.
The same situation is true now, if you set a screen saver password on your Windows, Mac, or Unix box: you have to give a password in order to log out.
Myth: Multics error messages were in Latin
"GE's Multics system used Latin for all error messages; the intent was that this would prevent the end users from trying to outsmart the system, and would encourage them to call the adequately trained support staff to determine the nature of the problem." Peter Seebach, , Article in IBM DeveloperWorks, Feb 2002
Germ of Truth
It happened once: see Hodie Natus Est Radici Frater.
As described in Bernie's story, one "can't happen" message did happen, when the hardware was broken, and his Latin message appeared, and I got called at home at 6AM on a Saturday morning.
The rest of the story is completely fabricated. Multics provided English error messages, with considerable care taken to make the wording understandable. The stuff about the "intent" is completely wrong. There was no such intent. There was no such practice. (Further evidence that the writer had no idea what he was talking about is seen in the phrase "GE's Multics." Honeywell had taken over the GE computer division for over seven years when the event in question happened.)
Seebach writes, "I wasn't trying to be funny, but I was apparently mistaken; I can't recall where I got this originally; it would have been from one of two or three sources, and I'll go poke around and find out where I got it."
Myth: A 10 year old job
"In Multics, shut down machine, found 10-year-old job" (On a slide about schedulers, and how some jobs might be starved forever.) Prof. John Kubiatowicz, Berkeley, Lecture notes for Berkeley course CS162, accessed Oct 2015
Germ of Truth
On an overloaded system, processes that run a long time between interactions would sink to the bottom of the scheduler queues and make no progress.
This sounds like an urban legend. There's no evidence that it ever happened, no site is specified, and the terminology used doesn't sound like Multics.
Besides, when a Multics system is shut down, the scheduler queues are discarded. There would be no way to find a process that was starved out of completion. And no Multics system I ever heard of had an uptime of 10 years.
The only "job" concept in Multics was the facility to submit an "absentee job" with a list of commands. That wouldn't be relevant to a scheduler starvation discussion.
Myth: Multics used multiple processes per user, and a two process debugger.
Technical Report IR-LP-31-21, September 1989, The Design and Implementation of a Two Process Prolog Debugger, Diomidis Spinellis
Germ of Truth
Elliott Organick's 1972 book, The Multics System: An Examination of Its Structure, gives this impression.
This scheme was designed and described in the MSPM, but never used. Processes in Multics were heavyweight, and their creation was quite expensive. As a result, a much simpler scheme was devised that created one process per logged-in user, and ran procedures within it. The debugger was customarily invoked and the procedure to be debugged run "under" it, in the sense that the debugger's stack frame was an ancestor of the procedure under test.
Myth: Every procedure executed in Multics consumed two segment numbers, one for code and one for linkage.
Germ of Truth
Elliott Organick's 1972 book, The Multics System: An Examination of Its Structure, gives this impression.
This scheme was used briefly but abandoned before the system was put into service, in favor of copying linkage section templates for each procedure executed into a per-ring Combined Linkage Segment. This method handles multi-ring execution and unlinking cleanly and conserves segment numbers.
The "KST story" mentioned by Dennis Ritchie is a similar bug in pre-production versions of Multics, fixed early.
Only during pre-production.
Myth: The Multics file system provided a "trap" access control attribute.
Making PEACE a Dynamic Alterable System (1990) Henning Schmidt EDMCC
Germ of Truth
The initial paper on the Multics file system, A general-purpose file system for secondary storage, says that we planned to do this.
The paper describing the trap attribute was written before we implemented the file system. When we came to actually code this feature, we discovered a fundamental problem: it was difficult, in the one-process-per-user Multics model, to run the trap procedure in a correct security context. Running it in the referencer's context would create a Trojan Horse -- referencing a file could cause arbitrary code to be executed. Creating a separate context would be extremely costly. We deferred the implementation while we thought this problem over, and eventually abandoned the trap attribute idea altogether.
Myth: Multics was the first interactive time-sharing system
"A group at the Massachusetts Institute of Technology made the first attempt at developing an Operating System that could provide multiple users with interactive processing. The name of the Operating System was Multics. For the first time different types of Programs could be run simultaneously, and immediate response to typed-in commands was possible." email@example.com, , , accessed Dec 2002
Germ of Truth
Myth: Multics was the first system to use virtual memory
"The Michigan Terminal System (MTS), along with Multics at MIT, were the first operational virtual memory operating systems in the world." David L. Mills, , , accessed Dec 2002
Germ of Truth
MTS was made available to the UM campus in May 1967.
The Atlas system had a paged virtual memory before Multics or MTS.
The Burroughs B5000 had segmented virtual memory before Multics or MTS.
The Rice Institute Computer was the first machine with a segmented memory architecture, before Multics or MTS.
Myth: Multics was the first system written in a high level language
"Multics was the first major OS written in a High Level Language. Multics and Algol represented the best the world had to offer in software technology in the early 70's." Chuck Flink, , accessed Dec 2002
Germ of Truth
The Burroughs system for the B5000 was written in Algol and preceded Multics.
Flink, above, gives the impression that Multics was written in Algol. This is wrong also. Multics was written in PL/I.
Myth: Multics was virus proof
"Back in the 1970's and early 1980's we knew how to build operating systems that were rock solid and virus-proof. How long will we have to wait for someone to re-invent MULTICS with a GUI on top of it?" Marcus Ranum, Computer Security: An Utter Failure , May 11, 2006.
Germ of Truth
Multics was more secure in the 70s than most systems are today.
If you tricked a Multics user into running a program you supplied, you could take over his account and do anything he could do. The Cookie Monster Story makes this clear. Such a compromise would affect only one account on a Multics machine, not the whole computer, unless the account belonged to a highly privileged user. System maintainers and administrators were serious about maintaining the security of the installation. In contrast, modern PCs are often administered by users who have little concern for system security, and who install untrusted code.
The Multics mail programs did not provide "convenience" features for automatic execution of programs mailed to the user, or interpretation of structured content such as graphics. The Multics architecture is more resistant than current popular systems to misbehavior such as buffer overflows: PL/I string operations respect the length of the target string, the stack grows toward higher addresses instead of lower, the stack and data segments are non-executable, the hardware checks supervisor arguments, etc. But implementation mistakes in the security mechanisms could still happen.
One reason for the Multics mandatory access control feature was to prevent a rogue program from leaking sensitive data. Even with the use of the Access Isolation Method, timing channels were still a concern.
Virus resistant, but not virus proof.
Myth: Multics never needed to shut down for maintenance
"During a previous boom, General Electric designed a mainframe that it claimed would be sufficient for all the computer uses in Boston, and would never need to be shut down for repair or for software tweaks. The machine it eventually built wasn't nearly big enough, but it did succeed at running continuously without need for hardware or software changes."
"The real continuous approach comes from Multics, the machine that was never supposed to shut down and that used controlled, transparent change.... if an interface took more than one parameter, all the parameters were versioned by placing them in a structure with a version number. The caller set the version, and the recipient checked it." Paul Stachour and David Collier-Brown, You Don't Know Jack About Software Maintenance ACM Queue, Nov 2009
Germ of Truth
Dynamic reconfiguration let us do some hardware maintenance without shutting down. Non-hardcore modules could be updated while the system was running. Versioned interfaces were used in several interfaces.
Paul and David intended "a rather lighthearted look at various subject that people think they understand, but don't." Their article makes its point with wit and hyperbole, but it describes Multics features as if they were universal, when in fact they were applied in limited cases.
Multics dynamic reconfiguration allowed us to add and drop CPUs and memory, and later I/O controllers, while the system was running. Peripherals and disk drives could be added and removed dynamically. I don't think it was possible to do major I/O reconfiguration, such as adding a disk controller, without shutdown. Many serious maintenance operations did require shutdown and restart.
Replacing any module of the hardcore supervisor required killing all processes and restarting the OS. In part this was because the kernel "leaked" facts into the user process, such as TTY descriptors and I/O channel bindings. (I did some design work in 1980 or so on how we could make the system reboot without discarding old processes, but it never made it into the system.)
Some non-hardcore, non-daemon programs could be replaced while the system was running. We did this by renaming old modules and leaving them on disk, and installing new versions. New processes would get the new versions, while processes that had already linked to the old versions would continue to use those. (A Multics process usually lasted for a whole login session, unlike Unix, which creates a process for each command execution.) The "versioned interface" practice was used in a few Multics facilities, but was not widespread.
David writes: "In fact, Multics started us on the path to solving the problem, and took us surprisingly far. The continuous change algorithm in the article is indeed a Multics approach, circa 1984. There is a brief mention of it in the "Level 68 Standards, System Designers' Notebook" (1980), p 2-6, a book I use to this day to guide my Java programming (;-)) "
We got part way there.
Readers may also enjoy Michigan Terminal System Myths and misconceptions.