Slashdot Mirror

Multics didn't die in 1969 - it went on under the auspices of Honeywell to influence many more OSes than Unix.

And one could argue that the "enterprise" features of Unix were present in Multics some time before they were reintroduced to its descendant.

The last Multics machine was turned off in October 2000. More details here.

Real Programmers don't play tennis, or any other sport that requires you to change clothes. Mountain climbing is OK, and real programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.

For many years, the NSA used a Multics system, dockmaster, for Internet email and networked forums.

System V is the basis for all operating systems outside of Redmond

Huh? What rock has this guy been living under?

OS/360, VM/CMS, MVS, Z/OS, OS/400, OS/2(...)

We could make a game out of this...

NetWare
The OS for any computer built before MS incorporated (C64, Apple II, etc.).
Multics
Amoeba (ok, it isn't much more than a research project...)
PalmOS
Symbian/EPOC

Anymore? C'Mon, I know there's gotta be a huge list!

1. This is different from a big cache . . . how?

2. Instead of creating a "whole new file system concept", how about putting cache on the IDE cable, or the controller, or wherever? Back in the old days when a controller was a separate card, that would have been the obvious approach - and it would improve any/all drives attached.

3. MULTICS's philosophy, all the way back in 1965, envisioned all "segments", whether executable or data, as existing in virtual space backed by however many levels of whatever size/type physical memory you wanted. There are no "files" distinct from "buffers" distinct from "memory", no "i/o" operations; one simply accesses a named segment at the desired displacement, and leaves it to the paging mechanism to get the required data to a place where one can operate upon it. When it's not in current use, it's rolled out (if dirty) to backing store as needed. See http://www.multicians.org, particularly http://www.multicians.org/general.html#tag13 1.3.1 and 1.3.2 which will lead you to http://www.multicians.org/mgs.html#segment. Of course, the size of a segment seems ludicrously small to us today, but one meg sounded like a lot back in 1965.

1. This is different from a big cache . . . how?

2. Instead of creating a "whole new file system concept", how about putting cache on the IDE cable, or the controller, or wherever? Back in the old days when a controller was a separate card, that would have been the obvious approach - and it would improve any/all drives attached.

3. MULTICS's philosophy, all the way back in 1965, envisioned all "segments", whether executable or data, as existing in virtual space backed by however many levels of whatever size/type physical memory you wanted. There are no "files" distinct from "buffers" distinct from "memory", no "i/o" operations; one simply accesses a named segment at the desired displacement, and leaves it to the paging mechanism to get the required data to a place where one can operate upon it. When it's not in current use, it's rolled out (if dirty) to backing store as needed. See http://www.multicians.org, particularly http://www.multicians.org/general.html#tag13 1.3.1 and 1.3.2 which will lead you to http://www.multicians.org/mgs.html#segment. Of course, the size of a segment seems ludicrously small to us today, but one meg sounded like a lot back in 1965.

1. This is different from a big cache . . . how?

2. Instead of creating a "whole new file system concept", how about putting cache on the IDE cable, or the controller, or wherever? Back in the old days when a controller was a separate card, that would have been the obvious approach - and it would improve any/all drives attached.

3. MULTICS's philosophy, all the way back in 1965, envisioned all "segments", whether executable or data, as existing in virtual space backed by however many levels of whatever size/type physical memory you wanted. There are no "files" distinct from "buffers" distinct from "memory", no "i/o" operations; one simply accesses a named segment at the desired displacement, and leaves it to the paging mechanism to get the required data to a place where one can operate upon it. When it's not in current use, it's rolled out (if dirty) to backing store as needed. See http://www.multicians.org, particularly http://www.multicians.org/general.html#tag13 1.3.1 and 1.3.2 which will lead you to http://www.multicians.org/mgs.html#segment. Of course, the size of a segment seems ludicrously small to us today, but one meg sounded like a lot back in 1965.

At least 2GB is better than the Multics large file support situation! Files were limited to the size of segments, which were at most 255K 36-bit words, which is equivalent to roughly one megabyte! The Multics designers didn't consider most users would have to ever have larger files than this. The first database product (ever!), MRDS, was severely limited, so Multics programmers created a (kludgy) workaround. Modern operating systems are designed differently and thus aren't limited to such (small) file sizes.

We have conquered this problem before, by redesigning filesystems to allow files bigger than segments, and we can conquer it again by allowing files bigger than the addressable range of a 32-bit processor's full word.

At least 2GB is better than the Multics large file support situation! Files were limited to the size of segments, which were at most 255K 36-bit words, which is equivalent to roughly one megabyte! The Multics designers didn't consider most users would have to ever have larger files than this. The first database product (ever!), MRDS, was severely limited, so Multics programmers created a (kludgy) workaround. Modern operating systems are designed differently and thus aren't limited to such (small) file sizes.

We have conquered this problem before, by redesigning filesystems to allow files bigger than segments, and we can conquer it again by allowing files bigger than the addressable range of a 32-bit processor's full word.

1959 letter proposing time sharing system

I think Multics dates from 1965, see History and 1965 paper on the file system.

I think Multics dates from 1965, see History and 1965 paper on the file system.

I'm confused about the difference between Multics and Unix. Unix as all the features described on this Multics page. Unix is multiuser; so there goes the "Uni" vs. "Multi" difference from the names. Unix scales well to big boxes like the Sun E10K. The only things I can think of are that Multics has more robust job control out of the box and Unix has a more portable foundation.

With apologies to Multicians everywhere, the correct capitalisation is of course Multics. One early reference to the concept of a "computer utility" appears in this introductory paper by F.J. Corbato and V.A. Vyssotsky.

It's no mystery why this announcement gives everyone deja vu - a principal idea behind MULTICS (and novel at the time) was that of the "computing utility". Guess it was just 40-odd years ahead of its time...

This reminds me of UNIX's parent, Multics, which had similar goals but never achieved widespread acceptance.

I hope not to get trolled for posting a reference that is probably not too hard to find on search engines. However, if any of the readers of this would like to see a much broader range of information on Multics, I can recommend:
The reference web site for Multics history

and it's just so straightforward too!

I'm sure I'd be more of a Unix fan if I'd not worked with something like VOS. All the components in these fault-tolerant machines were hotpluggable, and all device drivers dynamically loadable and reloadable.

I think my favourite feature was the utterly predictable naming of commands - no umount here.

VOS was designed in the late 70s, based on the legendary Multics.

Anyway, the important thing is not to make excuses for the various problems we've inherited but to organize and develop something better.

On Multics machines, it's the @-character. (0100 octal)

In any case, to be a properly secure distribution you need DoD/NSA style certifications. The Common Criteria go part of the way there, but again certification is slow and really not universally accepted. (There's a flame bait for you CC fans).

Bottom line - true security requires seriously lengthy evaluation and certification. And even so, a product like NT 4.0 is still being found to have security holes to this day.

Sigh.. anyone fancy rewriting Multics for the Intel platform? :)

Aye, this "30 yr old OS" is just a poor limited clone of Multics, which supposedly required hardware that was too powerful for its day. So now that our Microcomputers have processors capable of billions of cycles per second, RAM more abundant than most of the off line storage that was available, and hard drive storage capacity that can only be filled by massive copyright violation (or video editing), we are using the restricted clone of Multics. The name Unix (UNIX is not an acronym, the caps was a historical accident) was a reference to Multics, as "One of whatever Multics was many of" or "Multics without balls."

Of course I see your point, though computer science hasn't quite been as linear as your examples would indicate: Spoken language and transportation technology is usually a tangible progression. Multics isn't the only counter-example; consider the history of Lisp, older than most High Level Languages, and yet still more functional than most contemporary languages, which are still playing catch-up.

As for human language, I'm guessing you've never heard of Superl, have you? Now that is a language done right!

Aye, this "30 yr old OS" is just a poor limited clone of Multics, which supposedly required hardware that was too powerful for its day. So now that our Microcomputers have processors capable of billions of cycles per second, RAM more abundant than most of the off line storage that was available, and hard drive storage capacity that can only be filled by massive copyright violation (or video editing), we are using the restricted clone of Multics. The name Unix (UNIX is not an acronym, the caps was a historical accident) was a reference to Multics, as "One of whatever Multics was many of" or "Multics without balls."

Of course I see your point, though computer science hasn't quite been as linear as your examples would indicate: Spoken language and transportation technology is usually a tangible progression. Multics isn't the only counter-example; consider the history of Lisp, older than most High Level Languages, and yet still more functional than most contemporary languages, which are still playing catch-up.

As for human language, I'm guessing you've never heard of Superl, have you? Now that is a language done right!

It's definitely an example of how to comment your code :-)

Everyone should make all their new developers have a look at http://www.multicians.org/dialup_.html, IMHO. OK, it's a bit messy, but I can make sense of it just from the well-placed, frequent, and verbose comments. Hooray!

This is a tiny fragment of Multics Source

It's only 20 years old, surely we can find more of it?

Unix evolved from Multics.

You can check out Multicians.org if you're curious about Multics. [...]It was actively developed till the 80's, and finally vanished in 2000, but is still quite influencial, of course (mostly by way of Unix).

I want to second this. Multics had many things that Unix was "reinventing" in the late 80s and early 90s. In my "advanced OS" class half the papers we read were less then a year old, and 30% of the papers were on Multics. In fact if I went back and re-read the papers I might find more stuff we are still re-inventing...or at least should :-)

