Path: utzoo!yunexus!davecb From: davecb@yunexus.UUCP (David Collier-Brown) Newsgroups: comp.arch Subject: Slandering Project MAC (was Slandering Intel) Message-ID: <2126@yunexus.UUCP> Date: 7 Jun 89 12:03:06 GMT Article-I.D.: yunexus.2126 References: <182@mipos3.intel.com> <76700071@p.cs.uiuc.edu> Reply-To: davecb@yunexus.UUCP (David Collier-Brown) Organization: York U. Computing Services Lines: 37 In article <76700071@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: [responding to a discussion involving Intel's idea of segmentation] > >Well, if you're going to point fingers, why don't you blame MIT and >project MAC? They were the one of the ones that took segmentation to >outrageous extremes to begin with. Intel was only copying them. I beg to differ. The only similarity between the segments (aka files) defined by project MAC and the segments used for address-space-extension by intel is in the name. Project MAC is not, was not and never will be responsible for this particular misuse of the terminology. To go to the primary sources... In most modern file systems following CTSS, files (as do segments) carry unique names, have attributes, are created, destroyed, allowed to grow and shrink, have access controls applied to them (i.e., may be shared), and are structured in a directory hierarchy. A file system maintains this structure and offers retrieval services, backup services, and so forth. Only the difference (albeit very significant) that segments are "instantaneously" shareable by virtue of being directly addressable in Multics programs distinguishes the segment from the file. -- from Organick, E. "The Multics System: An Examination of Its Structure", Cambridge, Mass (The MIT Press), 1972. --dave (sources, people, sources! we're computer **scientists**, don't forget) c-b -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 223-8968 | He's so smart he's dumb.