MIT Releases the Source of MULTICS, Father of UNIX

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."

Comments

innovation and performance

[downix]

I've never messed with a Multics system, but reading the code is facinating for me. Finding out about a dynamically changeable system, where you could plug in drives, CPU"s, and even RAM on the fly, amaazing stuff. In many ways, the design was more innovative than what we have today.

KISS

[fm6]

UNIX can in fact be considered to be a 'simplified' successor to MULTICS.

Which is precisely why Unix matters and MULTICS doesn't. The simplifications in Unix are its most important contribution to the art of OS design. For example, we now take it for granted that the OS should implement a disk file as a simple byte stream, with bigger structures, such as records or indexes, being implemented on the application level. But when Unix appeared, that idea was novel and controversial.

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.

Re:Too Complicated to Run?

[suitti]

Multics requires hardware support for it's security model, probably the dynamic linking, etc.

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:Too Complicated to Run?

[AKAImBatman]

I'm sure if you stubbed out the parts requiring the special hardware and replaced them with software implementations you could probably get it to work, but that would require some effort in essentially updating the OS.

=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:Father of Unix?...or NT

[cburley]

I understand that MULTICS is the father of Primos

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...? ;-)