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

how long

[Trailer Trash]

til I can run this under mame?

Too Complicated to Run?

[Apple Acolyte]

Anyone know what makes the OS too complicated to run on today's most sophisticated hardware?

Re:Too Complicated to Run?

[orclevegam]

Sounds like it requires some specialized hardware. I think the point was more that you can't just drop it onto a current system and expect it to run. 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. Perhaps we'll see a MULTICS Modern release before too long.

Re:Too Complicated to Run?

[mikael]

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

Re:Too Complicated to Run?

[Fred_A]

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

[Anonymous Coward]

No, they gave us the compiler that creates the binary from the source.

Re:Too Complicated to Run?

[Anonymous Coward]

Nothing is impossible, but little things like 36bit words (not 32bit) are going to slow you down.

Re:Too Complicated to Run?

[EvanED]

What? That's not my understanding of how things work. Each process gets its own page table, which means separate permissions, no?

Re:Too Complicated to Run?

[PitaBred]

But what does the compiler run on? It's still a bootstrapping problem unless the PL1 compiler runs on an available architecture.

Re:Too Complicated to Run?

[Brian Gordon]

Presumably if someone knew enough about the hardware to write an emulator, they could easily write a modern compiler for whatever language the source is in..

Re:Too Complicated to Run?

[eggnoglatte]

Who said it was "too complicated"? TFA just said "dedicated hardware", i.e. different.

One issue was that Multics was running on hardware that didn't have bytes but 36 bit words. 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 there today that has the same machine language.

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?

[Akaihiryuu]

It sounds like it was written for the hardware of a particular series of mainframes and will not compile on anything else. The further back you go, the less abstraction there was, and the more code was written "to the bare metal" so to speak. Give it a week, then there will be a Slashdot article: "Multics ported to i386". There is NO reason that it can't be ported to any architecture, given enough interest. Someone will port it, just because they can.

Re:Too Complicated to Run?

[squiggleslash]

It's PL/I, which is actually a fairly established, if old, language. Ye olde CP/M (including Atari's TOS and DR's GEM windowing system) is written in a subset called PL/M. I seriously doubt there'll be a problem finding a PL/I compiler.

Re: Too Complicated to Run?

[Dolda2000]

I can't verify if there is any other argument, but what you are describing is definitely not true. In current Unices, mmap can map the same file with different permissions from process to process.

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

[Anonymous Coward]

There's even someone working on a GNU Compiler Collection (GCC) frontend for PL/1. http://pl1gcc.sourceforge.net/

Re:Too Complicated to Run?

[Urusai]

The bigger issue is finding someone willing and able to program in PL/I.

Re:Too Complicated to Run?

[Zeinfeld]

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.

Re:Too Complicated to Run?

[Chris Mattern]

Yah, but it's going really slo-o-o-ow. Five years and they still don't have any actual code generation.

Chris Mattern

Re:Too Complicated to Run?

[mikael]

That's what the wikipedia article said:

It is worth noting that these two ideas, in their full power, are even now still not available in other widely used operating systems, despite the rapid and otherwise enormous advance in the computer field since the 1960s; although in more limited forms they are now becoming more widely accepted and available, e.g. dynamic linking.

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

[bvimo]

Or is it a Chuckie Egg problem?

Re:Too Complicated to Run?

[Kadin2048]

I'm fairly certain that IBM has a PL/1 compiler that will still run on its big iron systems, at least in compatibility mode.

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 lost backwards compatibility.

What I think is sad is that the hardware apparently wasn't preserved when the last system was taken down; I'd have thought there'd be lots of people at MIT, or computer-history groups, that would have taken it over and carefully carted it away in a fashion that would have at least preserved it for analysis, if not actual operation.

Re: Too Complicated to Run?

[uucp2]

In current Unices, mmap can map the same file with different permissions from process to process.

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 do that in Unix.

You can achieve the same functionality by using shared memory, but then Process A's code could access Process B's data, which is quite different in security point of view. It is a bit like a system call, but instead of calling the kernel, you are calling another process.

Re:Too Complicated to Run?

[petermgreen]

No big deal, just use a 64 bit location for each word and ignore the higher bits. You will have to calculate the status flags manually but any emulator written in a high level language tends to have to do that anyway so no big deal.

Re:Too Complicated to Run?

[Anonymous Coward]

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.

Re:Too Complicated to Run?

[Fred_A]

So what you're saying is that all we *really* need to emulate is some kind of really ancient IBM big iron and there will be an emulator available ?

Is that supposed to be a relief ?

Re:Too Complicated to Run?

[Brian Gordon]

A PL/I compiler that will run on modern hardware and compiles for old MULTICS hardware? Not too difficult from source, but it would certainly take some know-how.

Re: Too Complicated to Run?

[davecb]

You're right, it's almost all in PL/1, with very approximatly the same amount of assembler as Unix. --dave

Re:Too Complicated to Run?

[Anonymous Coward]

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

Re: Too Complicated to Run?

[TheRaven64]

You can do this on x86 using call gates. x86 also has a 4-ring privilege system which is much closer to the MULTICS model than most other architectures provide.

Oh, I almost forgot, AMD ditched both of these features when they 'improved' x86 to make x86-64.

Re: Too Complicated to Run?

[Eli Gottlieb]

Except that call gates don't call into another address space, they call into another segment. And only one modern compiler for a modern language (Watcom C, IIRC) emits code for a properly segmented memory model instead of the flat-memory-on-segments model normally used.

Re:Too Complicated to Run?

[s4ltyd0g]

Well it would have been written in assembler for specific hardware. Lots of work porting that.

Re:Too Complicated to Run?

[pdcull]

Sorry to be pedantic, but GEM was actually written in C. The source code has been released and is "out there" somewhere (such as http://www.deltasoft.com/downloads.htm).

Re:Too Complicated to Run?

[ctzan]

There's a modern PL/I compiler (kednos) that works on VMS.

I've played with it on vms/vax (on simh), but it probably works on VMS on alpha and Itanium, too.

What is funny is how small and fast is when compared to gcc, given all the stories about PL/I being a 'big' language, that needs a compiler 100 times more complex than a C one.

Re:Too Complicated to Run?

[Anonymous Coward]

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 ? :)

No, because this is where the Cross compiler comes into play. And as another poster pointed out somone has apparently written a PL/1 compiler for GCC.

Re:Too Complicated to Run?

[Slithe]

Well, GCC has a PL/1 frontend available. Maybe, the operating system could be compiled with that, and then one could just load it into an emulator.

Re:Too Complicated to Run?

[SpinyNorman]

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.

Re:Too Complicated to Run?

[drspliff]

Not at all, once you have an existing programmable system you can build a cross compiler, how do you think they did it :) (well apart from the nuts that programmed directly in machine code).

Anyway, I'm sure building a PL/I compiler to output GE-645 machine code wouldn't be a hard problem, maybe an interesting comp/sci project. The source code for the PL/I compiler could probably be bastardized to be compiled and run on another machine (via a native PL/I compiler) which would save you a lot of time.

Take a look at the apout project some time ( http://puszcza.gnu.org.ua/software/apout/ ), something similar could be implemented which emulates only the minimum required to run a single executable (in apouts case, it uses native syscalls instead of the unix vX/bsd2.11 kernel).

Re:Too Complicated to Run?

[lokedhs]

I don't know about the other operating systems, but TOS was definitely written in C. It was compiled using Mark Williams C.

Re:Too Complicated to Run?

[Calinous]

What is funny, is how many things are in current gcc, that you won't find in PL/I. What about object oriented features?
      Compare the PL/I with one of the first C implementations to get it straight

Re:Too Complicated to Run?

[mwvdlee]

Still actively maintaining PL/I code on z/OS mainframes! :)
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:Too Complicated to Run?

[Anonymous Coward]

Yes but MIT have now provided us with the sources to their compiler so presumably that could mean a boost for the GCC frontend if it's of help to the project.

Re:Too Complicated to Run?

[Burrfoot]