You can check out Multicians.org if you're curious about Multics. It began as a research project in '65 between MIT, GE, and Bell Labs, and was continued as a commercial product when GE sold it off to Honeywell in '70. It was actively developed till the 80's, and finally vanished in 2000, but is still quite influencial, of course (mostly by way of Unix).

You'll find copies of the EMACS command set all over the place, though nowadays most users don't even know about them. Delphi has them, FrameMaker has them, god knows who else.

The obvious answer is Multics. Unix was a pun on Multics since it was originally a single-user OS in its earliest days. The original authors needed something less ambitious that could fit into the small computer they had to play with. Although the scale of unix systems eventually greatly exceeded any known Multics system, there is still some inherent architectural "heft" in Multics that Unix never had (never needed?). It's almost pure theology now, but you did ask. More info at Multicians.org I believe.

I like EROS's idea of having no filesystem. A hard disk is the permanent memory map, and regulary memory is just cache for it.

That was actually an idea that originated in MULTICS. Unfortuantely for MULTICS, most of the devlopment companies pulled out leaving HoneyWell with the sucker. And HoneyWell managed to bungle their marketing to no end. As a result, there have only ever been a handful of MULTICS machines in existance.

Multicians.org lists Dynamic Linking as one of Multics' features. A quick Google search turned up a number of pages referring to Multics having DLL-style shared libraries, and at least one claims that it was essentially nothing but shared libraries. Since Multics pre-dates Unix by ~4 years ('65 vs. '69), I think this counts.

