Talk:Multics

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)

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

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 05:09, 8 August 2001 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

I agree with you on both. It needs to present a balanced critique. Peter Flass (talk) 23:26, 17 December 2016 (UTC)

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)

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)

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)

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)

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)

Do you have a reliable source with names of key people on the project?--agr (talk) 21:28, 6 July 2018 (UTC)

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)

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)

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)

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)