Xref: utzoo alt.folklore.computers:7839 comp.unix.internals:1319 comp.misc:10842 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!cs.utexas.edu!uunet!odi!benson From: benson@odi.com (Benson I. Margulies) Newsgroups: alt.folklore.computers,comp.unix.internals,comp.misc Subject: Re: Multics bloat??? Are you sure??? Message-ID: <1990Dec9.194753.436@odi.com> Date: 9 Dec 90 19:47:53 GMT References: <1YbxGQ#2fbT353y6xKD8DT83C4bFDpV=eric@snark.thyrsus.com> <1990Nov30.172512.5282@sctc.com> <1Ydnzg#6fNyr23fxBD30ZbOTr9Txc6Z=eric@snark.thyrsus.com> Reply-To: benson@odi.com (Benson I. Margulies) Organization: Object Design Inc., Burlington, MA Lines: 56 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