If anyone wants a login on a basically-stock Multics 12.7 system, let me know in private. It's running on a Raspberry Pi, and I've really never done anything with it other than a minimal amount of poking around. It's exposed to the 'net through https://mvsevm.fsf.net. If there are other systems there anyone wants access to, lmk. Adam On Fri, Apr 8, 2022 at 2:12 PM Greg A. Woods wrote: > At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy wrote: > Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. > > > > Do we have any people around who actively used Multics long enough to > > develop a feel for it? My only experience is the printout that Rob > > Gingell had on his office door which was a description of Multics > > paging in library after library before it actually ran the program. > > I have no idea if it was that bad. > > 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 guess what I'm trying to ask is if Multics had modern hardware > > under it, performed well, would we want to be running it? > > 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 > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms >