Talk:Multics

From Wikipedia, the free encyclopedia

Contents

[edit] Aside

As an amusing aside, in the late sixties I was convinced that it was feasible to write a portable OS in a high level language (PL/I being the best candidate at the time). It was (and still is) my estimate that (except for device drivers, whose plethora makes up the bulk of Linux) some 60% of an OS could be written in a HL language, the other 40% requiring Assembly. For example, the code to do scheduling is architecture independent, the code to implement scheduling decisions (start/resume) a process is architecture dependant.

Until the mid eighties, when Unix became well known as a viable, portable, OS, nobody I knew agreed with me. It was for this reason that for many years I did private contracting/development under the name "Blue Sky Enterprises". See blue sky project. --Buz Cory

[edit] More content

Well, that's enough for now. It needs to be improved somwhat n the History section, but it's mostly there elsewhere, I think. Now I gotta write all those articles about Corby, Jerry, etc, etc, etc. Noel 10:02, 17 Aug 2003 (UTC)

[edit] Web archives

Neither the [http://www.mit.edu:8001/afs/net/user/srz/www/multics.html MIT Multics site], nor the [ftp://ftp.stratus.com/pub/vos/multics/multics.html Multics Repository at Stratus Computer] ("Last Updated 9 April 2001") have been updated in quite a while, and also don't contain much information that's not on Tom van Vleck's Multics site. If anyone is looking to make the entry shorter, those are candidates for editing out. Noel 14:26, 3 Nov 2003 (UTC)

Try drilling down into the links on those sites, and you'll discover a lot of Multics material. The sites may not have been changed recently, but then again, neither has Multics. Also, there is benefit in getting a variety of sources of information, especially non-mirrored Web sites that can occasionally have problems with their hosts being unavailable. Bevo 06:51, 4 Nov 2003 (UTC)
Yes, there is a lot of stuff - but almost all of it's also on the Van Vleck site. E.g. the only paper on the Green site is also on VV's site. Most of the MIT content is earlier versions of stuff VV wrote. Etc, etc. But about the redundancy - I was just thinking yesterday "Goodness knows what we'll do when Tom's gone!" :-) I'll have to look into getting the MIT-LCS Library to take it over.. .Noel 14:54, 4 Nov 2003 (UTC)

[edit] TSO, MTS, etc

What's the point to adding those systems to Multics' "See also"? You could add just about every modern operating system. (In fact, that's not such a bad idea - I'll add List of operating systems instead.) Noel (talk) 20:33, 11 Dec 2004 (UTC)

I felt Time Sharing Option (TSO), Michigan Terminal System (MTS), and MUSIC/SP were all especially worthy of "See also" listing under Multics because they were all contemporaries, and they all had historical significance in the time-sharing revolution. True, Multics also had influence on other operating systems, especially as the inspiration for UNIX, but historically those other three are (I think) worth specific mention. -- User:166.153.174.134 17:01, 11 Dec 2004

TSO? I can't see that one (nor the others either, although let's focus on this one for the moment). Yes, it got a certain amount use (and is still in use today), but what was the relationship between TSO and Multics? None, as far as I know. At least with CTSS and CMS there's a tie, but TSO and Multics? There's no connection at all (in fact it's an anti-connection - with OS/360, IBM went in completely the other direction from Multics, causing the rupture in the previously close IBM/MIT relationship that never was overcome). Other than being rough contemporaries (and the same can be said of literally dozens of other systems), there's nothing special about TSO as it relates to Multics, is ther? And as for "historical significance in .. time-sharing", what technical features did it have that influenced later systems? Again, none that I can think of. So, again, I fail to see the case that there's any relevance to mentioning TSO in the context of Multics. Yes, it would be relevant to a History of time-sharing page, but that's not what this page is about. Noel (talk) 22:12, 11 Dec 2004 (UTC)

I think you make good points. Maybe it would make sense to have a subsection that lists "Other Early Time Sharing Systems" or something like that. I'll make an attempt along those lines in the article.

Ah, that would still be somewhat off-topic for the Multics article. However, an article on Early time-sharing systems would be a good place for it, and a link to said article would definitely be appropriate in the "See also" here. Noel (talk) 23:59, 11 Dec 2004 (UTC)

I went ahead and moved the "others" to time-sharing (and cleaned up that article slightly while I was at it, including mention of Multics). I think everything is in pretty good shape now. -- User:166.153.174.134

Sounds good, moving further comment there. Noel (talk) 18:31, 12 Dec 2004 (UTC)

[edit] Technical issue

jnc wrote:

"Equally importantly, with the appropriate settings on the Multics security facilities, the new code could then access data structures maintained in a different process. Thus, to interact with an application running in part as a daemon (in another process), a user's process simply performed a procedure call instruction to a code segment which it had dynamically linked to (a code segment which implemented some operation associated with the daemon). The code in that segment could then modify data maintained and used by the daemon. When the request was completed, a simple procedure return instruction returned control of the user's process to the user's code."

This is only true if the dynamically linked code sends an interprocess message to the daemon and waits for a reply. Dynamically linked code becomes part of your process's address space, and executes with your access authority.

Multics did not have a feature like the Unix setuid facility. (Early Multics papers suggested that we would provide a "trap" attribute but we couldn't figure out how to make the trap procedure execute in the correct context.)

The Multics ring facility does allow a user program to call a routine that can do things the caller could not. For example, mailbox segments were maintained in ring 1. A user program can call the ms_ gate to add a message to someone's mailbox, even though the mailbox segment is inaccessible to normal user code. All code in a given ring had to trust the other code in that ring, though. User:thvv

Ah, actually, if you read what I wrote very carefully, it is technically correct! Nowhere does it say that the process doing the call gained the identity of the owner of the code! (Although I probably was thinking along the incorrect lines you mention when I wrote it! :-)
See, when I wrote this, I was thinking of the earliest versions of Dave Clark's TCP code, which worked in exactly this way (the daemon managed the retransmission timeouts, and also was the initial receiver of all incoming packets), but normal user calls did not transfer control to that process (via an IPC message); they just did a straight procedure call to the TCP code, which munged the common database. Obviously, now that you point it out, it operated insecurely, because the data segment would have had to have had write-access to all users; i.e. not mediated by Dave's TCP code.
The line about "with the appropriate settings on the Multics security facilities" can be read to mean just that (hence my comment about "technically correct"), but I agree that it gives an incorrect impression.
As you point out, to do what I wrote in a secure way would have involved using rings - although there's still a point there. To use the example above, for that type of system (implemented using rings to protect its operation) to be callable by any user, the database of the daemon would still have to be world-writable (although only to the lower ring). That would still allow any process executing in that lower ring access to it. Some sort of compartmentalization (e.g. via something like SUID) would have been even more secure.
Now that I've thought about it for a while, I think the Right Thing is actually to just leave the text in the article the way it is, *but* to enshrine our discussion of this point here.
My reasoning is that in fact my description is correct (since if one were using rings to secure such a subsystem, which is possible, one would have to use "the appropriate settings on the Multics security facilities"); however, a discussion on *how* to do that is a little to abtruse for a general encyclopaedia article. But leaving it here is perfect, so editors who know more about Multics can see the rationale. Noel (talk) 16:21, 7 October 2005 (UTC)

[edit] Errors

Though the auther seems to fawn over Multics, he has erred on some points: First many of the 'firsts' of Multics wee in fact pioneered by the little remembered MCP (Master Control Program), the operating systems shipped with the Buroughs B-5000 and which is still in use to this day on Unisys' Clearpath line of servers. Secondly, UNIX was 'derived' from Multics only in that Multics served as the antithesis of the approach taken by the designers of the UNIX system, who tried to avoid the mistakes which lead to the failure of Multics as a practicable system. —The preceding unsigned comment was added by 128.194.38.243 (talk • contribs) 07:28, 27 August 2005.

There are plenty of direct inheritances from Multics to Unix. Tree structured file systems with long names. The shell. seek, tell, ioctl. Multics did not fail as a practicable system for another 15 years. See http://www.multicians.org/myths.html User:thvv
Your view, that "UNIX was 'derived' from Multics only in that Multics served as the antithesis of the approach taken by the designers of .. UNIX" is directly contradicted by the authors of Unix themselves, in their ACM paper (Ritchie/Thompson, The Unix Time-Sharing System, CACM 17, No. 7, July 1974) wherein they say "On a number of points we were influenced by Multics".
Although, to be fair, in another paper (Ritchie, Unix: A Retrospective, BSTJ Vol. 57, No. 6, Pt. 2, July-August 1978), it says "a good case can be made that [Unix] is in essence a modern implementation of MIT's CTSS system." (although I think that's slightly hyperbolic, for effect).
IMO, the reality is somewhere in the middle; Unix is clearly a big step past CTSS, and many of those big steps came from Multics. On the other hand, Unix (or, more properly, early Unixes - modern ones, with dynamic linking, mapping, etc are a different kettle of fish) is a distinctly very different path from Multics, and conceptually closer to CTSS than to Multics. Noel (talk) 16:32, 7 October 2005 (UTC)

[edit] Size comparison

I've looked for data on contemporary large OS sizes, but I'm having a hard time finding much. None of my reference books on operating systems give them, and my IBM history books do not give sizes for e.g. OS/360. I did find these online:

  • "Approximately one million lines of code" [1]
  • "in 1964: over a million lines of code" [2]

but I don't know if those include things like the Fortran and PL/I compilers, etc. Still, they indicate that Multics was not significantly larger than contemporary system. Noel (talk) 18:45, 7 October 2005 (UTC)

[edit] Removed text

Someone removed the following text:

Among its many new ideas, it was the first operating system to provide a hierarchical file system, a feature that can be now found in virtually every operating system.
It was the first to have a command processor implemented as ordinary user code - an idea later used in the Unix shell (although the details are different, since Multics possessed powerful mechanisms which Unix lacks).

I have looked for documentation relating to the first of these points, but I can't offhand find anything. R.C. Daley and P.G.Neumann, A General-Purpose File System for Secondary Storage (FJCC, November, 1965), the earliest paper on the Multics hierarchical filing system, lists, in a very short References section, only two references which might be on point:

  • T.H. Nelson, A File Structure for the Complex, the Changing, and the Indeterminate (ACM, August, August) 1965
  • M.V. Wilkes, A Programmer's Utility Filing System (Computer Journal, October, 1964)

The latter seems [3] to be something different: "Describes a general-purpse text editing and filing system implemented for the Edsac 2 computer." The former is Ted Nelson's first Xanadu/Hyperlink paper.

If anyone has anything showing an earlier system with a hierarchical file system, can the please post it here? (Citations to contemporary documents, please.)

Similarly for the command processor running as ordinary user code; can anyone provide a citation to anything earlier? Noel (talk) 19:13, 7 October 2005 (UTC)

[edit] MULTICS vs Multics

It is possible to see the two different spellings. Is there a good one and a wrong one or the both are correct like UNIX and Unix ? 16@r 23:23, 30 July 2006 (UTC)


The project very definite about this: only "Multics" is correct. And it is not an acronym. See http://www.multicians.org/multics-humor.html#MULTICS

(According to Dennis Ritchie, Unix was the original name, a coined word like Multics. The AT&T trademark overseers preferred UNIX to distinguish it in written text.)

Thvv 13:40, 5 May 2007 (UTC)

[edit] MIT Source Archive

The MIT source archive appears to be inaccessable to the public, I got a 403 Forbidden going to it. --Blah2 11:54, 8 July 2007 (UTC)

[edit] myths

the mention of myths page as "myths" is not subjective IMO. Khaled.khalil 10:06, 2 August 2007 (UTC)

[edit] Open Source

One of the "side-bars" state that Multics was open-sourced in 2007 while the main article states 2006. As far as I understand, it was 2007, but this needs to be confirmed. —Preceding unsigned comment added by Andreas Toth (talk • contribs) 00:19, 14 November 2007 (UTC)

[edit] Performance, Success, MIT vs. Bell Labs

When I was a Bell Labs, I was told that Multics was horribly inefficient. At some point in development, it could only support two users and thus satisfied the definition of timesharing. The article is very glowing, but perhaps there should be some digging into criticism. It was clear from Ritchie and Thompson and others in lab 1127 that there was a deep disagreement about MIT's programming culture and software engineering philosophy. From the Bell Labs perspective, it was viewed as undisciplined and unwary of complex and messy coding. In some reciprocal visits of Richard Stallman to Bell and Rob Pike to MIT, there was quite a bit of hostility in evidence, and I wonder if that goes back to divisions that formed during the Multics collaboration? DonPMitchell (talk) 06:02, 13 January 2008 (UTC)