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."
how long (Score:4, Funny)
MESS (Score:5, Informative)
It's MESS [mess.org] you're thinking of, not MAME.
emulators? (Score:3, Interesting)
Any chance of an emulator being developed that can run this? Are the hardware specs open?
Re: (Score:2)
MULTICS ported to run on standard x86 hardware
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
As I said though, that doesn't make it really feasible
Re: (Score:2)
Why on earth wouldn't you be able to emulate x86(-64) on ARM?
I think you owe the Qemu guys some money: http://fabrice.bellard.free.fr/qemu/status.html [bellard.free.fr]
Re: (Score:3, Informative)
Of course it is. If you've got enough swap. Which you can plug into the Palm's USB connector.
Re: (Score:3, Insightful)
Well, yeah, of course it is. We are talking about emulating architectures, and the OP was saying that any general purpose architecture can emulate any other.
Whether or not any specific device will have the resources to run software targeted at any other specific device is, in fact, entirely irrelevant.
Re:emulators? (Score:4, Funny)
Re:emulators? (Score:5, Funny)
Re:emulators? (Score:5, Informative)
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*).
Emulating the Hardware (Score:5, Insightful)
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.
Re:Emulating the Hardware (Score:5, Funny)
Maybe it had a more magic switch [catb.org]?
Re:Emulating the Hardware (Score:5, Insightful)
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!"
oh good (Score:5, Funny)
Re: (Score:3, Funny)
"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)
Re: (Score:2)
Re: (Score:3, Informative)
If they're a government contractor, I'm sure they're anything but poor...
Re: (Score:2)
If they're a government contractor, I'm sure they're anything but poor...
Re: (Score:3, Funny)
Like it won't happen soon. (Score:2)
Currently taking bids on how long it will take.
Hey Microsoft! Read the source and weep... (Score:5, Informative)
Btw, it's "Multics" not "MULTICS".
Probably the best source for Multics-related information is this site. [multicians.org]
Re: (Score:3, Funny)
http://www.scribd.com/doc/3407/The-Last-Question [scribd.com]
Re: (Score:2)
But as an acronym, it's easier to deride it as:
Many Unusually Large Tables In Core Simultaneously.
It is MULTICS (Score:2)
Re:Hey Microsoft! Read the source and weep... (Score:5, Funny)
quickly reading the headline (Score:5, Funny)
Re:quickly reading the headline (Score:5, Funny)
Step 2... (Score:2)
you can't run it (Score:5, Funny)
innovation and performance (Score:5, Interesting)
Re: (Score:2)
Multics ran on the GE-600 series (Score:2, Insightful)
The wiki article has links to the programmer's reference manual and the instruction timings. Another issue is the care and feeding of the peripherals. Even so, given the reference manuals, it is hard to see why it is difficult to build an emulator.
The entire computer industry learned how to build PCs from the IBM technical reference. It looks to me like the same kind of information is available for the GE-600. So
Re: (Score:2)
emacs (Score:4, Interesting)
Re: (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?
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.
The real legacy of Multics (Score:5, Insightful)
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
Re: (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.
Re:The real legacy of Multics (Score:5, Informative)
Have a look at http://www.multicians.org/myths.html [multicians.org]
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
Re: (Score:3, Insightful)
I would say, instead, that we take it for granted that the OS should provide access to a disk file as a simple byte stream. I don't think there is consensus at all that there is one true way to implement a disk file, or whether that is even necessarily the job of the OS, as such, rather than replaceable modules, different sets of which may be found in use with any particular instance of the same OS.
Re: (Score:3, Insightful)
So basically you're saying that Multics's biggest accomplishments were all instructive mistakes? Not a ringing endorsement.
That is so middle-management brain, I'm almost speechless. From the perspective of career-advancement creditology, management oversight of the Multics project might not have been a double plus good on the resume. From the point of view of the technical people wrestling to reduce what was formerly impossible to annoyingly difficult, Multics might have produced some great moments of clarity on which forms of complexity to accept and which forms of complexity to reject and eliminate. Far too many projects
Re: (Score:3, Interesting)
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.
Mass commenting (Score:5, Insightful)
It ran on (Score:2)
From the supernatural hardware dept. (Score:5, Insightful)
Turing disagrees.
Mod parent up (Score:5, Informative)
Not "simplified" (Score:4, Funny)
Re: (Score:2)
and.....Multics for the Many, Unix for the One. I was waiting for you to point this out. Thanks.
Re:Not "simplified" (Score:4, Informative)
To make it even more amusing, meditate on the fact that most of what was chopped out of MULTICS to make UNIX was....the security related stuff!
Yes, UNIX is actually a secure operating system with the security removed.
Possible? (Score:2)
Would they consider it cheating unless they use something more complex than a 2,3 Turing Machine?
very eloquently ; "LOL !" (Score:2)
The special hardware exists on 386s and later (Score:5, Informative)
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
Re: (Score:3, Interesting)
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.
Microsoft did this!! (Score:3, Funny)
The perfect emulator (Score:4, Funny)
A good source of Prior Art (Score:5, Insightful)
Re:A good source of Prior Art (Score:4, Informative)
Re: (Score:2)
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:Too Complicated to Run? (Score:5, Insightful)
Multics - Novel Ideas [wikipedia.org]
Re: (Score:2, Interesting)
Re: Too Complicated to Run? (Score:2)
If anything, I would guess that a large part of MULTICS is simply written in assembler which makes it hard to port, but I doubt it. I don't really know that much about MULTICS, but I've gotten the idea that PL/1 is to MULTICS as C is to Unix.
Re: (Score:3, Informative)
True; this way you can attach a shared library into your code ("text") and data segments. However, if you think about the wikipedia article, you see that the Multics model differs from Unix method substantially. Process A can request pieces of Process B linked into it, then call the linked in piece of code and actually read and modify the pages which belong to Process B (using the code of Process B). You can't
Re: (Score:3, Informative)
Re:Too Complicated to Run? (Score:5, Insightful)
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.
Re:Too Complicated to Run? (Score:4, Informative)
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.
Re:Too Complicated to Run? (Score:5, Informative)
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)
Re: (Score:3, Informative)
Re: (Score:2, Informative)
Re: (Score:2)
Re:Too Complicated to Run? (Score:5, Insightful)
Re: (Score:3, Insightful)
You might run into issues between IBM's dialect of PL/1 and whatever dialect MULTICS is written in (there were at one point a bunch of incompatible versions), but compilers still exist.
Some of the big IBM machines can still run really crusty software in various binary-emulation modes; you might be able to dig up an ancient IBM PL/1 compiler and get it to run, if 'modern' compilers have
Re: (Score:3, Informative)
The compiler is still actively supported by IBM too, though not quite as much as COBOL compilers. Not much new code is written in PL/I in my workplaces, but it still happens on occassion. Either way PL/I is a pretty easy language to learn, easier than COBOL IMHO. Any C programmer should be able to write basic PL/I in a week.
Re: (Score:3, Insightful)
Re: (Score:2)
One issue was that Multics was running on hardware that didn't have bytes but 36 bit words [wikipedia.org]. Since performance was critical with the low compute power of the day, somebody somewhere is bound to have relied on sepcific bit trickery that assumes exactly that word size. Moreover, I would gess that certain performance critical of the OS parts were written in assembly to begin with, and obviously there is no special hardware out
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: (Score:2, Informative)
Comment removed (Score:5, Informative)
Father of Unix? (Score:5, Funny)
Re: (Score:2)
Re: (Score:3, Informative)
MULTICS and GCOS both ran on variations of the same hardware (The G in GCOS used to be GE as in General Electric -- Honeywell kept the acronym when they bought GE's computer operation).
The GCOS field in
Re: (Score:2)
Re:Father of Unix? (Score:5, Funny)
Puns count, but eunuchs don't tend to contribute lots of genetic material themselves.
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...? ;-)
Re: (Score:3, Funny)
Okay, I really don't want to continue this analogy.
May I suggest... (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
Re:I'm always happy to see something opened, but.. (Score:5, Funny)
Re:I'm always happy to see something opened, but.. (Score:3, Insightful)
Re:I'm always happy to see something opened, but.. (Score:2, Funny)