The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Greg A. Woods" <woods@robohack.ca>
To: The Unix Heritage Society mailing list <tuhs@tuhs.org>
Subject: Re: [TUHS] Interesting commentary on Unix from Multicians.
Date: Fri, 08 Apr 2022 14:02:23 -0700	[thread overview]
Message-ID: <m1ncvkN-000iJNC@more.local> (raw)
In-Reply-To: <20220408152834.GE29186@mcvoy.com>

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

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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  parent reply	other threads:[~2022-04-08 21:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07 16:32 Dan Cross
2022-04-08  5:30 ` Lars Brinkhoff
2022-04-08 13:34   ` Clem Cole
2022-04-08 14:14     ` Dan Cross
2022-04-08 13:59   ` Dan Cross
2022-04-08 15:28     ` Larry McVoy
2022-04-08 15:35       ` Dan Cross
2022-04-08 19:36       ` Rich Morin
2022-04-08 21:02       ` Greg A. Woods [this message]
2022-04-08 23:34         ` Andrew Warkentin
2022-04-09 19:28           ` Greg A. Woods
2022-04-09  3:33         ` Adam Thornton
2022-04-09 12:10         ` tytso
2022-04-09 13:09           ` Dan Cross
2022-04-09 19:14           ` Greg A. Woods
2022-04-08 15:45     ` Jon Steinhart
2022-04-08 16:07 Noel Chiappa
2022-04-10 17:14 Noel Chiappa
2022-04-10 17:31 ` Larry McVoy
2022-04-10 20:41 ` John Cowan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1ncvkN-000iJNC@more.local \
    --to=woods@robohack.ca \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).