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 9:34 AM Clem Cole &lt;clemc(a)ccc.com&gt; wrote: I have a scanned copy of Organick from MIT that says Copyright 1972 (and has a stamp from the Barker Engineering Library listing May 16, 1972 as the acquisition date). I can't see any indication that this is anything other than the first printing. Corbato's forward is dated Dec 13, 1971. However, Organick's book is often said to describe an earlier version of the system, up to somewhere in the vicinity of 1968/1970 ( https://multicians.org/history.html, also message to the old Multicians list at Yahoo! I'm not sure about the archives of that, so don't have a link). I understand that Multics got much better after the move to the 6180 and DPS8/M; Organick's book describes GE 645 Multics only. - 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.

On a related note, I'd love to hear from some folks who have used both Multics and Unix(ish) systems about things that differ and how they affect the user experience. -r

On 4/8/22, Greg A. Woods &lt;woods(a)robohack.ca&gt; wrote: I think it's useful to have both I/O and memory views for files. Things like commands that work equally well whether stdout is a disk file or something like a pipe wouldn't work so well in a system where disk files can only be accessed through a memory-like interface. However, I guess the I/O interface could just be implemented with library functions rather than real I/O syscalls for disk-like files. Maybe I could try doing something like that in my OS but I'm not completely sure if it would affect performance because it will be QNX-like, and reads and writes would probably require the VFS to act as an intermediary sometimes whereas that wouldn't be the case with I/O since reads and writes would otherwise map onto kernel message passing without any intermediary servers.

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;