As I recall: Multics ran on a mainframe system with 36 bit words (yep, 36 bits) giving you a choice of 6 bit BCD or 9 bit ASCII++ characters, 18 bit half-words used for indexing arrays, etc. 80 bit floating point arithmetic sharing the same general purpose registers as the 36 bit integer registers (2x36 bit registers holding the mantissa + and 8 bit "extension register" used to hold the exponent.) and a powerful but quite different memory map/virtual memory/ring of protection memory architecture. It had a single I/O instruction: CIOC (meaning connect to I/O controller) All that did was wake up the attached I/O coprocessor (the IOC) which executed IO Control programs (a unique language) that you left in main memory. The IOC, by the way also participated in the memory management and ring of protection scheme. Altogether a *different* beast from anything being built today. Portable code? We don't do portable code, Were MULTICS! Sure you could write an emulator -- using a x86, or a Turing machine if you want to. At least you could *START* writing an emulator, but I'll cover any bet you want to make that you never FINISH writing an emulator. -- What happens if I don't have a SIG?

Re:Too Complicated to Run?

[aduzik]

One of the reasons why UNIX succeeded where Multics failed was because Multics was written for specific hardware. The UNIX guys knew that their operating system had to be portable to other platforms, which is why Kernighan and Ritchie invented C as a platform-agnostic alternative to existing languages. That way, they only had to implement a small number of machine-specific routines in assembly while most of the operating system could be compiled for any platform.

So it's not a matter of MULTICS being too complex for modern hardware or vice versa. Rather, modern hardware is just different from the hardware MULTICS was written for. Almost forty years later you could, with some ingenuity, write the necessary low-level components for any version of UNIX and get it running on just about any imaginable piece of modern hardware.

Will the OSS & CSS Community Borrow More From

[mlauzon]

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..?! Hell, I wouldn't be surprised if other OS companies -- OSS or CSS -- will be looking at the source code to see what may be portable as we speak.

emulators?

[gEvil (beta)]

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?

[ByOhTek]

more likely, within a year we'll see the following article on /.:

MULTICS ported to run on standard x86 hardware

Re:emulators?

[Anonymous Coward]

I imaginet one of the machines in the simh simulator can run this...

Re:emulators?

[Jeppe Salvesen]

All computers can emulate all computers. The big question is how efficiently.. Anyhow, I bet a very poor hardware emulation layer will make Multics fly compare to that multi-million dollar hardware it ran on back in the days when I was not even conceived.

Re:emulators?

[exp(pi*sqrt(163))]

I bet you $1,000,000 you can't emulate my MacBook Pro on my Palm Z22. I'll make it easy for you - you can make your emulation as inefficient as you like.

Re:emulators?

[eyrieowl]

Can I have the $1,000,000 if I simply show you I can without doing it? http://en.wikipedia.org/wiki/Universal_Turing_machine I prefer check, but I'll also take cash or wire-transfer.

Re:emulators?

[Hatta]

Can I assume an arbitrary amount of storage? If so, Alan Turing would take that bet.

Re:emulators?

[MBGMorden]

He didn't say it was feasible or easy to write one, just that any computer (or really, any processor - space and RAM limitations have to be considered) can emulate another. That is mostly true. If one felt so inclined, your Macbook could be emulated by a Z80 based machine (Gameboy, Timex Sinclair, etc) if it had enough RAM at it's disposal (it'd need some tricks to address that much, but it can be done), and enough storage space to store the emulator.

As I said though, that doesn't make it really feasible or easy though. I can also say that any password can be cracked through a brute force approach (a true statement), but that doesn't mean it's feasible for me to start cracking at one using that method to prove it can be done - it's going to take to long and be an ultimately futile task. Easier to just use mathematics to investiagate it rather than require a working example (which is the only real way to go about it anyways - if I wrote a Macbook Pro emulator for a Palm Z22, all that proves is that it's possible to write a Macbook Pro emulator for a Palm Z22. Proving that any processor can emulate any other can only be done mathematically :)).

Re:emulators?

[glwtta]

I bet you $1,000,000 you can't emulate my MacBook Pro on my Palm Z22. I'll make it easy for you - you can make your emulation as inefficient as you like.

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

Re:emulators?

[orangesquid]

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

Re:emulators?

[Anonymous Coward]

The fact that there are posters on Slashdot who don't know what a Universal Turing machine is and how it applies to computer hardware completely boggles my mind. You are the cancer that has killed Slashdot.

Re:emulators?

[iksrazal_br]

Any chance of an emulator being developed that can run this? Are the hardware specs open?

What would it take to port multics to my iPhone?

Kidding of course, I have ROKR and linux runs on it.

Re:emulators?

[exp(pi*sqrt(163))]

The fact that there are posters on Slashdot who can't tell the difference between a Turing machine and a real finite computer with finite resources boggles my mind. You're the cancer that causes my computers to run so slowly considering they have multi-GHz processors in them.

Re:emulators?

[exp(pi*sqrt(163))]

> Can I have the $1,000,000 if I simply show you I can without doing it?

Absolutely. Just don't forget the fact that the Palm Z22 has about 32MB of memory and my MacBook Pro has 2GB of RAM and a 160GB hard drive. By the way, just in case you're unfamiliar with the notion of a bet, when you fail you owe me $1,000,000.

Re:emulators?

[exp(pi*sqrt(163))]

> if it had enough RAM at it's disposal (it'd need some tricks to address that much, but it can be done),

I bet you also claim that you can run a marathon faster than anyone else (and follow your claim with the parenthetical remark that you need a few tricks to do it like hopping on a bus).

Re:emulators?

[exp(pi*sqrt(163))]

> Why on earth wouldn't you be able to emulate x86(-64) on ARM?

Are you just pretending that you forgot about the GB of RAM that comes as standard on on MacBook Pros, or do you really think that RAM is irrelevant to emulation?

Re:emulators?

[Gordonjcp]

So when are you ponying up the million dollars? That's nearly 20 quid you know. You could buy a nice lunch for that.

Re:emulators?

[TheRaven64]

Does the Palm have any kind of network connectivity? If so you can always use some external storage.

Re:emulators?

[david.given]

Are you just pretending that you forgot about the GB of RAM that comes as standard on on MacBook Pros, or do you really think that RAM is irrelevant to emulation?

Of course it is. If you've got enough swap. Which you can plug into the Palm's USB connector.

Re:emulators?

[fishtop records]

SIMH already emulates PDP-10 hardware, also 36 bit, with special hardware for cool things. There is no reason that Multics can't be ported to SIMH if its not already done The world of computing did not begin with the IBM PC and all byte are not eight bits

Re:emulators?

[exp(pi*sqrt(163))]

Sure, and the coffee I'm drinking can emulate a MacBook Pro. I just need to add a CPU, RAM and a handful of other components.

Re:emulators?

[exp(pi*sqrt(163))]

You can't buy a nice lunch for 20 quid. In fact, it's completely impossible to buy any food even remotely close to 'nice' in any country that uses 'quid'.

Re:emulators?

[Anonymous Coward]

You've once again proven that mac users can't do everything.

Things like shutting up for instance.

Re:emulators?

[einhverfr]

Fair fa' your honest, sonsie face,
Great chieftain o' the puddin-race!
Aboon them a' ye tak your place,
Painch, tripe, or thairm...

Re:emulators?

[jra]

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.

Re:emulators?

[glwtta]

do you really think that RAM is irrelevant to emulation?

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?

[Atzanteol]

Mmmmm, haggis...

Re:emulators?

[Eternauta3k]

Come on, I liked the RAM comeback. I was like "what, how could a palm not be able to do this?".

Re:emulators?

[exp(pi*sqrt(163))]

> Whether or not any specific device will have the resources...

I'm certainly not giving people $1,000,000 for an imaginary machine. Real men make claims about real computers with real resources, not imaginary ones.

Re:emulators?

[eyrieowl]

there's nothing imaginary about it, except that no one has done it. you made an overreaching claim about whether it was or wasn't possible to emulate your beloved, fancy computer; people pointed out that, in fact, it was; and you have proceeded to vainly attempt to discredit them by making snide comments equating pragmatism with peoples manhood and casting vague aspersions on computing theory. nonetheless, it would, in fact, be possible to do with a real computer, even a real hand-held, attached to finite storage. there's nothing imaginary about the certitude that it *could* be done. sure, it would be worthless for anything other than the million-dollar contract you've generously offered, and completely inefficient, but is it possible? yes. which, i think, was all you originally asked for. something along the lines of "make it as inefficient as you want"? i'm not sure what originally offended you and drove you to make your ill-conceived offer to someone noting the ability of any computing platform to be emulated, but your indignation doesn't make it false.

Re:emulators?

[Anonymous Coward]

WOW! Youre so FUCKING COOL! I bet you're soooo cool and l33t that you've never had a girlfriend and you've probably got no friends! Unfortunately I've had a number of girlfriends and I'm quite popular, so I'm nowhere near as l33t as you...but, please, teach me! I will learn you're aspergic, anti-social ways quickly!

Re:emulators?

[ioshhdflwuegfh]

Wait a moment, he was saying "you can't emulate my MacBook Pro on my Palm Z22", which is definitely true.

Well....

[graviplana]

I, for one, welcome our Ancient MULTICS, Father of UNIX, Overlord. :)

