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.


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"


  "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>