Forgot your password?
typodupeerror
Operating Systems Software Education Unix

MIT Releases the Source of MULTICS, Father of UNIX 276

Posted by Zonk
from the linux's-dad's-dad dept.
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."
This discussion has been archived. No new comments can be posted.

MIT Releases the Source of MULTICS, Father of UNIX

Comments Filter:
  • by Apple Acolyte (517892) on Tuesday November 13, 2007 @02:27PM (#21339137)
    Anyone know what makes the OS too complicated to run on today's most sophisticated hardware?
  • emulators? (Score:3, Interesting)

    by gEvil (beta) (945888) on Tuesday November 13, 2007 @02:29PM (#21339163)
    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.

    Any chance of an emulator being developed that can run this? Are the hardware specs open?
  • by Anonymous Coward on Tuesday November 13, 2007 @02:41PM (#21339341)
    No, they gave us the compiler that creates the binary from the source.
  • by downix (84795) on Tuesday November 13, 2007 @02:44PM (#21339423) Homepage
    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.
  • emacs (Score:4, Interesting)

    by FranTaylor (164577) on Tuesday November 13, 2007 @02:47PM (#21339475)
    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.
  • KISS (Score:5, Interesting)

    by fm6 (162816) on Tuesday November 13, 2007 @02:48PM (#21339483) Homepage Journal

    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.

  • Source? (Score:3, Interesting)

    by SnarfQuest (469614) on Tuesday November 13, 2007 @02:49PM (#21339509)
    (it's the complete MR12.5 source dumped at CGI in Calgary in 2000, including the PL/1 compiler)

    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.
  • by EvanED (569694) <evaned.gmail@com> on Tuesday November 13, 2007 @02:51PM (#21339539)
    What? That's not my understanding of how things work. Each process gets its own page table, which means separate permissions, no?
  • by suitti (447395) on Tuesday November 13, 2007 @03:08PM (#21339811) Homepage
    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.
  • by suitti (447395) on Tuesday November 13, 2007 @03:23PM (#21340045) Homepage
    If Unix gave us just what we need in an OS, then Version 7 Unix gave us an OS written in a way to ease porting to new hardware. We even booted Unix on Pr1me hardware. The bit that makes a pointer point to an even or odd byte is not the least significant bit in a Pr1me address.

    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.
  • by mihalis (28146) on Tuesday November 13, 2007 @03:29PM (#21340113) Homepage
    (when I last saw the word MULTICS in a computer room, it was definitely spelt that way - maybe they were wrong then).

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

  • by Jay Maynard (54798) on Tuesday November 13, 2007 @03:32PM (#21340151) Homepage
    Hercules [hercules-390.org] shows that it's possible to emulate hardware that's quite different from the usual PC on a PC-class machine and get reasonable performance out of it. Assuming that the source on the MIT page is complete, it should be possible to work from there, along with whatever hardware docs are available, to emulate enough of the machine to get MULTICS running.

    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.
  • by AKAImBatman (238306) <akaimbatman@@@gmail...com> on Tuesday November 13, 2007 @03:57PM (#21340531) Homepage Journal

    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. :)
  • by Anonymous Coward on Tuesday November 13, 2007 @03:58PM (#21340541)
    Ok. I found it. THIS IS WHY THE HARDWARE EMULATION IS SO FREAKING HARD:

    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! )
  • by Anonymous Coward on Tuesday November 13, 2007 @05:03PM (#21341437)
    No, the Wikipedia article doesn't explain why you are wrong about how the hardware works, because it doesn't even introduce your flawed argument in the first place. I read this section you pointed to and the Multics approach is in no way at conflict with the interfaces that PC hardware provides.

    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.
  • by SnarfQuest (469614) on Tuesday November 13, 2007 @05:27PM (#21341787)
    simh already handles 36 bit emulation for the PDP10. There is one eample to use if nothing else.
  • Re:KISS (Score:3, Interesting)

    by fm6 (162816) on Tuesday November 13, 2007 @06:03PM (#21342343) Homepage Journal
    I don't agree that without Multics, Unix wouldn't exist. And come to think of it, I don't agree that it was an influential negative example. Its main influence at Bell Labs was its failure to go gold soon enough for Bell Labs to adopt it for internal use. This left Thompson and Ritchie without an OS to work with and motivated them to write their own. They weren't looking for a way to squeeze Multics into their tiny PDP-8, they were doing original work, with their creativity energized by the very limitations of their working environment. Things like byte streams, pipelines, and device files aren't adaptations of Multics concepts, they're completely new inventions.

    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.
  • by Anonymous Coward on Tuesday November 13, 2007 @06:35PM (#21342731)
    "Never underestimate the modern potential for recreating old hardware. :)"

    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.
  • by Quadraginta (902985) on Tuesday November 13, 2007 @07:59PM (#21343681)
    I used Multics for a while at MIT, and even wrote some user documentation for it.

    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)

    by The_Dougster (308194) on Tuesday November 13, 2007 @10:23PM (#21344939) Homepage

    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)

    by jra (5600) on Tuesday November 13, 2007 @10:29PM (#21344999)
    The stock distribution ot Multics depends intimately on the memory segmentation and protection hardware of the Level/68 architecture.

    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.
  • by cburley (105664) on Wednesday November 14, 2007 @12:28AM (#21345947) Homepage Journal

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

  • Finally, a keyboard [std.com] designed for Emacs!

Ma Bell is a mean mother!

Working...