On Fri, Apr 8, 2022 at 1:33 AM Lars Brinkhoff &lt;lars(a)nocrew.org&gt; wrote: Not to put too fine a point on it, It seems like it would be fair to say Multics was 'complete' by the time Organick published his book: *"**The Multics System: An Examination of Its Structure**.*" Amazon says the 3rd printing was April 72, so that means he must have published it earlier. I don't know when it first appeared and can not seem to find it. My copy is in storage but I bet I have the 3rd printing. But I had >>thought<< that was still in the late 1960s. Anyone have a first edition around with the publication date? ᐧ ᐧ

On Fri, Apr 8, 2022 at 1:30 AM Lars Brinkhoff &lt;lars(a)nocrew.org&gt; wrote: In context, I don't think Corby's statement was meant to be taken literally, but rather he used it as more of a colloquialism. His point was that (at least in his perception) the bulk of the work had been done when BTL dropped out of the project. Fano's statements are a bit overshadowed by Corby's here, but when he talked about each of the three participants in the Multics project at its outset working on one project but with different goals, he stated that his impression was that Bell Labs was interested in both the research products as well as a production system that they actually could use. In particular, they expected that the latter would be delivered on a specific timetable: when the research part basically wrapped and the system still wasn't production ready, they dropped out. MIT started offering timesharing access on Multics in 1969. A second site at Griffiss Air Force Base in Rome, NY was operational by 1970. Honeywell announced the 6180 running Multics as a product in 1973; throughout the 70s things were tuned, cleaned up, and new subsystems introduced. The "New Storage System", which started in 1973 and was delivered to customers in 1976. I think it's fair to say that, by the mid-70s, Multics had fully transitioned from "research project" to "commercial system." Bell Labs dropping out of Multics in 1969 was, of course, before Unix. This raises the question, what did Bell Labs use instead? I imagine 360s and either traditional batch processing or TSS or something? Of course, by 1976, Unix was at 6th Edition and I can see why no one would want to go back to Multics (or being tied to a machine costing an order of magnitude more than a PDP-11). But one wonders what would have happened had Multics started accepting timesharing, say, 9 months earlier than it did. It would be interesting to hear what it was like when Bell Labs withdrew from the Multics project. Does anyone have any stories? Perhaps Ken or Doug? Also, what was the relationship like with the MIT people after that? Corby et al seemed somewhat animated in insisting that Multics had been essential to the creation of Unix, almost as if that had not been sufficiently acknowledged; I imagine by the time this video was shot, they must have been feeling somewhat overshadowed by the success of Unix. - Dan C.

On Fri, Apr 8, 2022 at 11:28 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: I'm running Multics under emulation at home and I think it's actually pretty cool. I imagine that both Doug and Ken would remember it pretty well? - Dan C.

At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. I used Multics for a couple of my undergrad years at University of Calgary (along with a PDP-11/60 and then a PDP-11/44 and a VAX 11/780, with the DEC equipment running Unix of course: V7 on the 11s, and 32V then 3BSD and finally 4BSD on the VAX). I never really appreciated Multics as much then (except for its LISP and Emacs implementations), but have grown far more fond of it now that it is effectively gone. I think it would be most excellent, assuming it had kept up to modern needs, used modern languages (there was already a C compiler for it) and if modern hardware had continued to support it into the 64-bit era. The famous "everything is a file" description of Unix is wrong, or at least misleadingly incomplete -- the correct description is more like: "everything is a file _descriptor_"; whereas in Multics everything is actually just a memory array (except for some communications devices). Single Level Storage is an awesome concept and removes so many ugly hacks from algorithms that otherwise have to process data in files. Doing data processing with read and write and pipes is effectively working through a straw whereas SLS allows all (reasonably sized) data to be presented in entirely complete randomly accessible arrays just by attaching a "file" to a segment. Mmap() is a very poor replacement that requires a great deal extra bookkeeping that's next to impossible to hide from; and also there's the problem of the consistency semantics being different between the I/O based filesystems and direct memory mapping of their files, which Mmap() reveals, and which SLS eliminates (by simply not having any I/O mechanism for files in the first place!). Multics dynamic linking makes any unix-ish implementation look most ugly, incredibly insecure, and horribly inefficient. Unix shared libraries are bad hack to simulate what Multics did natively and naturally, with elegance, and with direct hardware security support. Both of these features of course strongly desire (for decent performance) either something like the original hardware-based segmented addressing scheme (e.g. as offered in Intel IA-32 and also tried to offer in the iAPX432), or hardware similar to what capability-based addressing schemes found in some research systems today [1]. Intel was never pressured strongly enough into improving the performance of segmented addressing and memory management in the IA-32 (because nothing (but OS/2?) really used it heavily the way a multics-like OS would have, and of course the iAPX432 also failed to deliver good performance), then AMD never carried full segmentation support forward into their 64-bit architecture and instruction set where it would have made larger scale multics-like systems more practical. [1] The experimental CHERI architecture is an example: CHERI: Memory Segmentation to Support Secure Applications "A segment mechanism that implements the capability model of safe, programmatic memory protection" http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2013essos-cheri.pdf "CHERI can do anything Multics could do: segmentation, paging, dynamic linking, ring-structured software" -- Peter G. Neumann in "An Interview with..." by Rick Farrow in ;login:, Winter 2017 vol. 42, no. 4 -- Greg A. Woods &lt;gwoods(a)acm.org&gt; Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt;

