Re: [TUHS] Interesting commentary on Unix from Multicians.

[Adam Thornton <athornton@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4635 bytes --]

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 <woods@robohack.ca> wrote:

> At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy <lm@mcvoy.com> 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 <gwoods@acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>
>

[-- Attachment #2: Type: text/html, Size: 5829 bytes --]