Slashdot Mirror
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.
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.
Tarsnap: Online backups for the truly paranoid
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.
--
Life's a bitch but somebody's gotta do it.
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.
... all very fascinating to a tech-hungry teenager.
:-)
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)
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
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:
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
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.
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.
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,
We call it art because we have names for the things we understand.
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.
Here is one. (seems to be down at the moment)
And here is another.
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.
134340: I am not a number. I am a free planet!
Here are links to a couple of computer museums here in the US.
The Computer Museum of America
Compuseum
-gerbik
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?)
Well, all modern operating systems can do this in theory at least
Windows: Only three reboots to install a sound card!
Linux: Exchange anything but the kernel without rebooting
Microkernels: 8-D
Windows: NTFS seems to be close enough for most people Linux: ext3 and reiserfs
Windows: Network Neighborhood ought to be enough for anybody!
Linux/UNIX/BSD: NFS, Coda, FTP, scp, etc...
Not entirely sure what they mean by this...
Check.
Windows: IDEs, IDEs and more IDEs.
Linux: Your choice of gcc,emacs,kdevelop,vi, or whatever else you find on freshmeat
Open source!
-- 2 + 2 = 5, for very large values of 2
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!!