Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

MIT Releases the Source of MULTICS, Father of UNIX

Posted by Zonk on Tue Nov 13, 2007 01:24 PM
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."
+ -
story

Related Stories

[+] The Last Multics System Decommissioned 77 comments
Bell Would? writes: "A key feature of the brief news item, 'The end of the Multics era,' in the latest issue of the The Risks Digest is the 'list of goals' Multics had fulfilled which, as the author describes them, are as relevant today as they were 35 years ago." Odd -- I assumed these were all long since junked or put into museums, since my first exposure to the name Multics was in books which spoke mostly in the past tense. That list of goals is one that I hope architecture designers consult frequently.
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • how long (Score:4, Funny)

    by Trailer Trash (60756) on Tuesday November 13 2007, @01:26PM (#21339117) Homepage
    til I can run this under mame?
  • emulators? (Score:3, Interesting)

    by gEvil (beta) (945888) on Tuesday November 13 2007, @01: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?
      • Re:emulators? (Score:5, Informative)

        by orangesquid (79734) <orangesquid&yahoo,com> on Tuesday November 13 2007, @02:57PM (#21340525) Homepage Journal
        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 [bitsavers.org]. Much will likely have to be reverse-engineered.

        I've been working on an emulator [orangesquid.net] 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*).
  • by Unoti (731964) on Tuesday November 13 2007, @01:31PM (#21339187) Journal
    It is not yet known if it will be possible to emulate the required hardware to run the OS.

    Surely it's possible, it just may not be much fun or very practical. Unless perhaps that old hardware has some black boxes that talk to spirits or do other magic things.

  • oh good (Score:5, Funny)

    by colourmyeyes (1028804) on Tuesday November 13 2007, @01:33PM (#21339201) Homepage
    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.
    • Que the Empire references.

      "No Darl, (MULTICS breathing) I am your father."

      "No...that's not true. That's impossible!"

      "Search your feelings. You know it to be true."

      "Noooooooooooooooooooooooooo!"
  • Imagine... (Score:5, Funny)

    by Unoti (731964) on Tuesday November 13 2007, @01:35PM (#21339233) Journal
    A beowulf cluster of these bad boys running on emulated hardware running COBOL.NET applications under Mono!
      • Re: (Score:3, Informative)

        Already some poor government contractor is being asked to implement just that very system.

        If they're a government contractor, I'm sure they're anything but poor...

  • by toby (759) * on Tuesday November 13 2007, @01:35PM (#21339251) Homepage Journal

    Btw, it's "Multics" not "MULTICS".

    Probably the best source for Multics-related information is this site. [multicians.org]
  • by xrayspx (13127) on Tuesday November 13 2007, @01:36PM (#21339261) Homepage
    I thought they'd released the source code for Ken Thompson. Neat trick.
  • by meta coder (752563) on Tuesday November 13 2007, @01:41PM (#21339339)

    Unfortunately you can't install this on any PC
    it's seem like windows vista
  • by downix (84795) on Tuesday November 13 2007, @01: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, @01: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, @01: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.

    • by spaceyhackerlady (462530) on Tuesday November 13 2007, @02:02PM (#21339701)

      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.

      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

      • by fm6 (162816) on Tuesday November 13 2007, @02:38PM (#21340263) Homepage Journal

        Multics was, fundamentally, a research OS
        Not true. Two of the three partners in the project were Bell Labs and GE. Bell Labs wanted an OS their researchers could actually use, and pulled out when they decided that the project wasn't going to come together in a useful time frame. GE's mainframe division wanted a new OS to differentiate their products from other mainframes, and went on to sell a small number of MULTICS-based systems. Or to be precise, Honeywell, Groupe Bull, and NEC, who owned the former GE mainframe division in turn, sold them. The last MULTICS-based commercial system was discontinued in 1987. Doesn't sound like a "research OS" to me.

        Have a look at http://www.multicians.org/myths.html [multicians.org]
  • Source? (Score:3, Interesting)

    by SnarfQuest (469614) on Tuesday November 13 2007, @01: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 hoggoth (414195) on Tuesday November 13 2007, @02:03PM (#21339725) Journal
    > It is not yet known if it will be possible to emulate the required hardware to run the OS.

    Turing disagrees.
  • by Blackeagle_Falcon (784253) on Tuesday November 13 2007, @02:08PM (#21339809)
    Calling Unix a "simplified" version of Multics ignores one of the greatest puns in computer history. The name Unix was chosen because it's a castrated version of Multics.
  • by davecb (6526) * on Tuesday November 13 2007, @02:25PM (#21340067) Homepage Journal

    There are two hard parts

    1. Rings and ring-crossings, which are supported in intel hardware since the 286/386 era, and
    2. Long words, longer than 32 bits.

    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

  • by mihalis (28146) on Tuesday November 13 2007, @02: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 mihalis (28146) on Tuesday November 13 2007, @02:49PM (#21340389) Homepage
    In the "Dunnet" adventure game built-in to GNU Emacs there is a VAX cabinet. If you find the CPU board and plug it in the thing runs and you can logon to the system and even execute commands. So I think someone skilled in Emacs Lisp (certainly not me) should implement a MULTICS system inside this game also. Given the birthplace of the original Emacs, this would be somewhat ironic.
  • by AppleTwoGuru (830505) on Tuesday November 13 2007, @02:51PM (#21340417) Homepage
    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.
    • by Bozdune (68800) on Tuesday November 13 2007, @03:30PM (#21341005)
      Actually, the Compatible Time Sharing System (Corbato, et al, 1962 or so) is a better candidate for the father of all modern operating systems. CTSS, for example, continued to provide reasonable response to the other users even when a process went spinning in a tight loop. This is something that Windows still hasn't solved.
    • Well, one thing I wonder if there is useful stuff that is in MULTICS that the Linux community will look at and try to port into their OS

      While the source code of MULTICS hasn't been Free until now, the internals of the system were well-known. MIT even published a technical introduction [amazon.com]. The Free Software community has already realized all of what made MULTICS useful in its own projects, and this opening up of the code, far from revealing something useful to today's hobbyists, is really just for historical study.

    • by EmbeddedJanitor (597831) on Tuesday November 13 2007, @01:39PM (#21339317)
      How can MULTICS be called the Father Of Unix? Sure, Multics brought some interesting ideas to the party and qualifies for "Unix's Crazy Uncle MULTICS", but a close genetic connection is hard to see.
        • by cburley (105664) on Tuesday November 13 2007, @11:28PM (#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...? ;-)

    • by mikael (484) on Tuesday November 13 2007, @01:36PM (#21339265)
      It seems something to do with the way they implemented dynamic linking. Each executable/data page could be shared between multiple processes, with each process having a different set of permissions on that page. On current systems, the permission codes would be associated with that executable/data page, not the process itself.

      Multics - Novel Ideas [wikipedia.org]
      • by Zeinfeld (263942) on Tuesday November 13 2007, @02:46PM (#21340343) Homepage
        It seems something to do with the way they implemented dynamic linking. Each executable/data page could be shared between multiple processes, with each process having a different set of permissions on that page. On current systems, the permission codes would be associated with that executable/data page, not the process itself.

        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.

        • by SpinyNorman (33776) on Tuesday November 13 2007, @08:38PM (#21344561)
          MULTICS era machines did not have many Mb

          Indeed. We had a Honeywell Multics system at Bristol University, UK when I was there from '79-'82. The thing was impressively fast (it would compile small FORTRAN programs in no noticble time - type compile command, hit enter, and you got your prompt back), but nonetheless I recall Bristol getting a free HALF A MEGABYTE (a big deal at the time) memory upgrade from Honeywell to address performance issues.
    • by Fred_A (10934) <fred@NospAm.fredshome.org> on Tuesday November 13 2007, @01:36PM (#21339275) Homepage
      Pretty much the same thing that makes ZX Spectrum software "too complicatded" to run under today's most sophisticated hardware. i.e. it's not meant for that hardware and therefore won't run. Unless you write an emulator first (like one was written for the Spectrum) and run a binary image of the software on that.

      But then we need to find a binary image of the software and we only have the source. Is this a chicken and egg problem ? :)
    • Re: (Score:3, Insightful)

      by Anonymous Coward
      Nothing is impossible, but little things like 36bit words (not 32bit) are going to slow you down.
    • by suitti (447395) on Tuesday November 13 2007, @02: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.
      • 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: (Score:3, Funny)

      Ken Thompson, of course. Multics impregnated him with the ideas, he carried 'em to term and birthed 'em on a PDP-7.

      Okay, I really don't want to continue this analogy.
    • Re: (Score:3, Insightful)

      I can't tell if you were being sarcastic, or if that was a call for gender-neutral dialogue, but just in case: Women already have "Motherboard", "Mothership", "Daughter Cells", and personifications of cruise vessels; let the men have this one.