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. Ata
jms@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!"