From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2720 invoked from network); 9 Apr 2022 03:36:47 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 9 Apr 2022 03:36:47 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2A5B49D706; Sat, 9 Apr 2022 13:36:46 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 989B09D680; Sat, 9 Apr 2022 13:33:24 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="e9gXUCyJ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id DFE879D680; Sat, 9 Apr 2022 13:33:21 +1000 (AEST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by minnie.tuhs.org (Postfix) with ESMTPS id 894DA9D665 for ; Sat, 9 Apr 2022 13:33:18 +1000 (AEST) Received: by mail-pf1-f174.google.com with SMTP id s2so10049000pfh.6 for ; Fri, 08 Apr 2022 20:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5IVikXOAttKZ+T2bNdsna3Ior6hrgy7VPavogj+WvOE=; b=e9gXUCyJLPGVwFlKTRrUe71upirNpXFWQ4EMgbRj2s2jfZhn+TOlL3JyY6bFhbRR3B B5+OVdnFu8ACVnKKRUZtEEw2nzYkJH7MdMoS0HuzzEiZmU8xUzB8yuLQQ352xAeAuRiI FsuoOJRTPh0Pr/gcjOeOSemAmKZhtTIY9HDEgOwgsmR9Fy1tXeK+o0Mnok4vIOqkYmmG Mp6KyJJAOTCzREnOpdh9UKCkY1jd6z9G+060wfbELItGgV6Jx4oYKNX3M/jatf5/nzwx mh9EQ2zPMWRXrbEGni+ZE519LIljumrAn9NRnA0XZxQibmnFZ5HaxtCreW7uX0Ds9nH0 8Q5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5IVikXOAttKZ+T2bNdsna3Ior6hrgy7VPavogj+WvOE=; b=axkxfOKVfWXSFElhjjHf+Q+vJUOeMeVa+w9Sg9W6Y4klcLFstFT3DWM6gVXj4n7aY1 o2D0oG2jW9EKbtFg7TnRZENbpQzyl2xHOLF8WAdBZhjiBnjyUjHTAQXb4aInZPRCfToc obYGg2jVBdrAvLjj2HJim8DFCpKe1A8ayNTz3KLJpxBt5iOAN0fWUH1bRpkJEEqV2YiB OK5bKdn11ZEBSTxjqFxHetDDbIohxHG9U3c8iZX7uvsSRdIxT7hozetLgh6G7ZU4j6lE TFX61iq5iFp+c/P1SYJP2ZTnvwC62dF/VgwHu+1+YOmMRejGA0bHg50LzBM0ElM5EmcE dR+Q== X-Gm-Message-State: AOAM531pPjiP/TMVo9eK0mSVNa4tKHLDQbVIjz+j8fwuIqSaHV6zgIET qbrAro1DlD66imdmy7fZIRQwKax75K9aubAMC1EZ+2YGUeo= X-Google-Smtp-Source: ABdhPJzedDR8Pu3I+oi5E0Ja5um++nSMMF9a12Ca8jNH88KZbFn2Jp04VK3aZ2plOikJpNwOSEfsB8zwQj0ZvOJmzU8= X-Received: by 2002:a63:3f8f:0:b0:386:3116:a1f3 with SMTP id m137-20020a633f8f000000b003863116a1f3mr17939358pga.136.1649475197424; Fri, 08 Apr 2022 20:33:17 -0700 (PDT) MIME-Version: 1.0 References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> In-Reply-To: From: Adam Thornton Date: Fri, 8 Apr 2022 20:33:06 -0700 Message-ID: To: The Unix Heritage Society mailing list Content-Type: multipart/alternative; boundary="0000000000003558b605dc305f3a" Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000003558b605dc305f3a Content-Type: text/plain; charset="UTF-8" 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 > --0000000000003558b605dc305f3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If anyone wants a login on a basically-stock Multics = 12.7 system, let me know in private.=C2=A0 It's running on a Raspberry = Pi, and I've really never done anything with it other than a minimal am= ount of poking around.=C2=A0 It's exposed to the 'net through https://mvsevm.fsf.net.=C2=A0 If there ar= e 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<= br> > develop a feel for it?=C2=A0 My only experience is the printout that R= ob
> 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:=C2=A0 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, o= r at
least misleadingly incomplete -- the correct description is more like:
"everything is a file _descriptor_"; whereas in Multics everythin= g 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.=C2=A0 Mmap() is a very poor repl= acement 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.=C2=A0 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].=C2=A0 Intel wa= s
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:

=C2=A0 CHERI:=C2=A0 Memory Segmentation to Support Secure Applications

=C2=A0 "A segment mechanism that implements the capability model of sa= fe,
=C2=A0 programmatic memory protection"

=C2=A0 http://www.cl.cam.ac.= uk/research/security/ctsrd/pdfs/2013essos-cheri.pdf


=C2=A0 "CHERI can do anything Multics could do: segmentation, paging,<= br> =C2=A0 dynamic linking, ring-structured software"

=C2=A0 =C2=A0-- Peter G. Neumann in "An Interview with..." by Ric= k Farrow in
=C2=A0 =C2=A0;login:, Winter 2017 vol. 42, no. 4

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg A. = Woods <gwoods@acm.or= g>

Kelowna, BC=C2=A0 =C2=A0 =C2=A0+1 250 762-7675=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0RoboHack <woods@robohack.ca>
Planix, Inc. <wood= s@planix.com>=C2=A0 =C2=A0 =C2=A0Avoncote Farms <woods@avoncote.ca>
--0000000000003558b605dc305f3a--