Google Oops[edit]

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)Reply[reply]

This seems to have been corrected. Riordanmr (talk) 22:53, 23 May 2020 (UTC)Reply[reply]

Aside[edit]

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

More content[edit]

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)

Web archives[edit]

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)

TSO, MTS, etc[edit]

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)

Not sure if it is related to the discussion above but I think "influenced virtually all modern operating systems" is inaccurate and too broad. IBM System 360 and OS/360 were announced in 1964. Clearly, Multics could not have had any influence on that. OS/360 and successors are the oldest operating systems still in active use. They are still being developed and sold today. Indeed it is those, and not Multics, which have had the greatest influence over the years.

TSO is not an OS and not even a shell. It is a batch job that provides some timesharing services.185.186.250.14 (talk) 05:01, 13 January 2020 (UTC)Reply[reply]

Technical issue[edit]

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)Reply[reply]

Errors[edit]

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)Reply[reply]

Size comparison[edit]

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:

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)Reply[reply]

Removed text[edit]

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:

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)Reply[reply]

MULTICS vs Multics[edit]

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)Reply[reply]

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)Reply[reply]

MIT Source Archive[edit]

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)Reply[reply]

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)Reply[reply]

myths[edit]

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

Open Source[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

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

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)Reply[reply]

I think this is the "Fords only come in black" pattern. Take something that was true once but changed, and ignore the changes.
Multics performance improved over the years, but these remarks are based on opinions formed before the system was released. You don't say when you were at Bell Labs: is it possible that this was in the 1980s, years after BTL withdrew from the project, and that you are recounting second or third hand remarks?
The invocation of Richard Stallman is a clue to understanding Don's remarks. Stallman had nothing to do with Multics. He was at the MIT AI Lab, ten years after BTL withdrew from Multics. The AI Lab had a totally different operating system, ITS, and a different development process. I have great respect for Rob Pike and enjoy his witty remarks, but he was not part of the BTL Multics team. If he visited MIT, this would have been in the late 70s or 80s, when MIT was no longer contributing to Multics; perhaps he visited the AI group.
People who weren't there tend to treat whole organizations as unified, e.g. "MIT," "Bell Labs." Often there are divisions of opinion and style within. The AI Lab versus Multics group divide is alluded to by Steven Levy's Hackers. Similarly, the folks at Bell Labs who disagreed with the "MIT" culture and philosophy are probably not the same as the ones who contributed to some of the more grandiose Multics designs.
Fact: in 1969, Multics was first used as a service at MIT, and supported 50 users (slowly) on a 2 CPU system.
It is difficult to compare the "efficiency" of systems that do different things. Multics was probably the most efficient timesharing system that provided the user a multi-megabyte virtual memory in 1969 :-)
Thvv (talk) 14:38, 1 October 2008 (UTC)Reply[reply]

Staffing Question[edit]

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)Reply[reply]

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)Reply[reply]

Accuracy Question[edit]

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)Reply[reply]

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)Reply[reply]

Ancestor of UNIX status[edit]

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)Reply[reply]

See my comment above at #Errors. Noel (talk) 22:01, 18 July 2014 (UTC)Reply[reply]

Multics failed?[edit]

The next paragraph is part of a comment I placed on the Unix talk page.

