Talk:Multics

message: The part page displayed by Google looks fine until you gt to tyhe last line, below
:Multics (Multiplexed Information and Computing Service) is an influential early time-sharing operating system which is based on the concept of a single-level memory. Multics "has influenced all modern operating systems since, from microcomputers to mainframes."
:Software genre: Operating system
:Developer: General Electric, Bell Labs, Ken Th...
:Languages used: ALGOL
Did we even offer algol? 
-- DRBrown.TSDC@Hi-Multics.ARPA  — Preceding unsigned comment added by 2607:FEA8:5620:6C3:0:0:0:BA17 (talk) 19:14, 7 April 2020 (UTC)
replies: text: This seems to have been corrected.  Riordanmr (talk) 22:53, 23 May 2020 (UTC)
thread_title: Google Oops

message: 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)
thread_title: More content

message: 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)
replies: text: 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)
replies: text:  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)
thread_title: Web archives

message: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title: TSO, MTS, etc

message: 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)
thread_title: Technical issue

message: 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)
thread_title: Errors

message: 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" 
* "in 1964: over a million lines of code" 
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)
thread_title: Size comparison

message: 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  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)
thread_title: Removed text

message: 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)
replies: text: the old AFS Multics pages seem to have been relinked to http://web.mit.edu/multics-history/ which is a more comprehensive and later version. Thvv (talk) 13:46, 1 October 2008 (UTC)
thread_title:  MIT Source Archive 

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

message: 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)
replies: text: 09 November 2007 is the date that the Multics source was made available at MIT.  The agreement to do so took about 6 years. Congratulations to the Bull and MIT personnel who made this happen. Thvv (talk) 13:49, 1 October 2008 (UTC)
replies: text:  This page needs a little more elaboration of pre-1975 source distribution agreement. Ken and Dennis were already looking at starting ports to the Interdata/Perkin Elmer 7/32, 8/32, and 3200 series as well as IBM 360/67 and Univac 1100 hardware by 1975. This has influence on source porting. Don's comment about OSes written in HLLs is important because this super-efficiency hindsight is lost to younger generations. It was a common red herring propagated by IBM salesmen and the bulk of a lot of bosses. Sure it was proprietary but elaboration on that is needed. 198.123.56.106 (talk) 19:29, 20 July 2012 (UTC)
thread_title:  Open Source 

message: There was a discussion  on the Muticians list recently that asked about Professor Dunovan:
"Someone added a bunch of references to John J. Donovan on September 14,
2009. The history page doesn't say who."
It's not obvious if he was a major contributor, on the level of Professor Corbato: can someone confirm/deny this?
--dave (mostly a lurker) c-b  —Preceding unsigned comment added by Davecb (talk • contribs) 14:16, 13 November 2009 (UTC)
replies: text: John Donovan spent the summer of 1967 at Project MAC.  He was an assistant professor in the MIT EE department.  He shared an office with Bob Fenichel. (I was an MIT DSR Staff member at Project MAC, working on Multics, at the time.)  Professor Donovan was a member of the Multics development team, and wrote two brief sections of the Multics System Programmer's Manual, about parts of the design for creating user processes.  He was not a major contributor: his inclusion in the list with the likes of Corbato, Saltzer, Licklider, and others listed is incongruous. Thvv (talk) 23:50, 11 February 2010 (UTC)
thread_title:  Staffing Question 