Emulating the Hardware

[Unoti]

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.

Re:Emulating the Hardware

[orclevegam]

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.

Maybe it had a more magic switch?

Re:Emulating the Hardware

[Cheesey]

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

Re:Emulating the Hardware

[Anonymous Coward]

Where is Doug Zwick when you need him!

PS I know where he is - but I'm not telling!

Re:Emulating the Hardware

[Anonymous Coward]

Unfortunately all of those old systems used copious amounts of magic smoke.

Re:Emulating the Hardware

[woodcutteruk]

Try emulating the PL/1 compiler. Lovely piece of stuctured code. Was given the green and white 66 line stripey paper source code (about two inches thick) in in my degreee exam as a question, asked to break it down to modules & inputs and outputs. Sad geek that I was, did it in 15 mins.

I'm always happy to see something opened, but...

[Facetious]

...I fail to see the value in this aside from the rare enthusiast's curiosity or perhaps an academic archive. Am I missing something?

oh good

[colourmyeyes]

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.

Re:oh good

[Etrias]

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

Re:oh good

[weeboo0104]

I'll up you a ROTS reference...

"Where is...SCO?"

"It's dead Darl, you killed it."

"Noooooooooooooooooooo!"

(The emporer laughs wildly)

Re:oh good

[janeil]

Best sig in quite a while, it'd be even funnier if Stephen Wright said it!

Re:Will the OSS & CSS Community Borrow More Fr

[CRCulver]

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

Imagine...

[Unoti]

A beowulf cluster of these bad boys running on emulated hardware running COBOL.NET applications under Mono!

Re:Imagine...

[orclevegam]

Imagine a beowulf cluster of these bad boys running on emulated hardware running COBOL.NET applications under Mono! Gah! Now you've done it! Already some poor government contractor is being asked to implement just that very system. You should never describe a system so completely absurd that no one in their right mind would implement it, because when you do some government organization rushes out to implement it. Please, won't someone think of the contractors?

Re:Imagine...

[BobNET]

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

Re:Imagine...

[djh101010]

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

I find your ideas intriguing and would like to subscribe to your newsletter. So are you saying that gummint jobs pay better than your average conslutancy gig?

Re:Imagine...

[FlameSnyper]

It is kind of like conSLUTing, isn't it? Selling yourself to the highest bidder, I mean.

An amazing typo. Thanks, man! LOL.

Re:Imagine...

[demonlapin]

No, not govt jobs. Those pay crap. "Contractor" is gov-speak for "consultant". Usually, like consultants, former employees of the org they do work for. Like consultants, well-paid for expertise.

Re:Imagine...

[Constantine XVI]

You forgot to have Mono running in BeOS on a PPC built in a FPGA

Re:Imagine...

[jaavaaguru]

That sounds like a fun project :-)

Re:Imagine...

[The_Dougster]

Dear Sir, In post yours: Imagine: A beowulf cluster of these bad boys running on emulated hardware running COBOL.NET applications under Mono! was which that plan was profits to be inconcievable! The step unknown notwithstanding ours is that to request assistance of yours in production this of plan the. Hope is that business may conduct us soon with. Soon to hope sincerely from hear you...

Re:Imagine...

[djh101010]

No, not govt jobs. Those pay crap. "Contractor" is gov-speak for "consultant". Usually, like consultants, former employees of the org they do work for. Like consultants, well-paid for expertise. Heh...funny you should mention that. Seems to describe my career path quite well. Now leading the team as a consultant, that I was part of when I got laid off as a direct hire. Took 3 or 4 years, got some outside experience, figured out that $VERYVERYVERYBIGCORPWHOSENAMEISTWOLETTERS isn't so bad after all, and went back. At a nice bump let's just say. It's not a game but, if it was, _I win_.

Like it won't happen soon.

[Kingrames]

"It is not yet known if it will be possible to emulate the required hardware to run the OS"

Currently taking bids on how long it will take.

Hey Microsoft! Read the source and weep...

[toby]

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

Probably the best source for Multics-related information is this site.

Re:Hey Microsoft! Read the source and weep...

[ElephanTS]

And it's Multivac not MULTIVAC!

http://www.scribd.com/doc/3407/The-Last-Question

Re:Hey Microsoft! Read the source and weep...

[ptbarnett]

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

But as an acronym, it's easier to deride it as:

Many Unusually Large Tables In Core Simultaneously.

Re:Hey Microsoft! Read the source and weep...

[Bill, Shooter of Bul]

Wait .. why is Microsoft weeping of the release of an ancient OS that can't be run on any hardware available? Its not like MULTICS is going to rise up and replace Linux as the open source OS, or Windows itself. Just explain your headline to me and we'll call it even.

Re:Hey Microsoft! Read the source and weep...

[fm6]

As long as we're playing usage nazi: it should be "MULTICS", because the word's an acronym (according to the official programmer's manual). But "Multics" is used officially, and that trumps ordinary usage nazism.

"UNIX" is the inverse example. It should be "Unix" because it's not an acronym, but rather a play on "Multics". But AT&T decided early on that it was "UNIX".

Re:Hey Microsoft! Read the source and weep...

[Anonymous Coward]

By the way, it's "BTW" not "Btw".

Re:Hey Microsoft! Read the source and weep...

[Anonymous Coward]

I guess GP meant: cry in SHAME, Microsoft coders, as you realize that someone once created a powerful and rock-solid operating system that ran well on those dinosaur machines -- whereas today's hardware is absurdely more powerful, but your system runs like crap on pretty much anything.

Re:Hey Microsoft! Read the source and weep...

[Bill, Shooter of Bul]

Ok... So BSD is what .. a fried egg sandwich? If they had to weep every time they discovered something that ran better than windows on a specialized hardware platform, they would die of dehydration.

Re:Hey Microsoft! Read the source and weep...

[drbaggins]

true, but silly.

why not caps?
after all, it IS an acronym ...
MULTICS = "Many Unnecessarily Large Tables in Core Simultaneously"

Re:Hey Microsoft! Read the source and weep...

[cpeterso]

MULTICS = Multiplexed Information and Computing Service

Re:Hey Microsoft! Read the source and weep...

[julesh]

And it's Multivac not MULTIVAC!

http://www.scribd.com/doc/3407/The-Last-Question

You know, given the whole scribd / Asimov / Doctorow thing, I'm rather surprised that's still up there.

quickly reading the headline

[xrayspx]

I thought they'd released the source code for Ken Thompson. Neat trick.

Re:quickly reading the headline

[Rorschach1]

Not yet - but the source for Craig Venter is published, and I hear there's less than 1% variation between the two. You just need to get the diffs.

Re:quickly reading the headline

[xrayspx]

They got MD5Sums with that? I don't want to spend 20 years compiling just to end up building and executing some virus.

Step 2...

[Nom du Keyboard]

Now all we need is some hardware...

Mother of Unix?

[z-j-y]

If this is the father of Unix, who is the mother?

Even though 99% of Unix geeks are men, it is still biologically incorrect to call it 'father'.

Re:Mother of Unix?

[nuzak]

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:Mother of Unix?

[Workaphobia]

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.

Re:Mother of Unix?

[dfn5]

Even though 99% of Unix geeks are men, it is still biologically incorrect to call it 'father'. Not if you stop to consider that AT&T left the project because it was just too damn complicated and created the simpler Unix. So if Multics is the Father then AT&T is the estranged mother and Unix the bastard child.

Re:Mother of Unix?

[Eli Gottlieb]

If this is the father of Unix, who is the mother? Your mom.

Wow, that was all too easy.

Re:Mother of Unix?

[Anonymous Coward]

> AT&T is the estranged mother and Unix

And of course, the "old" AT&T was "Ma Bell" at that time :-)

Father of Unix?

[EmbeddedJanitor]

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.

Re:Father of Unix?

[$RANDOMLUSER]