Multicians.org lists Dynamic Linking as one of Multics' features. A quick Google search turned up a number of pages referring to Multics having DLL-style shared libraries, and at least one claims that it was essentially nothing but shared libraries. Since Multics pre-dates Unix by ~4 years ('65 vs. '69), I think this counts.

I agree. The biggest problem is programmers who have NO understand on business. Programmers who also have extensive business /accounting/etc expertise are as rare as hen's teeth. (But I do know a couple). They are also way undervalued.

This gets to be the equivalent of a non-coder technology manager who has picked up a book on javascript, and has written something simple in a afternoon. Who then says that there is nothing to javascript, and way can't you use javascript to create this intricate ssetup for me?

A comprehensive understanding of the programming problem is vital to the development of a competent programming solution. To the extent that you do not have the the problem well defined, the more time you will spend debugging, etc.

this is well illustrated by this webpage, which tells the story of a guy who wrote a memory management tool. the only bugs in the program were a handful of typos. It was literally perfection otherwise. He obviously had done all of his debugging on papaer in the first place.

The flip side on this is in large corporate enviroments where people asking for reports, etc do not understand the nature of the data in the first place, and so as for simple things that are hideously difficult, or which are confused in the first place.

Check out the Vinny the Vampire comic strip

Bizarre as it may sound, that is exactly what the creators of multics envisioned. In their world, you would have only a couple of major computers (mainframes) that supplied computing power to homes like electricity. No one would ever need a real computer, all they would need is a cheap terminal or other interface to this computing power. Now we've come in a complete circle and are just beginning to achieve the original goals.