message: The article states "The single-level store and dynamic linking are still not available to their full power in other widely used operating systems". This seems in error in consideration of the OS/400 (IBM i) architecture. Perhaps I don't understand the meaning behind 'to their full power'. The OS/400 system kernel (System License Internal Code) implements both single level store at the Machine Interface level and provides dynamic linking to all high level languages on the system.
Dynamic linkage: OS/400 provides both dynamic data and program linkage as described in http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzasb/sc092539244.htm (COBOL specific instance) and http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzase/sc092540313.htm (another COBOL specific instance). Dynamic program linkage is also discussed in the ILE Concepts manual.
Single-level store: http://en.wikipedia.org/wiki/Single-level_store and the Single-Level Storage section in http://www-03.ibm.com/servers/enable/site/porting/iseries/overview/overview.html
I think that 'With rare exception,' should be added to the sentence to make it technically correct.
Mike Amos (yl_mra)  —Preceding unsigned comment added by Yl mra (talk • contribs) 19:04, 30 December 2009 (UTC)
replies: text: Well, I could defend the article by pointing out that it does say "other widely used [OS's]"! :-) (BTW, is OS/400 a descendant of the earlier System/38? I'm not familiar with it.) But if someone wants to add some (more) weasel words to the article, I won't object. Noel (talk) 15:15, 7 August 2014 (UTC)
thread_title:  Accuracy Question 

message: I'm at the edge of my knowledge depth here which is why I'm not editing the article. But I'd like to see the Multics/UNIX lineage clarified (or debunked if needs be).
I've encountered sources (eg. this and this) that portray UNIX as a direct descendant of Multics. (The RS status of these is far from certain however).
So as there is a public perception of *some* ancestral relationship to UNIX then I think this article would benefit from directly (and reliably) clarifying that, even if only to dismiss/diminish the relationship. 61.68.31.209 (talk) 02:14, 19 February 2010 (UTC)
replies: text: See my comment above at #Errors. Noel (talk) 22:01, 18 July 2014 (UTC)
thread_title:  Ancestor of UNIX status 

message: So the article still says that Multics was the first system to have "per-process stacks in the kernel", but I think this may be incorrect. I recently asked Jerry Saltzer (as part of an investigation into the ideas from Multics that showed up in Unix) about where that idea came from, since the first place I'd seen it was in his PhD thesis. His reply mentioned the Burroughs (B5000, I think; I think that was the only one of that line that existed when Multics was first done). Does anyone know of a citation? And we should probably tweak this article to say 'one of the first'; although I would wager that in this, like so many things, Multics made it well known. (Other systems at the time do not seem to have used this approach; CTSS I think kept the process' state more directly, and ITS definitely took the approach of having all system calls run to completion, or backing the process up to just before the system call.) Noel (talk) 17:50, 14 March 2016 (UTC)
thread_title:  Kernel stacks 