Besides, I thought God's Chosen Operating System was the "father of all modern OSes". After all, there's a GCOS field in /etc/passwd.

Re:Father of Unix?

[steve54]

Ken Thompson & Dennis Richie worked on MULTICS (MIT and Bell Labs were both involved in the project). After Bell Labs dropped out of the project, Ken & Dennis created Unix partly as an effort to reproduce the good stuff they were missing.
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 /etc/passwd was to support a batch job submission subsystem. This field connected your Unix account and your GCOS account.
The MULTICS is not an acronym but the gag acronym I heard was Many Unbelievably Large Tables In Core Simultaneously (that's what I heard -- http://www.multicians.org/multics-humor.html has it as Many Unnecessary Long Tables In Core Simultaneously).

Re:Father of Unix?

[UserGoogol]

Well, the name Unix is a pun on Multics. Puns count as genetic, right?

Re:Father of Unix?

[ardent99]

They way I heard it, Unix is Multics with its balls cut off...

Re:Father of Unix?

[jefu]

Puns count, but eunuchs don't tend to contribute lots of genetic material themselves.

Re:Father of Unix?

[GeneralTao]

Well done! Well done! :)

Re:Father of Unix?

[coastwalker]

speculation might have it that the acronym was more along the lines of Multi User L*** Timeshare I*** Computer System, but that would be too obvious :-) and wild guesses for the L and the I could be Limited Individual but I'm sure there are better ones.

Re:Father of Unix?

[Eunuchswear]

OI! I resemble that remark.

Unix - "Multics with the balls cut off".

Re:Father of Unix?

[hey!]

I don't think there would have been a Unix if here had been no Multics, but the family metaphor is all wrong.

Multics was a system that a modern programmer, if forced to use, would adapt to pretty easily. It was quite an accomplishment for its day, but it was designed by a committee, which produced a pretty good attempt at pleasing everybody. The result, however, was not small. Furthermore, operating systems weren't seen as products in themselves back then, they were just a way to make the very expensive hardware they came with usable. Put the size of the operating system and the lack of concern for portability together, and you can see that while Multics may have been quite successful, its future was limited. Multics was the culmination of the era of operating-system-as-hardware-accessory, and Unix the start of the portable operating system.

Unics [sic], was a classic instance of programmers scratching an itch. Multics had a lot of important and useful ideas in it, but nothing short of an army of programmers could reproduce it on different hardware. However, a couple of programmers who needed an operating system could take the set of successful ideas in it, and reproduce just the bare minimum they needed for their project. Ah, for the days when programming was so mysterious nobody could account for how you used your time!

So, if you want a metaphor, Multics isn't the father and Unix isn't the son. Multics is the factory produced motorcycle and Unix is the chopper you make out of it in your garage.

It's wonderful that MIT is releasing the source to this historically important OS. Who knows whether it will be useful to anybody, but my guess it probably will be. Not as an OS, but as a source of knowledge for people working in various areas of OS development and research.

MIT has been very active with open source of late

[mjasay]

It released its open-source Flickr application (Thalia) and it's actively working on open sourcing other projects that it's working on. Now if we could just get the corporate world to be as liberal/free with its code as the academics....

you can't run it

[meta coder]

Unfortunately you can't install this on any PC it's seem like windows vista

Re:you can't run it

[Anonymous Coward]

I think Vista's real problem is that it *can* be installed on PCs... that doesn't mean it *should* be

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.

Re:innovation and performance

[markov_chain]

Systems people don't joke when they say that everything has already been done by Multics!

May I suggest...

[saddino]

How about "parent process" of UNIX?

Re:I'm always happy to see something opened, but..

[$RANDOMLUSER]

It might be interesting to see how many of Microsoft's 235 patents are in there as prior art - that is, if they'd tell us which 235 patents they mean.

Multics ran on the GE-600 series

[Anonymous Coward]

http://en.wikipedia.org/wiki/GE-600_series

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:Multics ran on the GE-600 series

[Applekid]

This directory might indicate someone's already started an emulator project. The time for ascention is now[-ish].

emacs

[FranTaylor]

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.

Re:emacs

[The_Dougster]

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 with that Multics system, or did you just enter your papers in using punch cards?

Re:I'm always happy to see something opened, but..

[0racle]

Yes you are missing something. The 'value' you put in something is pretty meaningless to everyone else and historical interest is a value if you are interested.

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:KISS

[DragonWriter]

For example, we now take it for granted that the OS should implement a disk file as a simple byte stream

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:KISS

[Blackeagle_Falcon]

The fact that Unix was created from the ashes of Bell Labs' participation in the MULTICS project is just a historical accident.

I would beg to differ. Just because code or features from Multics didn't make it into Unix doesn't mean Multics didn't matter. Many of the choices Thompson and Ritchie made when creating Unix were clearly a reaction to Multics. Indeed, one could argue that the real genius of early Unix wasn't in the features it implemented, but in the features K&R chose not to implement. As Antoine de Saint-Exupéry put it, "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Multics taught K&R what to take away.

Re:KISS

[Anonymous Coward]

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.

I don't take that for granted -- I think they were onto something.

Every serious application today either requires a database, implements a database (explicit or ad-hoc), or has dataloss issues. Even things for which programmers (who can be very slow to change habits) think *must* be a plain stream of ASCII (like source code), we just put the database on a server and give them a text interface to it (like SVN).

For server programs, we basically require a database. For desktop apps, many are starting to (Firefox, meet SQLite). The OS itself is starting to make the filesystem more database-like (e.g., Spotlight/Beagle).

Why can't we just admit that an OS needs a record storage facility with a standard interface, and a standard serialization format? We've already admitted that a desktop needs an HTML renderer.

We programmers are lazy. If we see a bunch of people writing the same code, we pull it out into an abstraction, and then all use that. Why does it always stop at the kernel/userspace boundary? No abstraction higher than these may pass!

Yes, in 1969, saying "everything is a byte stream" was a great idea -- for an operating system written by one man in PDP-7 assembly language. They also didn't imagine that your telephone would be running UNIX. Modern systems like Java, Python, Cocoa, and .NET have shown that what developers need to make good apps today is not bare-bones systems, but batteries-included systems.

They weren't stupid, but they also weren't geniuses. The idea of a UNIX that people didn't hack would also have been a mystery to them. The first thing called UNIX didn't even have pipes, for example. That's why I love microkernels: because it doesn't draw a line in the sand and say "You can't come any further, unless you want to be flamed by Linus and then ignored for blaspheming The Ken".

Re:KISS

[fm6]

So basically you're saying that Multics's biggest accomplishments were all instructive mistakes? Not a ringing endorsement.

Re:KISS

[Guy Harris]

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.

I don't take that for granted -- I think they were onto something.

Yeah, instead of the lowest levels of the OS implementing a disk file as a seekable byte stream, with bigger structures implemented atop that, they had the lowest levels of the OS implementing a disk file as an array of words mapped into your address space, with bigger structures implemented atop that.

Yes, Multics implemented a PL/I-style record access package atop that; back in 1979 or so, UNIX had the dbm library, so it's not as if you had nothing other than byte streams even above the kernel level.

Re:KISS

[johannesg]

The simplifications in Unix are its most important contribution to the art of OS design.

Gimme a break. Yes, you have a point, for sure, but UNIX has also introduced the mindset of "just barely good enough"; the notion that a solution is acceptable if it solves 80% of a problem rather than all of it. That malevolent spirit still pervades Linux and Open Source today, and is the reason both have such a hard time gaining acceptance. UNIX may have contributed simplicity, but in doing so it also contributed mediocrity.

Re:KISS

[Blackeagle_Falcon]

It's not intended to be. Your original post asserted that Multics didn't matter, but without Multics, Unix would not exist. An operating system doesn't have to be commercially or even technically successful to have an impact.

Re:KISS

[Anonymous Coward]

This comment about UNIX simplification would be a good one, if it was technically accurate, but unfortunately, it's not.

