Slashdot Mirror
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."
Now we can comb the source to find all the places where Linux has stolen from MULTICS too. Give SCO a call, they can help out.
My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
A beowulf cluster of these bad boys running on emulated hardware running COBOL.NET applications under Mono!
Btw, it's "Multics" not "MULTICS".
Probably the best source for Multics-related information is this site.
you had me at #!
It is not yet known if it will be possible to emulate the required hardware to run the OS.
Run away! They're using reverse psychology!
"Let's tell the nerds that they can't run MULTICS on simulated hardware, and see how long it takes them to do it!"
>north
You're an immobile computer, remember?
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.
I beg to differ.
At the time of Multics people were just figuring out what a computer should do in an interactive time-sharing environment. People had lots of ideas, and since Multics was, fundamentally, a research OS, they threw them in. Only with experience could they decide which were the good ideas and which were the bad ones. They couldn't know, in advance, which were the winners. They had to try them and see. That is the legacy of Multics.
...laura
> It is not yet known if it will be possible to emulate the required hardware to run the OS.
Turing disagrees.
- For the complete works of Shakespeare: cat
There are two hard parts
Adresses and ints were 36 bits, longs were 72, and people used the 8th and 9th bits in in bytes for control and meta bits when manipulating raw terminal input.
Expect most of your problems will be with porting things like bit_offset_ entry (ptr) returns(fixed bin(24)) reducible
--dave (DRBrown.TSDC@HI-Multics.ARPA) c-b
davecb@spamcop.net
Its not an issue, modern hardware is so much faster than the hardware of the MULTICS era an interpreter can emulate the processor and the memory management in one go.
A bigger issue would probably be the 36 bit word but even that is just an efficiency issue. Memory is cheap and MULTICS era machines did not have many Mb.
The bigger question is why go to the trouble. The answer is prior art. MULTICS has been mined as prior art in patent disputes for decades. If its in MULTICS its out of patent.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Since MULTICS is the father of ALL modern OSes (which would include that trash heap, Windblows) it should provide a multitude of algorithms and processes that people are now trying to Patent and pass off as an Original Invention. This is a very good piece of history. Some people would rather you forget where you came from so they can take advantage of you in the marketplace.
Nope. The I/O hardware that the Level/68 system used was an extremely complex independent beast. (Think of SCSI (small computer systems interconnect) on steroids... since, uhh, Multics wasn't a "small computer system," but quite the opposite.) The documentation that survives is widely scattered; the few (insufficient) pieces that have been scanned and can be found on the web are at bitsavers. Much will likely have to be reverse-engineered.
I've been working on an emulator for a number of years. This article very good news, because it will make it easier for other people to get involved. (Note: don't bother trying to play with the emulator, because it is very... non-functional thus far. If you're interested in helping out, please do read everything at multicians.org, start following alt.os.multics, skim through everything on bitsavers, and then drop me a line *grin*).
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
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...? ;-)
Practice random senselessness and act kind of beautiful.