message: I disagree with the rewrite, althouh I agree the paragrapg could use a rewrite. Single-level store is still available in, e.g. IBM system i. I'm not sure the dynamic linking technique differs, The thing lacking today is the ability to link to an arbitrary executable (segment) instead of a special dso or dll. I could try to rewrite it to incorporate these details plus your objections, but I won't be able to get to it for a week or so. Peter Flass (talk) 12:29, 16 December 2016 (UTC)
replies: text: I agree with you on both. It needs to present a balanced critique. Peter Flass (talk) 23:26, 17 December 2016 (UTC)
replies: text: Perhaps this is worth mentioning: PMem (Persistent Memory) is slowly but steadily making its way into storage systems / virtualization technologies. Something that's conceptually similar to single-level store. I've recently worked on a storage system that utilizes the hardware as its primary data store (I don't want to disclose not to make this into an advertisement). The benefits of such approach: no need / reason for fsync() or similar mechanisms for filesystem cache invalidation in the user code. I'd definitely expect to see more storage designed to have single level as a consequence. This is definitely not an obsolete idea.87.233.215.97 (talk) 12:45, 23 June 2022 (UTC)
thread_title:  "obsolete concepts" 

message: Someone deleted the phrase "early and influential" from the lede, on the grounds that it was PoV. This is not a correct statement; those adjectives are factual.
First, the date: design of Multics started in 1964 (which was when GE was selected as the hardware supplier); considering the first time-sharing OS, CTSS, only went online in 1962, if within 2 years is not "early", what is?
As to "influential", here's a quote from the first CACM Unix paper (written by people who had worked on Multics), from the "Influences" section: On a number of points we were influenced by Multics. And from the paper "Origins and Development of TOPS-20", (on how TOPS-20, on which a generation of CS students learned, was a development of TENEX): Three system most directly affected the design of TENEX ... MULTICS was the newest and most "state of the art" system of that time ... Several members of the MIT faculty and staff who had worked on MULTICS provided valuable review and comment on the emerging TENEX design. Etc, etc.
Yes, it's true that most OS's have not taken all the ideas of Multics - which is not surprising, Multics had so many. But some of them (e.g. the hierarchical file system, a user-mode command processor), pretty much every OS since has copied. Dynamic linking is now becoming common. Etc, etc.
Noel (talk) 15:38, 26 November 2017 (UTC)
thread_title: Early and influential

message: Welcome to the world of WP:CHEESE. For those of you who don't have access to TR-123, here's what it says: 
Of the ideas reported here, the following seem to be both novel and previously unreported:
* The notion of designing a comprehensive computer utility with information protection as a fundamental objective.
Seems to cover the point. Noel (talk) 03:18, 2 December 2017 (UTC)
thread_title:  Security citation 

message: Well, a bit odd, critics of Multics get mentioned by name, but not too many who actually worked on it get credited.
A bit like talking about movie reviewers, but not the movie director or stars. Feldercarb (talk) 21:13, 6 July 2018 (UTC)
replies: text: Do you have a reliable source with names of key people on the project?--agr (talk) 21:28, 6 July 2018 (UTC)
replies: text: The various technical papers about Multics were usually written by the actual designers and implementers of the project.  Reify-tech (talk) 19:35, 19 May 2019 (UTC)
thread_title:  It's too bad 

message: I mostly agree with the claims of influence on other OSs, except Windows NT and its successors. The Windows NT line is the direct descendant of VAX/VMS, which in turn descended directly from RSX-11M and its predecessors, which were originally focused on real-time measurement and control, rather than timesharing. I have used all of these OSs, as well as Multics.
Can anybody provide a WP:RS with credible claims of direct influence? Of course, there were OSs which introduced new concepts that were adopted elsewhere, but overstretching these connections renders them meaningless.  Reify-tech (talk) 19:35, 19 May 2019 (UTC)
thread_title:  Influence? 

message: user:Timm123 changed this link from Hierarchical file system, which is an Apple-specific thing to Directory (computing), which misses the concept completely. File system mentions this in its section on directories, but there’s really no good discussion of this concept. Maybe this shouldn’t be a link here? Peter Flass (talk) 01:42, 29 March 2020 (UTC)
replies: text: You've subsequently fixed that by making hierarchical file system a page about the concept, with Hierarchical File System (Apple) being the page about Apple's HFS. I've updated at least one link here to go to hierarchical file system. Guy Harris (talk) 00:38, 25 February 2023 (UTC)
thread_title:  hierarchical file system 

message: I have on my bookcase a document titled "Massachusetts Institute of Technology Project MAC The Multiplexed Information and 
Computing Service: Programmer's Manual", and 1965 FJCC papers
 use the same name. How is that not an acronym? Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:06, 12 August 2020 (UTC)
thread_title:  Multics versus MULTICS redux 

message: The Technical Details section has links to several conference papers without identifying the sources of the papers. AFIPS sponsored at least two conferences in 1965: a Spring Joint Computer Conference (SJCC) and a Fall Joint Computer Conference (FJCC). The basic Multics papers were at the 1965 FJCC and were printed in Volume 27 Part 1. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:19, 12 August 2020 (UTC)
thread_title:  Sources for Technical details 

message: I have readded the vector version of the logo. Vectorization is good for Wikipedia. --Comrade-yutyo (talk) 18:06, 6 April 2022 (UTC)
thread_title:  Vector logo 

message: Under Retrospective observations there's the following:
During its commercial product history, it was often commented internally that the Honeywell Information Systems (HIS) (later Honeywell-Bull) sales and marketing staff were more familiar with and comfortable making the business case for Honeywell’s other computer line, the DPS 6 running GCOS. The DPS-6 and GCOS was a well-regarded and reliable platform for inventory, accounting, word processing, and vertical market applications, such as banking, where it had a sizeable customer base. In contrast, the full potential of Multics’ flexibility for even mundane tasks was not easy to comprehend in that era and its features were generally outside the skill set of contemporary business analysts.
This seems to be mistaken as the competition was with GCOS-8 running on basically the same hardware as Multics (Level 66 / DPS8 -- 36bit mainframe), it was only in late 80's that a 32bit version of DPS 6 hardware was released and one of the proposals made by HIS sales was to create a new operating system called "OPUS"/VS3 (containing all nice featuers of Multics) as a sop to the userbase. This would run on DPS6-Plus (32bit) hardware and was canned in '87
Dóeltenga (talk) 16:25, 16 September 2023 (UTC)
thread_title:  DPS-6/GCOS-6 vs. DPS-8/GCOS-8