UNIX absolutely DID NOT originate the idea that the disk file should be a simple byte stream. Multics segments were simply an array of bytes (well - actually words, but that's a minor detail). Multics did indeed support fancy structured files for backwards compatibility with earlier mainframe systems via a user-mode file I/O simulator.

In fact, I don't think Multics originated the idea either. That may go back to CTSS or DTSS, but I'm not certain.

UNIX I/O was almost identical to Multics I/O streams and to DTSS communications files. Now what UNIX did originate is the notion of the pipe, and making the pipe easily specified by a single character on the command line. Multics I/O streams could be interconnected in more ways than pipes supported, but the human interface was rather more complex.

In fact, if you look at many of the things from Multics that were left out of UNIX, only to be added back many years later in very clumsy fashion, you would find that much of the "simplification" actually was not done well.

Two of the biggest examples are mapped files and access control lists. In Multics, all segments were mapped by default. In fact, using them as "files" with read and write statements was the exception, not the rule. By contrast, mapping a file in UNIX had to be added many years later, and is quite complex by comparison. Multics had a full access control list mechanism that was quite easy to use. By contract, the POSIX ACL mechanism, which was NEVER approved by IEEE for very good reason, but has been implemented in Linux, is horribly complex and VERY difficult to use. The POSIX ACLs were forced to be so complex, because early UNIX had NO file locking mechanism, and instead early UNIX manuals recommended "locking" by setting the permission bits to zero. This early locking mechanism never worked properly, and better locks were added later. But POSIX mandated that any ACL system had to maintain backwards compatibility with that old, broken locking approach, which has condemned UNIX and Linux to a very baroque ACL mechanism.

Re:KISS

[fm6]

but UNIX has also introduced the mindset of "just barely good enough"; the notion that a solution is acceptable if it solves 80% of a problem rather than all of it.

I'm sorry, I don't see that. I've used pre-UNIX OSs (IBM OS360, DEC RSTS), and I don't see any great decline in quality between them and UNIX. Do you have a counterexample?

Re:KISS

[fm6]

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.

Re:KISS

[epine]

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 fail without having confronted the right question in the first place.

Let's consider the first moment in history where a physicist convinced himself (after many years of effort and for mostly the right reasons) that a classical description of light could not possibly work. Hardly a ringing endorsement of his work so far. What an abject failure. Now he'll never get promoted to middle management after making such an enormous career blunder. A negative result. Not even worth writing a paper.

Re:KISS

[fm6]

Let's consider the first moment in history where a physicist convinced himself (after many years of effort and for mostly the right reasons) that a classical description of light could not possibly work. Hardly a ringing endorsement of his work so far.

That's a pretty dumb comparison. Nobody connected with the Multics project said, "Oh, gee, we've been going about this all wrong. Let's invent Unix instead!" In fact, Multics eventually became a commercial product, though it never became a big profit center for its owners. Honeywell only stopped selling in in 1987; the federal government shut down its last Multics system only 7 years ago.

I'd be the last to deny that you learn a lot from mistakes. But I don't think Multics's mistakes have been very influential. The big lesson to be learned is that the future doesn't belong to mainframes that lack byte-level addressing. And IBM figured that one out before Multics was even released.

Re:KISS

[cburley]

They weren't looking for a way to squeeze Multics into their tiny PDP-8

PDP-7, actually. The PDP-8 was even smaller; (a multiple of) 4K 12-bit words, compared to the -7 (18-bit words) and the -11 (16-bit words and byte addressability), where Unix really first "landed" in a widespread way.

AFAIK, Unix never ran on an -8.

Re:KISS

[petermgreen]

What is really meant is that as far as the OS is concerned a file is just a sequence of bytes. The OS and filesystem drivers do not concern themselves with what those bytes mean only with storing them and associating them with an identifier for retrival and security information.

That is if an application stores a sequence of bytes it expects to get the same sequence back, not have the driver interpret the file, store it's interpretation of it and then regenerate a different sequence of bytes from that interpretation.

Source?

[SnarfQuest]

(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 for example.

MESS

[Weaselmancer]

It's MESS you're thinking of, not MAME.

It ran on

[Ancient_Hacker]

It ran on GE Model 645 hardware, a not particularly complex nor fast CPU. Maybe someone will whip up a bunch of macros to convert that language to X86 or even C. Shouldnt take more than a couple of weeks of hacking.

Re:It ran on

[Slithe]

Even if it was that easy to port Multix to the PC, wouldn't the programmer have to write all the device drivers to support it? That might take more than "a few weeks."

Multics has been ported to x86:

[Anonymous Coward]

It's called Linux. :-O

Well, duh

[Nicolas MONNET]

Karma whoring, indeed ...
Had you compiled Linux in the past 5 years, you might have noticed that it can do just that on suitable hardware.

Re:Well, duh

[Ant P.]

Could Linux do this 30 years ago? Could anything else, for that matter?

Re:Well, duh

[TeacherOfHeroes]

Just how old do you think linux is, anyways?

Re:Well, duh

[Ant P.]

Fifteen years, what's your point.

Re:Well, duh

[downix]

Saying "Linux can do it" when it's 15 years old does not diminish the accomplishment of Multics, at 30 years, by any stretch. So what if Linux can do the same things, it came after. The fun part is what Multics could do, at it's age.

think outside the box...

[Anonymous Coward]

"there's no operational computer system today that could run this OS"

emulation, baby!

The real legacy of Multics

[spaceyhackerlady]

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

Re:The real legacy of Multics

[suitti]

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.

Re:The real legacy of Multics

[fm6]

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

From the supernatural hardware dept.

[hoggoth]

> It is not yet known if it will be possible to emulate the required hardware to run the OS.

Turing disagrees.

Re:From the supernatural hardware dept.

[fbjon]

Yes, it is possible, but it may not be feasible. Hypothetically, some hardware may have properties that would require emulation at, say, a quantum level to achieve identical output.

More practically, the hardware may simply be different enough that emulation would be infeasible for a hobbyist. Not that I would know about it myself.

Re:From the supernatural hardware dept.

[Anonymous Coward]

Hardware emulation is a provable science. Screw turing, all you need to do is prove any given computer can emulate a sega saturn and it can emulate anything.

As for quantum emulation... there's already an answer to that. :)

only in use 35 years? Linux nearly halfway there!

[bball99]

interesting that Multics was presented in 1965 and that the last active installation was pulled in 2000...

Linux-based OSs are nearly halfway there... how long will Linux be in use?

so.... its not turing-equivalent?

[Anonymous Coward]

what is it, some sort of fairy computer that runs on whipporwills?

Not "simplified"

[Blackeagle_Falcon]

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.

Re:Not "simplified"

[kevinbr]

"....castrated......."

and.....Multics for the Many, Unix for the One. I was waiting for you to point this out. Thanks.

Re:Not "simplified"

[SuiteSisterMary]

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.

Re:Not "simplified"

[Anonymous Coward]

Not true; the pun came years later. The "Multi" in Multics was for multiple users; the original Unix was not multi-user, but single. Brian Kernighan coined the name Unics from "Uno" and "tics", and it was later spelled as Unix. I wasn't exactly there at the time but the tale is recounted by the participants in several places. I was however using Multics (the G-E Phoenix installation of it) via dial-up connection in 1975, and wrote a text processing program in one of its macro languages (TED)...

Re:Not "simplified"

[Anonymous Coward]

No - the name Multics came from "Multiplexed Information and Computing Service"

tar

[martin_lovick]

It would be nice to have a tar of the whole lot, theres a LOT of files in there

Mass commenting

[Z-MaxX]

That block comment appears in virtually every source file. It appears to have been added just for this release.

Obligatory comment....

[killmofasta]

Ken: Oh Crap. We wasted all that time rewriting it.
Dennis: Yea, I know. How about we get that ole PDP-7 out of the closit again,
Ken: Yea?
Dennis: and we can port Multics, and emulate the special hardware!
Ken: Yea?
Dennis: and have Multiple Multiple Multics!
Ken: Yea?
Dennis: And we can Profit!
Ken: Thats Silly, you've been reading slashdot again havent you.

Re:I'm always happy to see something opened, but..

[justkeeper]

To see the wisdom of ancient masters...

Mod parent up

[Raul654]

For those of you who missed the reference, ding!

Re:Mod parent up

[jaavaaguru]

Damn, now I'm going to spend the night reading Wikipedia again! And I was just about to go to bed.

Re:Mod parent up

[rozz]

Damn, now I'm going to spend the night reading Wikipedia again! And I was just about to go to bed. that is by far the geekiest /. msg in quite a while ... my geek core shuddered when i read.
too bad i have no modpoints today.

Possible?

[bigdavex]

It is not yet known if it will be possible to emulate the required hardware to run the OS.

Would they consider it cheating unless they use something more complex than a 2,3 Turing Machine?

Re:MIT has been very active with open source of la

[Anonymous Coward]

Nice job spamming the URL to your offtopic blog posting.

very eloquently ; "LOL !"

[unity100]

MULTICS requires dedicated hardware, and there's no operational computer system today that could run this OS i assure you that just as of now there are more than one project for an emulator (even hardware) are on the works in the half-dark recesses of many college/private sector labs.

Re:very eloquently ; "LOL !"

[julesh]

MULTICS requires dedicated hardware, and there's no operational computer system today that could run this OS
i assure you that just as of now there are more than one project for an emulator (even hardware) are on the works in the half-dark recesses of many college/private sector labs.

Indeed. Give a few students a handful of months and access to some reasonably large FPGAs, and I'm sure we'll have something convincing.

The special hardware exists on 386s and later

[davecb]

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

Re:The special hardware exists on 386s and later

[Anonymous Coward]

2. Long words, longer than 32 bits.

But less than 64 bits.

Re:The special hardware exists on 386s and later

[Anonymous Coward]

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.

begin(oldmanvoice)

and we LIKED it that way!

end(oldmanvoice)

Re:The special hardware exists on 386s and later

[SnarfQuest]

simh already handles 36 bit emulation for the PDP10. There is one eample to use if nothing else.

Re:The special hardware exists on 386s and later

[fishtop records]

Dec 10s, famous at the same time as Multics, are well emulated in software on PCs. There are many implementations, check out SIMH. Given that DPS-8 and PDP-10 hardware were typically one mips and had under two megawords (~~ 10 megabytes) there is nothing hard about this.

My MULTICS experience

[mihalis]

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

Re:My MULTICS experience

[Dynamoo]

I also started at Birmingham in 1986 and went to the same Computer Club meeting, although we never engineered anything more than software.

Multics was a seriously cool system, but it was absolutely crippled by its reliance on a very limited hardware base, i.e. the Honeywell DPS-8 (by 1986). Incidentally, the DPS-8 processor also found its way into mainframes using the godawful GCOS8 OS.

Multics in some ways very much the antithesis of Unix - when Unix was developed they chose to make it hardware independent and single-processor, for example. In other ways it was very like Unix, but in some ways it's quite unlike most operating systems in that.. well, it sounds strange.. but it's too *modern*. Multicians will understand, but suffice it to say that the underlying architecture has many features that I hope will one day make it to my desktop.

Re:My MULTICS experience

[commodoresloat]

So I like to think I helped kill off Multics (if only infinitesimally). You bastard!!

Re:My MULTICS experience

[VorlonFog]

I used MULTICS at the University of Southwestern Louisiana from 1975 to 1979. Our MULTICS ran on Honeywell 68/80 series hardware, and was a helluva machine for its time. Our favorite early hack was re-writing the 'get_group_id' system function and making the new segment known to our process. Then we'd send mail to another user and our function put up whatever spoofed username we wanted. The orignal 'cookie' program was also hilarious.

Re:My MULTICS experience

[mihalis]

Hey nice to meet you. I wonder if we'd have gotten to know each other if the login prompt had ever appeared that night.

As I understand it, the very first version of Unix was in assembly language and machine specific. The portability was a goal of the C rewrite if I recall correctly.

Multi-processor support was definitely lacking for years though!

Re:My MULTICS experience

[igb]

I was in the CS department at Birmingham 1983--1988, so used Multics pretty much throughout (and as a CS undergraduate I got essentially enough resources that I didn't need to worry about resources, unlike less-favoured departments: I think I got $20/day in the first year and $50/day thereafter, while other departments got about $2/day). The joy was the emacs implementation, which was a thing of beauty and in many ways better that GNU emacs is today.

"It is not yet know if the hardware can be

[Anonymous Coward]

emulated..."

Hmm. Let me see. The Multics system, ran on GE mainframes. So old, they predate a PDP-7.
I believe it ran on a GE-465. VERY WEIRD hardware. 36 bit. Seemed to have some thing about varible sized bytes of 6-bits for compatibility, and 9-bit bytes for emulation and a whole lotta weird stuff. VERY SECURE. And the box had a slit down the middle and could be opened up like a fridge...
( Im going to post this Anonymously so I dont show my age...:(

OPPS. Some was working on emulation:
http://stinet.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=AD0787218
So is this:
http://os.1.vg/projects/ge635/

Re:"It is not yet know if the hardware can be

[Anonymous Coward]

Ok. I found it. THIS IS WHY THE HARDWARE EMULATION IS SO FREAKING HARD:

ftp://ftp.stratus.com/pub/vos/multics/pg/mvm.txt

"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! )

An emulator should be feasible

[Jay Maynard]

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

Re:An emulator should be feasible

[Drinking Bleach]

SIMH already emulates other machines from the 1960s/70s, like the PDP-10 (which used 36-bit words as well), at a much faster rate than the original machines ran! On cheap PC hardware no less! I have no doubts that a GE-645 or Honeywell 6180 emulator would far surpass the performance of the original machines on PCs today (unless you throttle the speed; IIRC throttling is possible in SIMH as well to make it feel more like a PDP-10 :P).

It is MULTICS

[www.sorehands.com]

or at least when a Real Programmer (http://www.sorehands.com/humor/real1.htm) says it. Real Programmers speak in uppercase.

Microsoft did this!!

[alta]

They talked them into releasing it so it would distract us from Linux. Don't fall for it! Don't spend time porting it! Don't even read the code because they probably planted bugs that are so advanced that just 'more sourcefile.c' would infect you and overwrite your bios and install Anna K pr0n!!!

Re:Microsoft did this!!

[Constantine XVI]

Did you miss the part where Multics was written in PL/I, not C?

Re:Microsoft did this!!

[Stormwatch]

...would infect you and overwrite your bios and install Anna K pr0n!!!

Wow, someone did porn based on Leo Tolstoy's masterpiece?!

Re:Microsoft did this!!

[Anonymous Coward]

Don't even read the code because they probably planted bugs that are so advanced that just 'more sourcefile.c' would infect you and overwrite your bios and install Anna K pr0n!!!

more sourcefile.c

The perfect emulator

[mihalis]

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.

A good source of Prior Art

[AppleTwoGuru]

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.

Re:A good source of Prior Art

[Bozdune]

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.

Re:A good source of Prior Art

[ScrewMaster]

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.

Windows hasn't solved it even when there are no other processes.

In other news ...

[smcdow]

... Google announces that MULTICS code will be incorporated into Android.

Re:I'm always happy to see something opened, but..

[Kjella]

IANAL but even if I was, it'd probably take a judge to say that with any certainty anyway. Legalese is fuck-ugly to read and combined with code in assembler that is also fuck-ugly to read, the probability it's that clear is slim. Which is why they haven't said anything what the alleged patents are, nor where the alledged infringements are. Eventually people will see that it's nothing but empty threats. Or rather some won't, but they'll be squeezed from the market because of higher operating costs. It's a little bit of "You can't teach an old dog new tricks - but they do die eventually."

Someone build an emulator

[Pedrito]

This should be helpful to whoever (and surely someone will) wants to build an emulator. This is a PDF of the processor manual from 1985. The processor features sounds awfully advanced for 1985. Pipelining (they call it overlapping instruction execution), instruction caching, memory protection... Sweet! I want one...

Re:Someone build an emulator

[Bushido Hacks]

Port it to Palm OS. I bet everything MULTICS did can run on a 1 GB SD card or less. ("Is that a decommissioned supercomputer in your pocket or are you happy to see me?" --Some computer nerd girl.)

Hmmm

[greenfield]

"It is not yet known if it will be possible to emulate the required hardware to run the OS."

And Alan Turing rolls over in his grave....

SCO

[quangdog]

How long before Sco claims they own this as well?

--Kimball

http://www.kimballlarsen.com/

M-U-L-T-I-C-S

[Sun Tzu]

Many Unnecessarily Large Tables In Core Simultaneously.

I think we know what Linux stole from MULTICS!

Oblig.

[Anonymous Coward]

Netcraft confirms it: MULTICS is dying

Re:Will the OSS & CSS Community Borrow More Fr

[www.sorehands.com]

Free until now, the internals of the system were well-known. MIT even published a technical introduction.

Hell, there are several OS text books the examine Multics. I think I left my Pascal algorithm book.

Re:Father of Unix?...or NT

[DukeofSavoy]

I understand that MULTICS is the father of Primos/VMS and the Grandfather of Windows/NT (If you believe the rumors). Unix was designed to be an O/S where all the bells and whistles were removed. If you imagine an emasculated MULTICS, well that's unix. I remember an urban myth that UNIX was called EUNICH (supporting the above statement), but as that name could never be sold to a male dominated IT environment....unix, which sounds like eunich, was introduced. Ray D

great news

[m2943]

That's great news; I think there's a lot of prior art in there for supposedly modern inventions.

Getting this up and running shouldn't be all that hard; people have written emulators for all sorts of older architectures. Given the speed and memory of modern hardware, you can, for example, just emulate the 36 bit words using 64 bit words and not worry about the wasted 30 bits.

Chaos theory

[rapett0]

A butterfly flaps its wings...and takes out Multics.

Favorite Quote

[Flwyd]

My OS professor "The designers of Multics took the principle 'All problems in computer science can be solved by adding a level of indirection' to extremes."

(Or maybe that was Hydra...)

Re:Favorite Quote

[julesh]

I think that was Hydra. Multics only added one level of indirection and that's still in use today on modern architectures (segment selector architecture, similar to 80286 et al).

PL/I Subset G ran on Z80 machines

[crovira]

and on 360 class big iron.

AND there is even one dialect ( http://pl1gcc.sourceforge.net/ ) for the GCC.

Porting Multics may not be that big a job IF you have the source code.

The power of Multics lies in the ideas it implemented, not it whatever hardware it ran on.

(Even though the hardware was rather special it is well enough documented to be reducible to an implementation on a Turing machine.)

Zipped downloadable file?

[itsybitsy]

Has anyone found a single downloadable file for the Multics gizmo yet? If not has someone made one that contains ALL the files and docs? If so please link us to it. Thanks very much.

I prefer to have a copy on my computer naturally where, gasp, I can study it off line. Shivers... off line...

Re:Zipped downloadable file?

[celle]

Just make sure your wife doesn't find out!

"Modern" OSes

[RoaldFalcon]

...the father of UNIX and all modern OSes.

Am I just being paranoid, or is everything a swipe against Microsoft?

Re:"Modern" OSes

[jaavaaguru]

They do modern OSes? I thought Vista was merely a re-arrangement of kernel drivers and priviledges with a new GUI on what is mostly still Windows XP.

wonderful News

[jshriverWVU]

I use to be an OS collector, and I remember trying to get info on this years ago. All roads I came too said that the original tapes had disintegrated and the only remaining source code was a print out a guy at the uni had found and OCR'd. So curious what happened along those years. Someone find a backup?

Palms have a serial port.

[Ayanami Rei]

That serial port can interface storage through , thereby expanding the virtual address space of the emulator to an arbitrary size.

Re:Palms have a serial port.

[exp(pi*sqrt(163))]

Yeah, and a Ford Focus can fly because you can drive it onto a 747.

Re:Palms have a serial port.

[Eunuchswear]

Yay! You win 'cos you've found the stupid car analogy.

Meanwhile, back in the virtual world, you're full of shit, and might as well go and hide your head for the next decade(*)

(*) or 2-3 minutes in slashdot time.

Emulation of GE 36 bit hardware has been done .

[Anonymous Coward]

BULL sells a machine today that runs GCOS8 on an emulated platform .
They use an Itanium platform and it runs at least as fast as the native platform .
Go to BULL-s homepage and search for HELIOS , GCOS system used to run on
GE6000 machines very similiar to the Multics machines only the virtual unit
was different . I think GCOS ran on GE635 and Multics used GE645 or GE655? .

The last Multics installation

[mu51c10rd]

Rather amusing, the last Multics in use was with the Canadian military. See here.

Re:Will the OSS & CSS Community Borrow More Fr

[Organic User]

If they want some usefull stuff they might as well get them from Plan 9. The "successor of Unix." It has been open source since 2000 AFAIK.

Some things never change

[Anonymous Coward]

Unfortunately you can't install this on any PC, as VISTA requires dedicated hardware, and there's no operational computer system today that could run this OS. Fixed that... ;)

Well, as a user I kind of disagree

[Quadraginta]

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:Well, as a user I kind of disagree

[fm6]

Well of course the version you used felt like a research version — it was being used to research OS development. But there was a commercial version; Honeywell grossed a few hundred million selling machines that ran it. The last commercial installations (at the NSA and RCAF) shut down in 2000.

Re:Well, as a user I kind of disagree

[Anonymous Coward]

Actually, Honeywell tried very hard NOT to sell it as a commercial product. It was viewed as politically unacceptable to the batch processing GCOS people who ran the company. Customers had to drag their Honeywell salesman kicking and screaming to get to buy Multics. This was despite the fact that Multics regularly beat GCOS on interactive benchmarks.

The problem was that Multics would run all the GCOS software in emulation and had much better interactive support, so the GCOS people saw it as a threat. It was built and supported by this renegade team in Cambridge, MA, across the street from MIT, and not by the main software groups in Phoenix.

What is amazing is how many Multics systems were sold, given that the Honeywell sales force was basically incentivized to sell anything except Multics!

Both Ford and General Motors were big Multics customers, and GM in fact saved Multics from cancellation by Honeywell management at least once. The Air Force likewise saved Multics multiple times.

download ?

[ctzan]

what is all that idiocy with pressing 'back' in internet
explorer and wordpad ?

is there any link where to actually DOWNLOAD an archive or
a tape/disk image ?

MnM's Not Multics!

[The_Dougster]

I'd like to announce the new MnM/Amil operating system: Its "MNM's Not Multics" running on the "Amalgamation of Multics Impersonating Lemmings!" Its also licensed by the new MnM Candy Coated License (MnM CCL) which is will never leave your hands dirty! Yummy!

The OS for Tourette's Syndrome

[calidoscope]

A gag from Compuserve's ADD Forum - since of the of the symptoms of Tourette's is tics...

As other have pointed out, UNIX was considered to be less secure than Multics, though I suspect that work on things like ACL's and OpenBSD's bug stomping crusades may make a modern Unix more secure than Multics. Multics may be in theory a more secure design, but that may not carry over in practice. OTOH, it wouldn't surprise me if being written in PL/1 is a good part of the inherent security as it is way too easy to write insecure software in C.

Another factoid that I ran across ca 1972 was that OS/360 required 1,200 man-years of work while Multics only required 50 man-years, the difference attributed to Multics being programmed in a high level language while OS/260 was largely done in assembler.

Re:The OS for Tourette's Syndrome

[julesh]

OS/360 required 1,200 man-years of work

That's a myth.

(Sorry. Bad joke, but I couldn't resist it.)

Multicians, it can be done

[the_kanzure]

Any time I hear of MULTICS, I always recall:

The late André Bensoussan worked with me on the Multics operating system at Honeywell in Cambridge. We were working on a major change to the file system, which required a subsystem, the VTOC manager, to manage file description information. It had to transport the file information between disk and memory, manage a shared memory buffer pool, and manage space on disk for the information. In other words, it was a small virtual memory manager.

André took on the job of design, implementation, and test of the VTOC manager. He started by sitting at his desk and drawing a lot of diagrams. I was the project coordinator, so I used to drop in on him and ask how things were going. "Still designing," he'd say. He wanted the diagrams to look beautiful and symmetrical as well as capturing all the state information. I was getting nervous about the schedule, so I was glad when he finally began writing code. He wrote in pencil, at his desk, instead of using a terminal. He declined offers of typing help, and just kept writing away in pencil. He rewrote parts, copied things over, erased and rewrote.

Finally André took his neat final pencil copy to a terminal and typed the whole program in. His first compilation attempt failed; he corrected three typos, tried again, and the code compiled. We bound it into the system and tried it out, and it worked the first time.

In fact, the VTOC manager worked perfectly from then on. Only one bug was ever found in it, and that was my fault: André had asked me the calling sequence for an error procedure, and I'd guessed instead of looking it up, so it crashed the first time it hit an error. Beyond that the program was perfect.

How did André do this, with no tool but a pencil?

source

Father figure?

[sadangel]

I think Multics would more appropriately be described as the abusive, overweight, unemployed step-father of Unix.

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

Re:I'm always happy to see something opened, but..

[Chysn]

> ...I fail to see the value in this aside from the rare enthusiast's curiosity or perhaps an
> academic archive.

Isn't that enough?

With one of those I could toss the foot pedals...

[Kadin2048]

Finally, a keyboard designed for Emacs!

Now let's wait for...

[hotfireball]

Great! Now let us wait for last machine with Windows 3.1 ...

Re:Now let's wait for...

[taradfong]

You won't live to see it.

if Multics last this long we will have to fix

[Anonymous Coward]

I just had a look at the source and found (in http://web.mit.edu/multics-history/source/ldd_listings/sss/adjust_cutoff_.list ):

              43 dcl NEVER fixed bin (71) int static options (constant) init /* This date is 12/31/99 2359. */
              44 (1011000110010110011001001110100110111010100100000000b); /* .. if Multics last this long we will have to fix */

Still, Multics was running till the end of October 2000. Are there any updates to the source?

I'm not convinced.

[SanityInAnarchy]

Often, we talk about wanting to create a more advanced filesystem -- based on a database, for instance. Often, we find ourselves re-integrating some of these things -- the OS absolutely should handle indices, at least of our byte streams.

I do think Unix was an important fresh start. I also think that it didn't have to be as simple as it did.

One simple example: The POSIX filesystem API is broken. Biggest problem: lack of transactions; for example, either FS operations are ordered or they aren't. If they're ordered, you lose performance because the FS can't make intelligent decisions about what order to write to the disk -- and the application can't do that either, being at the wrong level. If they're unordered, you lose reliability, because you can't guarantee when anything hits disk -- or you lose performance, because you're doing a sync when you really don't need to.

Even simpler example: Lack of a 'copy' filesystem call, or anything like it, basically kills any standard copy-on-write support. Without standard copy-on-write, you can do hardlink farms, but that's at file-level granularity, not block-level granularity. Time Machine is a perfect example of why copy-on-write at the block (or extent, maybe) level is kind of needed.

Re:I'm not convinced.

[fm6]

You're right, these are important filesystem features — now. I fail to see how their absence in an API designed almost 40 years ago means that API is "broken".

Modern Unix systems do come with modern file systems. (My own employers are trying get everybody to adopt ZFS, which I believe supports all the semantics you want and much more.) Perhaps my ignorance of the relevant APIs is showing, but it's hard for me to see how the core Section 2 APIs fail to support these semantics. Perhaps you could educate me?

Re:I'm not convinced.

[SanityInAnarchy]

I fail to see how their absence in an API designed almost 40 years ago means that API is "broken".

Well, 40 years ago, they would have been good features, too.

I don't mean to imply that I'm judging the original designers. However, these features are so essential now that I consider any API not supporting them to be broken, just as I consider FAT (or at least, most FAT partitions) to be broken by not supporting files bigger than -- what is it, 2 gigs? 4 gigs?

By "broken", I mean that very basic functionality is missing, in a way in which it's not really possible to extend the system to implement them. For example, transactions can only be implemented on a modern filesystem by doing it yourself, in your own format (with your own journal), and calling 'sync' on a big file, at which point, why not write your own filesystem?

Modern Unix systems do come with modern file systems.

Which are hindered by this ancient API.

(My own employers are trying get everybody to adopt ZFS, which I believe supports all the semantics you want and much more.)

If it does, how does it support them?

More relevantly, are they done in such a way that any filesystem can implement them, or only ZFS?

Consider file permissions. POSIX basically requires them, although there are plenty of filesystems like VFAT which will show you any permission set you want it to (because the underlying device doesn't support them), and toys for FUSE which outright ignore file permissions.

Anyway...

If you want to discuss ZFS, you'll have to wait till I get some decent VMs set up here on which to install Solaris -- or at least, I should read the specs. But I do suggest you re-read them carefully -- I want to be able to perform a number of FS operations, on a set of files, and ensure that all of them are either committed as a unit, or fail. And I want to do it without interrupting the rest of the system.

Re:I'm not convinced.

[fm6]

You raise a lot of good points, most of which I can't provide an intelligent answer to. I'd need to read up on ZFS and Unix security settings, among other things, and I don't have time to do that. But I have to differ with your use of the word "broken". Software isn't broken just because it lacks a particular feature. It's just not appropriate for tasks that include that feature. I've been bitten by the 2GB limit in FAT32 (while backing up a system prior to reinstalling the OS) but I still keep all my portable drives in that format. This is not to say that FAT32 is a good file system, but it works well enough 99% of the time, and switching to other file systems has both portability and reliability problems.

You should reserve "broken" for software where even the core functionality has dangerous problems, such as not being reliable, or having an excessively complicated design. I think the appropriate word for the Posix file API limitations (assuming you're correct about them) is "outdated".

Re:I'm not convinced.

[SanityInAnarchy]

You should reserve "broken" for software where even the core functionality has dangerous problems, such as not being reliable, or having an excessively complicated design.

Filesystems lack transactions. I call that "broken", because it is dangerous to not only lose new data, but corrupt the old data in the process. In that sense, FAT32 is "broken" not because of the 2 gig limit, but because it lacks a journal, so it's entirely too easy to corrupt in the event that you forget to unmount (remove safely, eject...)

Technically, it's a performance improvement, because you can hack around it by calling fsync enough, and in the right places, and by either making heavy use of temporary files or writing your own journal inside the file.

But I consider it broken that to get acceptable reliability, you have to either kill performance with temporary files + renaming + fsync, or basically re-implement most of the features of the filesystem inside the file -- I think that meets your requirement of "complex".

Also, I use "broken" because most people, even programmers, are completely unaware of the issue, and it is an important one. Most filesystems are already mostly capable of supporting an API like this, but it really should be done now, for all filesystems (the way permissions are now).

This is especially frustrating for me now, as I'm currently working with an API even more minimalistic than POSIX. My only saving grace is that I'm mostly dealing with XML files, and thus, corruption is instantly noticeable. But I long for at least the POSIX guarantee that a 'rename' on top of an existing file would be atomic -- I just have a 'move' that is:

1. Delete destination file, if it exists
2. Copy source file to destination
3. Remove destination file if step 2 failed. Otherwise, remove source file.

Re:I'm not convinced.

[fm6]

Filesystems lack transactions. I call that "broken", because it is dangerous to not only lose new data, but corrupt the old data in the process.

Your argument seems to be "if there's any chance at all that a system will corrupt data or lose data, then the system is broken." By that definition, all computer systems are "broken" and always will be.

In the real world, you don't demand absolute safety, because that's not achievable. You simply do your best to determine how much safety you can achieve at an affordable cost.

Re:I'm not convinced.

[SanityInAnarchy]

Your argument seems to be "if there's any chance at all that a system will corrupt data or lose data, then the system is broken." By that definition, all computer systems are "broken" and always will be.

That's a strawman.

In the real world, you don't demand absolute safety, because that's not achievable. You simply do your best to determine how much safety you can achieve at an affordable cost.

You also don't demand absolute security. However, when somebody finds a security hole, you generally consider security to be broken -- that's why it's called a security hole. And you frequently rush a patch out the door as quickly as you can -- or at least, as quickly as you can be sure your patch doesn't break anything else.

I consider this to be broken because reliable storage is really a solved problem. Just about every database out there supports transactions. At the filesystem layer, we have metadata journalling, thus the filesystem itself is immune to corruption, so long as the disk, RAM, and CPU hold. At the block layer (disk) level, we can do RAID, bad block relocation, and so on. For RAM, there's ECC. For stupid users, there's filesystem snapshots.

The only place this has not been solved is in files stored on the filesystem.

I realize that there's no excuse for not having backups. However, it seems to me that the number of times you have some critical hardware failure is going to be far, far less than the number of times you have a power failure, or even a software failure -- many, many more of these result in a crash than in loss of data.

As for "affordable cost", the only part of this that isn't affordable is the lack of software that supports it, right now. I cannot imagine that it would take more resources to add this to an existing filesystem than it does to, say, add ipv6 support, or any of the other things people do to OS kernels. And I cannot imagine it being particularly hard to implement at the application level, especially if it ends up being a library which either uses transactions or "mv+fsync" and similar tricks on systems that don't support transactions.

Best file; best comments.

[igb]

It's the handover from BSG to BarMar of Emacs, with the change from Latin to Emacs comments, http://web.mit.edu/multics-history/source/ldd_listings/unb_2/e_redisplay_.list.

ian

Re:I'm always happy to see something opened, but..

[Facetious]

Indeed. Perhaps I should have asked, "Is there value in this beyond the rare enthusiast's curiosity or perhaps an academic archive?" Your point is well taken.