The Last Multics System Decommissioned

Bell Would? writes: "A key feature of the brief news item, 'The end of the Multics era,' in the latest issue of the The Risks Digest is the 'list of goals' Multics had fulfilled which, as the author describes them, are as relevant today as they were 35 years ago." Odd -- I assumed these were all long since junked or put into museums, since my first exposure to the name Multics was in books which spoke mostly in the past tense. That list of goals is one that I hope architecture designers consult frequently.

Sigh

I guess there won't be any Real Men around any more. After all, it is a well known fact that Real Men use Multics.

Re:Intro to Multics 101

Multics had a rather interesting approach to file I/O, IIRC - when you loaded a file, it got mapped straight in to virtual memory (the machine had a 48 bit address space back in the 1960's, so you could get away with stunts like this). Read/write was just a matter writes to memory!!

That's pretty much what we do now in Linux - when you write it doesn't go to disk, it goes onto memory pages. When you read you're reading from memory pages and if they're not there, they get 'swapped in' from your file using the same mechanism we use for virtual memory, though we bypass the paging hardware in this case (it's faster that way).

Neat idea - but imagine the 32-bit address space crunch happening 20 years ago instead of now :)

We get around that by using disjoint pages of virtual memory mapped into the file's address space with a hash table, so the file has a 44 bit address space - that should be enough for a while. This works well, and doesn't cause virtual memory fragmentation. We'll probably start mapping the files in chunks larger than one page pretty soon.
--

Re:Multics system at University of Calgary

Yes, the University of Calgary housed two Multics systems in the 80's: a 6-CPU system and a 1-CPU test system. The company that supported Multics after Honeywell (ACTC) was a spin-off from U of C.

Multics (at UofC) was the first large system I used, and I have many fond memories of it. I attended the Shad Valley (technology + entrepreneurship) summer program in 1984 and spent hours absorbing 'everything Multics'. On-line manuals, pathnames, processes, e-mail, chatting, windowing systems (character-based) ... all very fascinating to a tech-hungry teenager.

It's interesting to note that Multics underwent a development surge in the early 80's and despite the aging hardware design still had a number of sites at that point (Ford, Canadian defense, US DOD).

I'm sad to see it go, though its time has come (without portability, it was doomed to die with the hardware). I remember touring the U of C computer room when a tech was on site, reportedly doubling the cache *width* while the system remained on-line (I presume he was taking one CPU offline at a time). The LED bargraph pads showing CPU utilization for each processor that were scattered around the room were quite impressive too :-)

Re:MULTICS 2000

I had the "opportunity" to work as a systems operator on *6* Multics systems, from 1986 to 1988. (Yes, I'm listed with Multicians.org.) Your interpretations of some of the goals of the Multics project is somewhat colored by modern technology. Let me explain what some of those goals meant to the Multicians, and why they still aren't met by modern operating systems:

• Continuous operation analogous to power & telephone services
  This meant that the entire system was hot swappable: disk drives, CPUs, Memory units, IO units. Of course, your odds of the system surviving the addition or subtraction of any one of these were ... low. This was more a function of the hardware architecture than the OS, but most modern computers don't take this to the extremes of Multics. Since hardware is so cheap, it's much more effective to build redundant clusters with shared, redundant storagem where you add and subtract entire systems, instead of adding and subtracting components.
• A wide range of system configurations, changeable without system or user program reorganization.
  This is the hot-swappable hardware thang again. You could add a CPU to a system without interrupting the processing on the rest of the system. System software updates were quite a different matter -- that generally required a system restart, and there were still "system" drives whose failure could cause the entire system to crash.
• Support for selective controlled information sharing.
  This refers to classifying information, not filesystems. Multics could run with Classified, Secret, and Top-Secret information (and programs) all co-resident, and without a lower-classification program being able to access higher-classification information. No modern operating system works this way; the set of systems that replaced the Multics group that I worked on was *3* separate Unix networks, one for each security classification.
• Hierarchical structures of information for system administration and decentralization of user activities.
  This refers to the traditional hierarchical file structure, with hierarchical user management thrown in for good measure. What CP/M and MS-DOS stole from Unix, Unix in turn stole from Multics.

In general, Multics achieved its goals, though the cost was too high. More recent operating environments have judged the cost of some of those goals (primarily security) to be so unrealistic as to be completely undesirable. While I think that Multics aimed too high on some goals, I think that too many operating systems (including Linux) aim too low.

Are you moderating this down because you disagree with it,

Re:Longest Lasting O/S thus far?

Most of the large airline systems run on IBM's Transaction Processing Facility (TPF). IBM keeps updating it, even added TCP/IP a few years back, but it's essentially 1960's technology. By the way, go to a web site like Expedia or even the new Orbitz site and you're still hitting mainframe assembler code in the background somewhere... Try these on for size: most applications are written in assembler, manually divided into 4K blocks. No virtual memory, all storage preallocated at sysgen into fixed size blocks (woohoo - no fragmentation!). No filesystem, all you get is a shitload of blocks (381 bytes, 1055 bytes, 4K) and it's up to the programmer to do the rest. I've seen code on these systems that was written in 1970-1972 and is still in use today, taking thousands of transactions per second. Somehow I don't see W2K apps lasting 30 years.

Re:Museums

Here [tcm.org] is one. (seems to be down at the moment)
And here [obsoleteco...museum.org] is another.

The end of an OS

Multics was ahead of it's time. Now It's at the end of it's time. I hope that before I reach the end of my time, I read an article about the last Windows system reaching it's final blue screen.

Re:Museums

Here are links to a couple of computer museums here in the US.

The Computer Museum of America [computer-museum.org]

Compuseum [compustory.com]

-gerbik

MULTICS 2000

Looks to me like not only are these principles still applicable, but they're pretty integral parts of everybody's favorite OS:

• Convenient remote terminal use
  Linux/BSD/UNIX: Check! telnet/ssh and X can make nearly everything network transparent
  Windows: Need an extra program like PCanywhere, and even then it's single user. (but isn't m$ fixing this in win2k?)
• Continuous operation analogous to power & telephone services
  Well, all modern operating systems can do this in theory at least ;-)
• A wide range of system configurations, changeable without system or user program reorganization.
  Windows: Only three reboots to install a sound card!
  Linux: Exchange anything but the kernel without rebooting
  Microkernels: 8-D
• A highly reliable internal file system
  Windows: NTFS seems to be close enough for most people Linux: ext3 and reiserfs
• Support for selective controlled information sharing.
  Windows: Network Neighborhood ought to be enough for anybody!
  Linux/UNIX/BSD: NFS, Coda, FTP, scp, etc...
• Hierarchical structures of information for system administration and decentralization of user activities.
  Not entirely sure what they mean by this...
• Support for a wide range of applications.
  Check.
• Support for multiple programming environments & human interfaces
  Windows: IDEs, IDEs and more IDEs.
  Linux: Your choice of gcc,emacs,kdevelop,vi, or whatever else you find on freshmeat
• The ability to evolve the system with changes in technology and in user aspirations.
  Open source!

Intro to Multics 101

For those of you who have no idea what Multics is, here's a brief summary from www.multicians.org [multicians.org]:

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 [multicians.org] 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!!

Re:Sigh

Not anymore. Real Men use BSD.