At Fri, 8 Apr 2022 17:34:27 -0600, Andrew Warkentin &lt;andreww591(a)gmail.com&gt; wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. I/O is good for I/O of course (e.g. to devices, like terminals and printers and such), and if you can "attach" that I/O to a segment, or to another program's I/O, all the better: https://multicians.org/myths.html#nofile (One big complication forced by hardware limitations of the day was rather limited file (i.e. segment) size, and thus Multics developers invented multi-segment files, and as mentioned in that link, stream access to them was often through the I/O mechanism, but of course this was a simulation done by copying (I think) data from a mapped segment of the file to a buffer in a heap segment.) -- Greg A. Woods &lt;gwoods(a)acm.org&gt; Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt;

On Fri, Apr 08, 2022 at 02:02:23PM -0700, Greg A. Woods wrote: To be fair, Multics had it a lot easier, because core memory meant that every single memory access could be considered "durable storage", so there was no real need for "fsync(2)" or "msync(2)". So I/O consistency could be done much like writing to persistent memory, except that there would be no need for "CLFLUSH" (Who needs multi-level memory caches when the clock cycle is pathetically slow?) and no need to worry about write endurance exhaustion with core memory, either. So how much of the consistency benefits are due to the hardware, and how much is due to the OS? We could just as easily claim that Multics is superior to Unix because it's immune to Spectre and Meltdown attacks --- except that Unix on a PDP-11 would be immune to cache based attacks as well. Of course, Unix on a PDP-11 is a lot slower than NetBSD on an modern x86_64 machines.... What if we compared Multics dynamic linking to Solaris Doors? - Ted

At Sat, 9 Apr 2022 08:10:21 -0400, tytso &lt;tytso(a)mit.edu&gt; wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. As Dan mentioned, actual "core" memory was long gone by the time Multics was in commercial use. Core memory was only used in the first-generation 6000 series (and presumably the GE-635 too), i.e. before 1975. One source says there was cache memory in the CPUs as early as 1974. The later machines, such as the DPS-8/70M ("M" for Multics) definitely came with 8KW cache memory that could be expanded up to 32KW. These systems were also generally used in multi-processing configurations, especially for Multics, with multiple CPUs, each with potentially multiple memory units (and multiple IOMm (I/O Multiplexer), later IMUs (Information Multiplexer Unit)). As for how this cache memory was used and how its consistency with main memory and with secondary storage was maintained, I don't know myself, but of course much documentation about Multics internals is available, along with all the source code, and it is running on simulators today. I don't think Doors is really relatable to Multics dynamic linking. As I understand it, Doors is more like RPC than directly shared code. In Multics all code, even kernel code, is generally shared -- in broad terms user processes just "gate" (i.e. jump) directly to code in a lower/inner "ring" to run system calls (e.g. Ring-0). Code doesn't even have to exist when first called (similar to how methods don't have to pre-exist in Smalltalk) -- the user gets a "linkage fault" and can write and compile the missing code and continue a program at the fault point. Also there's no such thing as "relocation" of code in Multics -- segmented memory means all segments have their own zero address and so all code is pure procedure and can be executed by many processes simultaneously simply by mapping the shared code segments into each process (as read-only, executable). Shared libraries of a sort (bound segments) do exist, partly because of performance issues (dynamic link faults are expensive in Multics, especially on hardware of the day), and partly because of addressing limitations (only a quite limited number of segments can be attached to any given process), and partly because otherwise there would be effectively one global namespace for all symbols exposed by each compilation unit in a user's $PATH. One of the difficult things for Unix people to wrap their heads around is the difference between a "process" in Unix and in Multics. One way to think about it that has helped me figure it out is this: In Multics you have a "shell" program which you interact with just like with "sh" in Unix, but it's not a separate process in Multics -- just a unit of code that effectively runs when no other program is running. So generally a user only runs one process at a time, even though it may transition through hundreds or thousands of programs during its existence. Multics did eventually have the concept of multi-threading and a form of co-operative multi-tasking too, though I don't know as much about these. I think the latter would/could effectively be like having multiple processes in one login session in Unix and it is said this facility was used to implement network service daemons for example. Now I don't believe the Multics concept of "process" is strictly necessary to support its concepts of Single Level Storage or even Dynamic Linking. I believe those could be used equally well in a system with more Unix-like processes, though some mix of concepts might be required to truly benefit from all the features of Multics-style dynamic linking. One way I've been thinking of Multics lately is that it's more like modern virtualization (e.g. Xen), but with added OS services such as a filesystem and controlled access to shared "inner ring" code; and indeed that's more or less how it was described in early Multics concept papers, assuming you transmogrify the old terminology of the day into modern lingo. Each user gets a computing environment that gives them the impression they have full use of the machine, and it comes along with pre-existing useful code and various useful services, including a filesystem the ability to communicate with other users and other machines. -- Greg A. Woods &lt;gwoods(a)acm.org&gt; Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt;