pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/06/90)
On 1 Dec 90 23:01:26 GMT, eric@snark.thyrsus.com (Eric S. Raymond) said: eric> I will incorporate several of your corrections. Upon doing a eric> context grep for MULTICS it does seem that the references to it eric> are uniformly negative. That is unfair and was unintended; though eric> I agree with the charge that MULTICS became somewhat bloated and eric> at least partly a victim of design grandiosity, I also do think eric> that it expressed some of the best thinking about OS design in its eric> day and doesn't deserve to be `sneered at' by anyone. Especially as it is smaller and faster and more efficient than SVR4, or 4.3BSD, etc... Multics was a large system for its day -- it was slow when running more than a dozen users on a 1MIPS, 2MB machine :-). I remember enjoying excellent response time on an 8 MIPS, 32MB machine (approx.) when logged in with a couple hundred other users. I would really like having somebody tell us what is the wired down code size of a fairly recent Multics release (10, for example) vs. SVR4 or Ultrix or SunOS etc... -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
gillies@m.cs.uiuc.edu (12/07/90)
Mutlics segments are/were limited to 262K (or less, I don't remember exactly). Systems like 4.3BSD and System 5.0 move beyond these PDP-11ish limitations into the modern world, where files can be 20 megabytes and filesystems can have 100,000 inodes or more, filenames can be arbitrary length, etc. etc. etc. If you had to use Multics today you'd be screaming in pain due to the hardwired limitations. - Don
barmar@think.com (Barry Margolin) (12/08/90)
In article <6100008@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: >Mutlics segments are/were limited to 262K (or less, I don't remember >exactly). Systems like 4.3BSD and System 5.0 move beyond these >PDP-11ish limitations into the modern world, where files can be 20 >megabytes and filesystems can have 100,000 inodes or more, filenames >can be arbitrary length, etc. etc. etc. If you had to use Multics >today you'd be screaming in pain due to the hardwired limitations. While Multics segments are limited to 255K (that's words, so it's almost 1Mb), there is a library routine that supports treating specially-marked directories as a single file constructed of all the segments in the directory; this is called a Multi-Segment File, and the msf_manager_ library is pretty straightforward to use (it can be used to access ordinary segments as well, and will automatically convert them to MSFs when necessary). Additionally, the I/O library interface to files (the Multics equivalents of Unix open/read/write) uses msf_manager_, so it will transparently support huge files. I think an MSF can conceivable grow to a few gigabytes, if you've configured the disk with enough inodes. When the Multics C compiler was implemented we even taught the compilers and dynamic linker how to deal with multi-segment executable files (it support static linking of C programs, to deal with namespace collision problems, and this tends to bloat the executables beyond a megabyte). MSFs can be considered analogous to Unix indirect blocks. The difference is that Multics puts this functionality in a user-ring library (since Multics has been doing dynamic linking and shared libraries since day 1, libraries are cheap), to keep the kernel interface simple. So whose kernel is bloated? The Multics kernel is amazingly simple and pure compared to modern Unix kernels, although not quite as pure as some recent alternate kernels such as Mach. Very little is in there unless it *has* to be there. The one glaring exception is the terminal driver, which would make the BSD terminal driver look simple, yet doesn't do many of the things most other terminal drivers do (e.g. it doesn't have a settable interrupt character -- it's hardwired to the BREAK signal); however, when video terminals became popular a user-ring replacement was developed to support them (it supports programmable input editing a la Emacs, input line recall (like some Unix shells, but in effect for all programs, not just the shell), automatic output paging, etc.). Unix is slowly working its way towards the elegance of Multics. The System V streams mechanism is a good step (it's similar to the Multics I/O module mechanism, except that Multics does it in the user ring), and some flavors of Unix now have dynamic linking. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
benson@odi.com (Benson I. Margulies) (12/10/90)
I'll regret this, but: Multics wired a trivial amount of memory. 95% of the kernel was paged, only interrupt and fault handling was wired. Some day, Unix implementations may do the same. (AIX does now ...) Much Multics folklore comes from people who read Organic's (I'm sure I'm spelling his name wrong) book, which rescribed the state of the system long before I ever worked on it. Other comes from internal MIT polemics taken far out of context, like the Jargon file. Not to mention that much of the Jargon material was written at about the same time as Organic, when the MIT system was extremely slow, with less than 1MB of memory, and a whole bunch of users. Multics had all the interesting features of V.4, but it only had them once, not 4 times from 4 predecessor versions merged together. Multics didn't require the equivalent of fsck after reboot. Multics had dynamic linking. Multics had fully symmetrical multiprocessing. It had the same functionality as streams. It was the first system certified B2, for what that's worth. Its commands had, by and large, comprehensible and consistent names and arguments. Multics didn't require one to add a device driver to the kernel to support a new device (except for those that contained file systems.) All Multics system facilities were available from both commands and subroutines. No Multics subroutine printed a mysterious error cookie on the terminal, they all returned some sort of error indication. Multics could fit, without much bother, on the machines that are now required for commercial Unix systems -- 12MB, several mips. The Multics development group never found time or interest in writing about the system, and the MIT academic community had written operating systems off as old hat years ago. In short, Multics' sins were that it was ahead of its time and that it was owned by a company that preferred to see it dead than in competition with its batch OS offering, GCOS. Five to ten years ago, little v7 Unix was a neat way to get a nearly-Multics OS onto an itty bitty computer. Now, V.4 and related projects are running as fast at they can to stick back in everything that the original Unix authors (refugees from the Multics project) took out. Only it dosen't always fit so well. Such is life. Finally, only the ignorant spelled Multics in capital letters. ps: in case you haven't guessed, I was one of its developers, and I miss it. I hope that there's a place in hades reserved for the Honeywell execs responsible for never selling it seriously. -- Benson I. Margulies
bzs@world.std.com (Barry Shein) (12/10/90)
>Much Multics folklore comes from people who read Organic's (I'm sure >I'm spelling his name wrong) book, which rescribed the state of the >system long before I ever worked on it. AUTHOR Organick, Elliott Irving, 1925- TITLE The Multics system; an examination of its structure [by] Elliott I. Organick. PUBLICATION Cambridge, MIT Press [1972] CALL NUMBER QA76.5 .O73 -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
isodonovan@brb.isnet.inmos.co.uk (12/12/90)
Hi! In article <1990Dec9.194753.436@odi.com>, benson@odi.com (Benson I. Margulies) writes: > I'll regret this, but: maybe, but not on my account! I used a Multics system (running on a Honeywell DPS 870) for about 2 years when I worked at the Compuing Centre at University College Cardiff (Wales, UK). I only have a user's appreciation for it - I know nothing of the internal workings. All I can say is that I found it easy to use - very intuitive. Being able to access the abilities of the OS as commands or as subroutines was great. Simple things like hijacking the prompt routine at any time to make it do almost anything... Access control lists were easy, as were removing a file from a directory and replacing it with a pointer to somewhere else... Above all it was friendly and easy to understand. I had this idea that as time went on computer systems should get simpler to use, more friendly, easier to understand. Multics did all of those things like no other system I've worked with. It's been good to see some of these functions creeping into VMS (which I use most of the time) but it still does not have the same 'feeling' that Multics did. Unix, by contrast seems to be quite alien and hostile (MS-DOS ditto). All in all, I would have preferred a future of Multics+Algol68 to one of Unix+C! Cheers, Brian > > > -- > Benson I. Margulies -- o---------------o-------------------------------------------------------------o : # # # # : Brian O'Donovan - I.T., Inmos, Newport, Wales, UK, NP9 1YJ. : : # # # # # # : Tel : (+44 or 0)-633-810121-X383 o-----------------------: :# # # # # # # #: Fax : (+44 or 0)-633-810820 :(o)-(o) NISC: The NO : :# # # # # # # #: Telex: 497053 : | Instruction-Set: :# # # # # # # #: eMail: Isodonovan@Isnet.Inmos.Co.Uk : v Computer. : :# # # # # # # #:-------------------------------------o-----------------------: : # # # # # # : "When the chips are down we play our aces, : : # # # # : hiding them in our broken places." -- The Roches. : o---------------o-------------------------------------------------------------o
car@trux.UUCP (Chris Rende) (12/20/90)
From article <6100008@m.cs.uiuc.edu>, by gillies@m.cs.uiuc.edu: > > Mutlics segments are/were limited to 262K (or less, I don't remember > exactly). Systems like 4.3BSD and System 5.0 move beyond these > PDP-11ish limitations into the modern world, where files can be 20 > megabytes and filesystems can have 100,000 inodes or more, filenames > can be arbitrary length, etc. etc. etc. If you had to use Multics > today you'd be screaming in pain due to the hardwired limitations. > > - Don It is true that Multics segments are limited to 256k (or there abouts). (Because of the Honeywell Level 68 architecture). However, Multics has another file type: Multi-segment files. Multi-segment files can be quite HUGE. No, you wouldn't been screaming in pain due to hardwired limitations. Multi-segment files have been part of Multics since before 1980. (That's when I first started using Multics). On the contrary, many who currently use Multics are going to miss it. (Anyone for a Multics mailing list?). car. -- Christopher A. Rende Central Cartage (Nixdorf/Pyramid/SysVR2/BSD4.3) uunet!edsews!rphroy!trux!car Multics,DTSS,Unix,Shortwave,Scanners,UnixPC/3B1 trux!car@uunet.uu.net Minix 1.2,PC/XT,Mac+,TRS-80 Model I,1802 ELF trux!ramecs!car "I don't ever remember forgetting anything." - Chris Rende