Is my memory going? Don't know about the Honywell 6180, but I thought I remembered that the GE 635 and GE 645 were 48-bit machines instead of 36-bit as one of the articles says.

Your memory may be going; the item on the multicians.org site about the GE 635 says:

635

General Electric's competitor to the IBM 7094 in the 1965 time frame. Like the 7094, the GE-635 had a 36-bit word, 18-bit addresses, and programmable data channels with direct memory access.

and the item on the 645 says:

645

The computer system that Multics first ran on, produced by General Electric. Derived from the GE-635, a 36-bit word machine with accumulator, quotient register, and 8 index registers like the 7094. Basic execution speed was about 435 KIPS.

The 6180 was also 36-bit (its instruction and register set was largely a superset of the 645's, although I seem to remember the base register set was a little different - instead of pairing two base registers, so that you had 8 base registers but only 4 base pairs, you had 8 double-width base registers; programs that used the base pairs worked on either, but I think programs that tried to use the base registers independently rather than as part of a pair might not have worked).

Is my memory going? Don't know about the Honywell 6180, but I thought I remembered that the GE 635 and GE 645 were 48-bit machines instead of 36-bit as one of the articles says.

Your memory may be going; the item on the multicians.org site about the GE 635 says:

635

General Electric's competitor to the IBM 7094 in the 1965 time frame. Like the 7094, the GE-635 had a 36-bit word, 18-bit addresses, and programmable data channels with direct memory access.

and the item on the 645 says:

645

The computer system that Multics first ran on, produced by General Electric. Derived from the GE-635, a 36-bit word machine with accumulator, quotient register, and 8 index registers like the 7094. Basic execution speed was about 435 KIPS.

The 6180 was also 36-bit (its instruction and register set was largely a superset of the 645's, although I seem to remember the base register set was a little different - instead of pairing two base registers, so that you had 8 base registers but only 4 base pairs, you had 8 double-width base registers; programs that used the base pairs worked on either, but I think programs that tried to use the base registers independently rather than as part of a pair might not have worked).

For prople primatily interested in Linux, and glibc2, there's a paper for the community, written by David J. Brown and Karl Runge on Library Interface Versioning in Solaris and Linux.

There is the old joke regarding delivery of cutome designed goods:

Pick Any Two:

• High Quality
• Low Cost
• Fast Delivery

One thing that many will run into in the computer industry, is employers who are rather clueless and yet don't necessarily realize this. In 1996, a friend told me about a boss he had that needed a C program written for him. After a week, the boss complained that the program wasn't done, and he asked my friend what was taking so long.

• Friend: "The program is written, and I'm debugging it."
• Boss: "What's wrong with you people? You make programming more difficult than it needs to be. I have Frontpage Express to write web pages with, and when I write code with it, I never need to debug it. If you were as good of a programmer as me, you'd never need to debug either."

High Quality goes out the window.

There is an interesting story of a gentleman who wrote perfect code for a particular project. You can find the story HERE The parent page is also interesting, and worth checking out.

The bottom line is that it is a stoty of a guy who knows something sufficiently well that he was able to spend most of his time designing it, and made sure that the design was correct and perfect from the start.

Most places would have a heart attack at any thought that your would approach it this way in the first place.

I am still thinking on the proper conclusions to draw from all this.

There is the old joke regarding delivery of cutome designed goods:

Pick Any Two:

• High Quality
• Low Cost
• Fast Delivery

One thing that many will run into in the computer industry, is employers who are rather clueless and yet don't necessarily realize this. In 1996, a friend told me about a boss he had that needed a C program written for him. After a week, the boss complained that the program wasn't done, and he asked my friend what was taking so long.

• Friend: "The program is written, and I'm debugging it."
• Boss: "What's wrong with you people? You make programming more difficult than it needs to be. I have Frontpage Express to write web pages with, and when I write code with it, I never need to debug it. If you were as good of a programmer as me, you'd never need to debug either."

High Quality goes out the window.

There is an interesting story of a gentleman who wrote perfect code for a particular project. You can find the story HERE The parent page is also interesting, and worth checking out.

The bottom line is that it is a stoty of a guy who knows something sufficiently well that he was able to spend most of his time designing it, and made sure that the design was correct and perfect from the start.

Most places would have a heart attack at any thought that your would approach it this way in the first place.

I am still thinking on the proper conclusions to draw from all this.

• The Unix-Haters largely come out of the community of users of Lisp machines, with a few "X haters" that preferred NeXTstep and NeWS;
• You probably don't work with mainframe folk; they are pretty desparaging of Unix-like stuff as being "toyish;"
• VMS users are a similarly proud (albeit seemingly fading) group that generally aren't big fans of Linux
• Then there's Multics ...
• Fewer people remember GECOS, Stratus, and such...
• PDP-10's ran such notable OSes as TOPS-10, ITS, all vastly not Unix.

I Look at this, and I think of programming maxims that have been passed down, such as here an other excellent places. A few that might be appropriate include:

• "There's no time to stop for gas, we're already late"
• Craziness is doing the same thing and expecting a different result.
• When troubleshooting, make sure you are trying to fix the right problem.

Point being, I wonder what we would find if we applied proper bug finding and engineering standards to the drug war. Some solutions we would not want to apply to humans, of course.

But I bet we would find alot of hidden factors that are not being even looked at one way or another.

There is a big difference between "hacking up a better Minix" and creating a Multics clone; in the latter case, there was considerable integration between:

• The kernel, providing file, computation, and security services.

  Note that the memory model was substantially different from that of Unix. With Unix, you open files and filter data in and out, and allocate memory dynamically on demand, Multics unified this, so that rather than "opening a file," you would instead "initiate a segment," so that all files would essentially be memory mapped into the address spaces of all participating processes.

  Furthermore, whilst the evils of segmentation as seen with the 64k pages on the original "IBM PC" give people the impression that segmentation is evil, Multics made pervasive use of it to keep chunks of memory distinct.

  Note that some of the later Pentium CPUs included segmentation instructions likely based on Multics that could have been used to help do memory management "the Multics way;" the lack of such on RISC (Alpha, IA-64, PPC, MIPS, ...) architectures and the perpetual impending doom of IA-32 means that having memory management in Multics style on "modern" hardware may need to wait another 15 years...

• Programming Language.

  Multics was coded in PL/1, and the fairly byzantine complexity of PL/1 provides both the merit that some operations may be much better optimized than C, and the demerit of being pretty complex.

  I just don't think "C hackers" would build Multics.

• Unix and Linux represent "minimalist" systems in a number of senses, and it seems that many prominent Linux kernel hackers prefer "more minimal" text editors like Vi to the sorts of complex tools like TECO and Emacs.

The only way I'd see it being likely would be if some of the retired Multics creators that made some Silly-Valley and/or DotCom millions decided to sponsor a several-year-long project involving a staff of on the order of a dozen pretty elite developers to provide some sort of "legacy" to retrieve Multics from the dead.

There is a big difference between "hacking up a better Minix" and creating a Multics clone; in the latter case, there was considerable integration between:

• The kernel, providing file, computation, and security services.

  Note that the memory model was substantially different from that of Unix. With Unix, you open files and filter data in and out, and allocate memory dynamically on demand, Multics unified this, so that rather than "opening a file," you would instead "initiate a segment," so that all files would essentially be memory mapped into the address spaces of all participating processes.

  Furthermore, whilst the evils of segmentation as seen with the 64k pages on the original "IBM PC" give people the impression that segmentation is evil, Multics made pervasive use of it to keep chunks of memory distinct.

  Note that some of the later Pentium CPUs included segmentation instructions likely based on Multics that could have been used to help do memory management "the Multics way;" the lack of such on RISC (Alpha, IA-64, PPC, MIPS, ...) architectures and the perpetual impending doom of IA-32 means that having memory management in Multics style on "modern" hardware may need to wait another 15 years...

• Programming Language.

  Multics was coded in PL/1, and the fairly byzantine complexity of PL/1 provides both the merit that some operations may be much better optimized than C, and the demerit of being pretty complex.

  I just don't think "C hackers" would build Multics.

• Unix and Linux represent "minimalist" systems in a number of senses, and it seems that many prominent Linux kernel hackers prefer "more minimal" text editors like Vi to the sorts of complex tools like TECO and Emacs.

The only way I'd see it being likely would be if some of the retired Multics creators that made some Silly-Valley and/or DotCom millions decided to sponsor a several-year-long project involving a staff of on the order of a dozen pretty elite developers to provide some sort of "legacy" to retrieve Multics from the dead.

The issue is that when you connect to a cable modem, you immediately have a perhaps-24x7 connection that someone can attack. Hooking up a Windows box to this is nigh unto suicidal.

The thought I had had was to have a little "shoebox" system; no screen; only two Ethernet ports, one to go towards the outside world, and one to provide services "inside."

The "FireCard" is a quite clever idea; it cuts down on the requirements by one Ethernet port by itself replacing the usual Ethernet card that gets put in the PC.

With luck, they have some scheme for remote management whereby it knows just enough SSL (or some other cryptographic protocol) that it can be possible for folks at the ISP to log into it to help out if there are problems.

This isn't a "B1 System" for people who thought Multics wasn't tough enough to crack; it's a "C1 system" for the people running "D1 secure" PCs...

There may be good reason for that... I was wringing Google looking for a place to get real TTYs when I found this thingy about Multics covert channels. It was in /. in March. Sounds to me like separate machines is a solution, not some kind of OS shortcoming.

Take a look at the way multics handled dynamic linking. Calling a non-existant symbol caused the process to suspend. Someone could write a replacement for the missing subroutine and resume the process.

Multics had a hierarchical administration system, unix has sudo(1).

Multics was designed for large systems. Unix was designed for small systems and grew large.

Are you sure the machine was still functioning? Or just there...

From discussions on the Multics newsgroup, the only site that there seemed to still be uncertainty about was the Puerto Rico Highway Authority, and they were pretty sure that the system there didn't get the Y2K patches, and thus could not still be operating.

If you're right, then certainly let the folks at the Multicians site know of the still-running ABB system...

From the Multics Glossary entry on virtual memory:

A Multics process accesses all the data (it is allowed to) on the system as part of a huge, two-dimensional address space (see segmentation). There is no "file I/O", no buffers, no read-in, no write-out.

I take this to mean that Multics had no read(2) or write(2)... from the application-writer's point of view, the equivalent to these system calls was simple memory access.

Presenting this analogy to programmers as their primary means of file access is different from using such tricks down at a level where (theoretically) no one except kernel programmers needs to know ahout them.

It shows a completely different point of view... instead of "everything is a file", the MULTICS way seems to be "everything is core".

Multics (Multiplexed Information and Computing Service) is a timesharing operating system begun in 1965 and used until 2000. The system was started as a joint project by MIT's Project MAC, Bell Telephone Laboratories, and General Electric Company's Large Computer Products Division. Prof. Fernando J. Corbató of MIT led the project. Bell Labs withdrew from the development effort in 1969, and in 1970 GE sold its computer business to Honeywell, which offered Multics as a commercial product and sold a few dozen systems.

It had TONS and TONS of features (look here for a list), but unfortunately it took too long to implement, and when these features were finally implemented, the resulting OS was so damn slow nobody wanted to use it. Consequently it was canned.

Fortunately for us, Dennis Richie and Ken Thompson decided to pare down some of the features and create a version of "Multics without the balls." Thus Unix was born (the name being a pun on "Multics").

And we all lived happily ever after!!