Multics didn't have `many problems', or at least many more than other systems of the time. (IBM's TSS/360, in 1967, turned out to be too slow for supporting more than one user concurrently, and of course OS/360 was plagued with bugs and performance problems). There is a common myth that Multics `failed', but in fact the system was first described in 1965, released in the early 1970s, and lasted until 2000 (see the Multics article, which also quotes Peter Salus as saying that it `failed miserably'). However, the lifespan, in particular the 13 years after development ceased in which installations continued to use it, doesn't suggest failure. It's certainly true that AT&T management decided that the project wasn't relevant to them, and that's sufficient for Unix history.

I'd like to see the Salus quote either removed, or placed in context. In my opinion, the quote is out of place where it is, in any case. The last section, `Retrospective observations', might benefit from having something like this added to it:

`Multics clearly gained a group of loyal adherents, sufficient to keep the system in production use for 30 years. It popularized a number of operating system design techniques, including tree-structured file systems, memory-mapped files, and even writing the kernel in a higher-level language, rather than assembly language. Yet the system was not a major commercial success, and it is clear that Multics's original developers underestimated the resources needed to build a system of this size.'

Vmanis (talk) 21:17, 22 February 2010 (UTC)Reply[reply]

I'm not sure about that last clause - and in any case, to the extent it was true, I don't think that was a major cause of Multics' failure to be a big success. After all, it may have taken longer than they predicted to build it, and get it running reasonably efficiently - but as you point out, they did reach the point of having it 'done' decades before it went out of use.
I suspect that Honeywell's failure to properly support the product (in terms of devoting resources to development of new generations of hardware), etc were a large part of its failure. (E.g. I seem to recall hearing from someone that Honeywell's memory was at a very poor cost competitiveness to competing systems - and with so few Multics sites, there wasn't a lot of incentive for third-party suppliers to provide cheaper alternatives.) Noel (talk) 21:59, 18 July 2014 (UTC)Reply[reply]

Kernel stacks[edit]

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)Reply[reply]

I think I may have bee wrong about ITS; it was prepared to abandon the processor while on the stack. Another process could force the first one to exit the OS, though, through the PCLSR mechanism. Noel (talk) 15:12, 26 November 2017 (UTC)Reply[reply]

"obsolete concepts"[edit]

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)Reply[reply]

My problem fundamentally is that it read to me like an endorsement of the MULTICS features and a statement that the computing world would be better off if operating systems had gone this direction. This seemed strange to me. Apparently, according to another friend, I've now biased it in the wrong direction... 96.239.57.6 (talk) 03:15, 17 December 2016 (UTC)Reply[reply]

I agree with you on both. It needs to present a balanced critique. Peter Flass (talk) 23:26, 17 December 2016 (UTC)Reply[reply]
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)Reply[reply]

Early and influential[edit]

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)Reply[reply]

And another one about Unix: Like much else in Unix, it was inspired by an idea from Multics., from "The Evolution of the Unix Timesharing System", by Dennis Richie, pg 6. When I get a roud tuit, I'll add that as a citation in the article. Noel (talk) 16:05, 28 November 2017 (UTC)Reply[reply]

Security citation[edit]

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:

Seems to cover the point. Noel (talk) 03:18, 2 December 2017 (UTC)Reply[reply]

It's too bad[edit]

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)Reply[reply]

Do you have a reliable source with names of key people on the project?--agr (talk) 21:28, 6 July 2018 (UTC)Reply[reply]
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)Reply[reply]

Influence?[edit]

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)Reply[reply]

hierarchical file system[edit]

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)Reply[reply]

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)Reply[reply]

Multics versus MULTICS redux[edit]

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[1] use the same name. How is that not an acronym? Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:06, 12 August 2020 (UTC)Reply[reply]

References

  1. ^ F. J. Corbato; V. A. Vyssotsky. "INTRODUCTION AND OVERVIEW OF THE MULTICS SYSTEM". AFIPS CONFERENCE PROCEEDINGS VOLUME 27 PART 1 1965 FALL JOINT COMPUTER CONFERENCE. Fall Joint Computer Conference. Vol. 27 Part 1. Spartan Books. p. 185. ISBN 978-1-4503-7885-7. Multics (Multiplexed Information and Computing Service)

Sources for Technical details[edit]

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)Reply[reply]

Active functions[edit]

Shouldn't Multics#New features mention active functions? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:50, 13 September 2020 (UTC)Reply[reply]

I put a very quick mention of active functions in Multics § Active functions, which is a subsection of Multics § Commands, as the command list really needed some structuring, including putting the active functions in a section, and that, in turn, required explaining what an active function is. (Perhaps, for the benefit of UN*X folks, it should be mentioned as a predecessor to enclosing commands in backquotes or $(/).)
But that could be moved up to Multics § Novel ideas - and if the Multics shell is one of the first shells in which commands are just programs, rather than things built into the shell, with no need for a run command to run a program, that should perhaps go there as well. The shell is mentioned in the next-to-last paragraph of Multics § Novel ideas; with all that stuff, perhaps it deserves a paragraph of its own. Guy Harris (talk) 06:28, 28 January 2024 (UTC)Reply[reply]
That probably should go under Scripts. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:09, 29 January 2024 (UTC)Reply[reply]

Restructure references?[edit]

The article has several references to papers that are collected in a single volume,, e.g., the 1965 FJCC[1] papers collectively known as the "MULTICS papers". I propose adding or repurposeing a section to include those collections with, e.g., use ((cite conference))[2] to define a volume and use, e.g, ((sfn|FJCC|1965|loc=[URL#page=page OVERVIEW OF THE MULTICS SYSTEM]|p=185)),[3] to refer to it.

References

  1. ^ AFIPS CONFERENCE PROCEEDINGS VOLUME 27 PART 1 1965 FALL JOINT COMPUTER CONFERENCE. 1965 Fall Joint Computer Conference. Vol. 27 Part 1. Spartan Books. ISBN 978-1-4503-7885-7.
  2. ^ Include section header and other volumes here.
    FJCC 1965
    AFIPS CONFERENCE PROCEEDINGS VOLUME 27 PART 1 1965 FALL JOINT COMPUTER CONFERENCE. 1965 Fall Joint Computer Conference. Vol. 27 Part 1. Spartan Books. ISBN 978-1-4503-7885-7.
    SJCC 1972
    AFIPS CONFERENCE PROCEEDINGS VOLUME 40 1972 Spring JOINT COMPUTER CONFERENCE. 1972 Spring Joint Computer Conference. Vol. 40. AFIPS Press.
  3. ^ FJCC 1965, p. 185, OVERVIEW OF THE MULTICS SYSTEM.

[edit]

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

nowiki[edit]

@Chatul: This edit adds a nowiki tag with the comment "nowiki to prevent coloring of semicolon after link". I don't see any coloring of the semicolon with or without nowiki. I've tested on Chrome/MacOS and Chrome/Windows using Vector legacy skin + custom CSS. --Macrakis (talk) 16:02, 11 August 2022 (UTC)Reply[reply]

The semicolon appeared to be blue on Firefox 45 (yes, I know it's ancient), but I can't sear that it wasn't just my eyes. What's in the generated HTML without the <nowiki />? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:38, 11 August 2022 (UTC)Reply[reply]
The HTML looks fine without the nowiki:
special <a href="/wiki/Dynamic-link_library" title="Dynamic-link library">Dynamic-link libraries (DLL)s</a>; a program
I will remove the nowiki. Even if there is a bug in some version of Firefox, we shouldn't be putting hacks in the source. --Macrakis (talk) 20:42, 12 August 2022 (UTC)Reply[reply]

automatically[edit]

@Macrakis: I think the last “automatically” you removed is important to differentiate how Multics works from systems using e.g.overlays or programmed loading of segments via. OS/360 LINK macro, etc. “Automatically” here means “without special programming.” Peter Flass (talk) 00:55, 24 October 2022 (UTC)Reply[reply]

@Peter Flass: "Automatically" or for that matter "without special programming" is an awfully vague way of characterizing the difference between Multics segments and other systems. I've reworded. See what you think. The rest of the paragraph needs work. The paragraph starts by saying that you always link to the most recent version, then says that the version depends on the search rules.... --Macrakis (talk) 14:53, 24 October 2022 (UTC)Reply[reply]
@Macrakis:Definitely better. I was also thinking that “automatically” is not what we want there. You’re right about the paragraph needing work. As an aside, I like the story about a program getting an error due to a missing segment where the programmer quickly coded and compiled it, and then returned to the program which picked right up where it left off. Peter Flass (talk) 19:11, 24 October 2022 (UTC)Reply[reply]
@Macrakis and Peter Flass: The revised wording in your edits does not convey that the dynamic linking is automatic and seems to imply that the programmer needs code to load the segments into his virtual memory prior to calling it, which is not the case. How about

Another major new idea of Multics was dynamic linking, in which a call by a running process to a subroutine not in its address space adds the code and linkage segments to its address space without explicit code and allows sharing of the code segment with other processes.

as a replacement? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:27, 24 October 2022 (UTC)Reply[reply]
@Chatul and Peter Flass: I don't think that referring to concepts which are never defined (code and linkage segments) is helpful here.
Alas, I don't know Multics enough to improve on it though. How exactly are the external subroutines referred to? -- apparently by name, not by segment number? And what is the "automatic" process that converts a name reference to a segment/offset reference?
Also, I think that the sharing of the code segment is orthogonal to dynamic linking -- any read-only segment is shared, right?
It would be useful, too, to clarify the rest of the paragraph, which is confusing about versions. --Macrakis (talk) 13:50, 25 October 2022 (UTC)Reply[reply]
I’m not an authority on dynamic linking in general, but In OS/2, which I know best, a program has to be linked with a definition file that identifies the subroutines to be called and the library (DLL) they are in. Then the routine will be dynamically loaded when called. I believe Windows works this way. In Multics, I believe, the calling program doesn’t have to be told anything about the called program in advance (there is usually no link step). Everything is handled by the OS. I may well have this all garbled.Peter Flass (talk) 14:02, 25 October 2022 (UTC)Reply[reply]
Let's have a Multics expert clarify this. --Macrakis (talk) 16:35, 25 October 2022 (UTC)Reply[reply]
In Multics there is no place for a DLL. The programmer uses the same CALL statement whether the subroutine is bound with the caller or is in a separate segment. Conceptually[a] every subroutine has a shared read-only code segment and a private writable linkage segment. The linkage segment includes the names of all subroutines called by its owning procedure. The generate code for a CALL uses an indirect word in the linkage segment to reference the subroutine. If the subroutine is not in the processes address space, the indirect word will have a tag that causes a fault when it is used; the dynamic linker places the newly assigned segment number into the indirect word and changes the tag.
Does the text at Position-independent code##Multics belong here?
Text about dynamic linking added to this article should probably also go into Dynamic linker#Multics as well. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:06, 25 October 2022 (UTC) -- revised 12:57, 26 October 2022 (UTC)Reply[reply]
I assume there's also a way to call an arbitrary routine not pre-defined by a standard PL/I CALL, probably a system call (otherwise something like the shell couldn't work). I keep meaning to look this up. Peter Flass (talk) 20:42, 25 October 2022 (UTC)Reply[reply]
@Macrakis and Peter Flass: A program can explicitly invoke the dynamic linker. How about

Another major new idea of Multics was dynamic linking, in which a call by a running process to a subroutine not in its address space adds the code and linkage segments[b] to its address space without explicit code and allows sharing of the code segment with other processes. A program can also explicitly call the dynamic linker when the segment name is variable.

Should there also be a link to Position-independent code##Multics? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:57, 26 October 2022 (UTC)Reply[reply]

Notes

  1. ^ In practice multiple linkage segment may be packed into a single segment, with distinct offsets.
  2. ^ the dynamic loader initializes the new linkage segment from the linkage section of the code segment.

DPS-6/GCOS-6 vs. DPS-8/GCOS-8[edit]

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)Reply[reply]

Categories