Ata@multics.radc.af.mil (John G. Ata) (09/01/89)
Delivery-Date: 28 August 1989 10:24 edt
Delivery-By: Ata.SysMaint
Sender: amiga-relay-request at UDEL.EDU
Date: Saturday, 26 August 1989 00:55 edt
From: Kent Paul Dolan <xanthian at WELL.UUCP>
Subject: Re: Why do you need metaphor? (Re: What should be learned from Unix
To: amiga-relay at UDEL.EDU
Newsgroups: comp.sys.amiga.tech
Keywords: Multics, Unix, Bell Labs
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
All the blurb about Multix is also wide of the mark. I was responding
to a series of articles all claiming in essence "Unix isn't so great,
look at this (long-after-Unix-developed) much nicer way to chose a
metaphor of device access"; and I attempted to provide a bit of historical
context to the discussion. This does not require me to trace the concepts
back to Babbage, and frankly, except for being the predecessor that drove
the Unix developers away to do things better, Multics was a dinosaur, however
nice the ideas incorporated. Don't believe me? Check its market share
^^^^^^^^^^^^^^^^^^^^^^
versus Unix or even the OS-360's children. ;-)
I hope you are not judging the merits of an operating system by it's
market share. The fact that Multics didn't do well in the market place
has really nothing whatsoever to do with the technical merits of the
operating system. There were many different forces at play here
including the non-marketing of Multics by its vendor and the prohibitive
cost of the hardware platform it ran on. Perhaps you think that MS-DOS
is a technically superior operating system to the AmigaOS because it's
market share is so much larger. :-)
improve the world. The Unix file as a stream of bytes paradigm made a
horrendously complicated process in every other file system much easier
to comprehend. And no, that god-awful segmented mess that was Multics
idea of a file doesn't begin to compare.
Indeed! Perhaps you would like to make a comparison? I suspect that
although your knowlege of Unix is present, your understanding of the
Multics system is not all that deep. Please note that the segmentation
and paging on Multics, as well as the file structure in a stream file,
is invisible to the programmer where a segment to most programmers is
merely a file.
John G. Atajms@tardis.Tymnet.COM (Joe Smith) (09/02/89)
In article <22976@louie.udel.EDU> Ata@multics.radc.af.mil (John G. Ata) writes: > From: Kent Paul Dolan <xanthian at WELL.UUCP> > improve the world. The Unix file as a stream of bytes paradigm made a > horrendously complicated process in every other file system much easier > to comprehend. And no, that god-awful segmented mess that was Multics > idea of a file doesn't begin to compare. > >Indeed! Perhaps you would like to make a comparison? I suspect that >although your knowlege of Unix is present, your understanding of the >Multics system is not all that deep. Please note that the segmentation >and paging on Multics, as well as the file structure in a stream file, >is invisible to the programmer where a segment to most programmers is ^^^^^^^^^ >merely a file. From my short experience with Multics, the segments were NOT invisible. Each segment was limited to 256K words (36 bit words, 18 bit addresses). The instant you tried to make a sequential file bigger than 256K words (1 megabyte), segments became PAINFULLY obvious. You had to stop what you were doing, create an empty multi-segment file (which acted sort-of like a subdirectory), copy half of your input file to one segment, half to the other, delete the original, rename the new file, and then try to continue as if nothing had happened. Small files were wonderful, large files were not. Maybe they fixed it after I stopped using Multics, but I agree with Kent; large files on Multics were a god-awful segmented mess. The ability to map a file into your virtual address space is great, provided that the OS and/or CPU is not hobbled with a too-small limit on ranges of virtual addresses. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"