MIT Releases the Source of MULTICS, Father of UNIX 276
mlauzon writes "Extraordinary news for computer scientists and the Open Source community was announced over the weekend, as the source code of the MULTICS operating system (Multiplexed Information and Computing Service), the father of UNIX and all modern OSes, has finally been opened. Multics was an extremely influential early time-sharing operating system and introduced a large number of new concepts, including dynamic linking and a hierarchical file system. It was extremely powerful, and UNIX can in fact be considered to be a 'simplified' successor to MULTICS. The last running Multics installation was shut down on October 31, 2000. From now on, MULTICS can be downloaded from an official MIT site (it's the complete MR12.5 source dumped at CGI in Calgary in 2000, including the PL/1 compiler). Unfortunately you can't install this on any PC, as MULTICS requires dedicated hardware, and there's no operational computer system today that could run this OS. Nevertheless the software should be considered to be an outstanding source for computer research and scientists. It is not yet known if it will be possible to emulate the required hardware to run the OS."
Too Complicated to Run? (Score:1, Interesting)
emulators? (Score:3, Interesting)
Any chance of an emulator being developed that can run this? Are the hardware specs open?
Re:Too Complicated to Run? (Score:1, Interesting)
innovation and performance (Score:5, Interesting)
emacs (Score:4, Interesting)
KISS (Score:5, Interesting)
The fact is, Unix was a fresh start, and a damned important one. Unix's creators' biggest accomplishment was clearing out all the feature crud and creating a simple model that has influenced computer science on many levels.
MULTICS, by contrast, was doomed by its own complexity. The fact that Unix was created from the ashes of Bell Labs' participation in the MULTICS project is just a historical accident.
Source? (Score:3, Interesting)
Looking at random files, I see copyright notices dated 2006, so how can this be a dump from 2000?
See the bottom of http://web.mit.edu/multics-history/source/Multics/tools/install_volume_backup.ec [mit.edu] for example.
Re:Too Complicated to Run? (Score:2, Interesting)
Re:Too Complicated to Run? (Score:5, Interesting)
Certainly, a Multics machine emulator could be written. Such an emulator would run circles around the original hardware. Multics was not written in an era of gigabytes of RAM. So, a Multics emulator could keep an entire emulated machine in RAM on a pocket computer today, like a $99 Palm. Such an emulator might not be hard to write.
Re:The real legacy of Multics (Score:3, Interesting)
Yeah, yeah, i know, other OS's have been ported. Windows and VMS on Alpha. CP/M on the 8086 and 680000. Mac OS on PPC. But Unix variants are everywhere.
My MULTICS experience (Score:4, Interesting)
I started college at the University of Birmingham in Edgbaston (near Birmingham), England in 1986. They had a MULTICS installation and on my registration day the university computer club took those of us interested in it to a terminal room to show us the ropes.
The guy hit a key to get a login prompt. During the half-hour we were there the system did not manage to cough up even the prompt, so we got no demo. I never tried again.
Instead I got involved in the local programming going on in my department (Mechanical Engineering) and hence learned about Turbo Pascal on PCs and then Apollo workstations running their unix-like Domain OS - much better.
My final year project was an emulation of part of a mainframe/multics graphics library to the Apollo workstations so that the large deformation finite element analysis software they were developing could work entirely on the workstations, bypassing the central computing facilities entirely. They were already able to split jobs up and run work packets across multiple CPUs on the network. The combined computation performed by their workstation network was already outperforming their slice of the central mainframe. Before my project however they still had to transfer the output files over to the multics system so they could use the nice high speed plotters that the computer center had. With my project they could finally get nice large engineeering plots made locally.
If I recall correctly I provided a "GINO" emulation library that output large F/E plots as CAD symbol files which could be read by the "DOGS" CAD system they had. My memory is rusty on any more details than that. It was very cool to be involved in that, even if it was all in FORTRAN 77.
So I like to think I helped kill off Multics (if only infinitesimally).
An emulator should be feasible (Score:3, Interesting)
You don't have to emulate the entire machine in every last detail. You only have to emulate those pieces of it that the OS talks to. You can also get away with not emulating the error detection and reporting features of the architecture any more than is required to deal with normal operation; the emulator will not encounter a failing instruction, for example.
The biggest problem in getting it running is much more likely to be getting the software into a form the emulator can execute. There are binary images on the site; if those are enough to bootstrap your way into a running system, then the problem is manageable - you only have to create an emulated disk image that contains the files in the form that MULTICS expects to see. If you have to recreate things from source, you wind up having to build a cross-compiler - a much harder task.
I'd love to see it running. It's possible, but a lot of work. There does seem to be a dedicated MULTICS crowd on the net, and I won't be at all surprised to see them take on the job.
Re:Too Complicated to Run? (Score:5, Interesting)
=OR= we could get someone to develop an FPGA version of the MULTICS system. The machine was big, but today's FPGAs should be able to encapsulate all the hardware services originally available to the system. Certainly there's enough room for the CPU, a controller for a 2MB stick of RAM (though it might need to be larger to support 36-bit words if the chosen RAM is only byte addressable), and an interface to a Flash drive or hard disk. Tack some terminal hardware on the PCB and you're golden.
Never underestimate the modern potential for recreating old hardware.
Re:"It is not yet know if the hardware can be (Score:1, Interesting)
ftp://ftp.stratus.com/pub/vos/multics/pg/mvm.txt [stratus.com]
"The 635 and 645 also had instructions to execute single
instructions or pairs of instructions. These could be used to
ensure atomicity as well; interrupts would happen only after the
instruction, or pair of instructions, had completed. Yet on the
645 these instructions could also take linkage, segmentation, or
page faults...and these faults were restartable! The 635 and 645
repeat (and repeat-double) instructions WERE interruptible, but
only after each instruction or pair of instructions. As a
result, the 645 machine state information was considerably larger
and more complex than the 635 machine state. The ability to
handle interrupts and/or restartable faults during these
particular instructions is arguably the hairiest aspect of of the
(pre-6180-EIS) hardware design, and was the source of many subtle
hardware bugs."
Either instruction of a two instruction pair could be intruped by a page fault, and could be restarted.
1. Very reliable.
2. Some times slow.
3. extremely flexable.
But as the author states...it was the sounce of many subtle hardware bugs.
You could take a linkage fault, stop the program. copy the library from tape into core, and restart the process! ( do THAT LINUX! )
Re:Too Complicated to Run? (Score:1, Interesting)
Additionally, I find it strange that in the paragraph you just quoted and the one before it, the article almost seems to complain that to do IPC in modern OSes, you don't do an ordinary call instruction into another process's address space. I'm pretty sure that x86 CPUs actually do let you do that, but it still seems like a pretty silly approach. Also given that most software isn't even written in assembly anymore, I don't see how it matters much in the end whether libc decides to use a call, int 80h, or a sysenter; it'll still wind up to the same thing.
Re:The special hardware exists on 386s and later (Score:3, Interesting)
Re:KISS (Score:3, Interesting)
Actually, Multics might well have killed Unix in its infancy. If the project had gone a little faster, Bell Labs might have stuck with it, and had no incentive to develop its own OS.
There's a lot of mythology about Multics, and you seem to have bought into a lot of it. Check out multicians.org for corrective details.
When I say "Multics doesn't matter" I mean it didn't have any accomplishments we should care about. You can read "doesn't matter" any number of ways, but I think it's pretty clear from context which way I meant it to be read.
Re:Too Complicated to Run? (Score:2, Interesting)
Amen! My Linux box has XMame, Mess, DOSBox, Wine, ZSNES, and SIMH. I can emulate anything from a Super Nintendo to a PDP 11 to an arcade cabinet Tron. Multics should show up in Ubuntu screenshots in oooohhh, about two months.
Well, as a user I kind of disagree (Score:3, Interesting)
From that point of view, it sure looked like a research OS. They were tinkering with the damn thing all the time, and it would have interesting new flaws and idiosyncrasies regularly, as well as be out of service at random intervals while they upgraded from version 35.6a to 35.6ab. If you wanted stability and reliability, you were expected to use the IBM CMS system.
I don't say that Honeywell didn't try to sell it as a regular system -- I vaguely recall Ford used it at one point -- but that may have been more of a bread on the waters, what the heck kind of thing to try to recoup some of their investments costs. My impression is that the people actually working on the system at MIT, at least, did not regard keeping the thing running and reliable as their top priority. If they thought of something new and nifty to try, they would.
Re:emacs (Score:3, Interesting)
I miss emacs on Multics. My first word processor, I wrote a lot of papers using it. Even today I catch myself typing emacs commands that only existed on Multics emacs.
Did you perchance happen to be using a MIT Space Cadet Keyboard [std.com] with that Multics system, or did you just enter your papers in using punch cards?
Re:emulators? (Score:2, Interesting)
So no, it's not possible to run Multics on any current hardware.
Is there a lot of good skullsweat in there nonetheless? Yes.
How long will those ideas take to get into Linux and *BSD?
I'm betting... about 3 months.
Kudos to the Groupe Bull people who got this done; I gather it took *most* of the last 7 years to clear it all.
Re:Father of Unix?...or NT (Score:5, Interesting)
Yes, I worked at Pr1me (in R&D) starting in early 1978, and during my interviews it was made quite clear they were designing PRIMOS to become "Multics in a (super-)minicomputer".
I think they already had ("real", not Unix-y) dynamic linking at that point, but only into PRIMOS itself. The ability to create dynamically linked libraries came with the introduction of the Executable Program Format (EPF, a bit like Unix's ELF I assume) in PRIMOS version 19.4, circa 1984.
Other cool things included full-featured signaling/exceptions — full-featured in the sense that a signal handler could re-signal the signal and then pass that new signal "up" the stack to earlier invocations to handle, which was helpful for handling interrupt (^P, akin to Unix ^C) and similar conditions; and recursive "shells", programmed in CPL, which I think stood for Command Procedure Language, which were to PL/1 as Bourne shell and its language was to C in the Unix world in terms of what they were trying to provide.
Oh, and a "transparent" network filesystem was both a blessing (when you really didn't care that the files and directories were remote) and a curse (when you actually did care but couldn't reliably figure it out), implemented initially via a client/server model using the underlying network protocols directly from within the kernel's filesystem and, later, via a Remote Procedure Call (RPC) mechanism the kernel offered to itself and to users.
(One of my own little hacks, which became reasonably popular in the R&D data center at least, was to write a SETIME utility that could be run on system startup, and which would query designated remote systems via RPC for their date/time in order to set the local system's date and time, as the hardware back then didn't have its own CMOS-ish clock and the OS wasn't really usable until the local date and time were set.)
I'm not so sure the transparent FS was Multics-inspired, but the folks doing much of the OS design (including CPL, EPF, and so on) definitely included many ex-Multicians who were enthusiastic (to say the least) about recreating their favorite OS features on a system that was selling like hotcakes.
Then there was the guy in Tech Pubs who kept going on about a completely different OS with a wacky name that ran on DEC equipment, had a "shell" (with a "case" statement that he tried to explain to me once), let users connect programs together with "pipes" and, for some weird reason, had all its program names and commands in lower case!! (Wonder whatever happened to that OS...? ;-)
With one of those I could toss the foot pedals... (Score:2, Interesting)