The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Interesting commentary on Unix from Multicians.
@ 2022-04-07 16:32 Dan Cross
  2022-04-08  5:30 ` Lars Brinkhoff
  0 siblings, 1 reply; 20+ messages in thread
From: Dan Cross @ 2022-04-07 16:32 UTC (permalink / raw)
  To: TUHS main list

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

I came across this talk that, apparently, was meant to be part of a
documentary about timesharing systems at MIT:
https://www.youtube.com/watch?v=KZPYBDA6XVo

This "episode" features McCarthy, Corbato, Fano, Fredkin, and Philip Morse
talking about Multics.

Starting at ~12:15m they talk about the triumvirate of MIT, GE and Bell
Labs and some of the challenges with distributed work. Around the 14 minute
mark, they talk about Bell Labs exiting the project, and touch briefly on
the development of Unix. Interesting quotes include Fano talking about
different objectives from the different organizations, Corby saying, "they
[Bell Labs] dropped out three-quarters of the way through the race"
(referring to Multics), Fano asserting that BTL left after the _research_
part of the project was essentially completed, and Corbato talking about
the influence of Multics on Unix design (Corby refers to Multics as Ken and
Dennis's "prototype" and calls Unix a "second generation Multics"). This
was all shot in the early 1980s.

The rest is interesting, but mostly unrelated to Unix.

        - Dan C.


(PS: As an aside, Fano lighting up a cigarette at about 19:20 was
particularly striking: my, how times have changed.)

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-07 16:32 [TUHS] Interesting commentary on Unix from Multicians Dan Cross
@ 2022-04-08  5:30 ` Lars Brinkhoff
  2022-04-08 13:34   ` Clem Cole
  2022-04-08 13:59   ` Dan Cross
  0 siblings, 2 replies; 20+ messages in thread
From: Lars Brinkhoff @ 2022-04-08  5:30 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

Dan Cross wrote:
> Interesting quotes include Fano talking about different objectives
> from the different organizations, Corby saying, "they [Bell Labs]
> dropped out three-quarters of the way through the race" (referring to
> Multics), Fano asserting that BTL left after the _research_ part of
> the project was essentially completed

Multics was started in 1964 and first went online in 1967, although it
seems likely it wasn't exactly at the top of its game yet.  Bell Labs
pulled out in 1969.  If that was the 75% point, 100% would be around
1971.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  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
  1 sibling, 1 reply; 20+ messages in thread
From: Clem Cole @ 2022-04-08 13:34 UTC (permalink / raw)
  To: Lars Brinkhoff; +Cc: TUHS main list

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

On Fri, Apr 8, 2022 at 1:33 AM Lars Brinkhoff <lars@nocrew.org> wrote:

> Multics was started in 1964 and first went online in 1967, although it
> seems likely it wasn't exactly at the top of its game yet.  Bell Labs
> pulled out in 1969.  If that was the 75% point, 100% would be around 1971.
>
Not to put too fine a point on it, It seems like it would be fair to say
Multics was 'complete' by the time Organick published his book: *"**The
Multics System: An Examination of Its Structure**.*" Amazon says the 3rd
printing was April 72, so that means he must have published it earlier.  I
don't know when it first appeared and can not seem to find it.  My copy is
in storage but I bet I have the 3rd printing.   But I had >>thought<< that
was still in the late 1960s.   Anyone have a first edition around with the
publication date?
ᐧ
ᐧ

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08  5:30 ` Lars Brinkhoff
  2022-04-08 13:34   ` Clem Cole
@ 2022-04-08 13:59   ` Dan Cross
  2022-04-08 15:28     ` Larry McVoy
  2022-04-08 15:45     ` Jon Steinhart
  1 sibling, 2 replies; 20+ messages in thread
From: Dan Cross @ 2022-04-08 13:59 UTC (permalink / raw)
  To: Lars Brinkhoff; +Cc: TUHS main list

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

On Fri, Apr 8, 2022 at 1:30 AM Lars Brinkhoff <lars@nocrew.org> wrote:

> Dan Cross wrote:
> > Interesting quotes include Fano talking about different objectives
> > from the different organizations, Corby saying, "they [Bell Labs]
> > dropped out three-quarters of the way through the race" (referring to
> > Multics), Fano asserting that BTL left after the _research_ part of
> > the project was essentially completed
>
> Multics was started in 1964 and first went online in 1967, although it
> seems likely it wasn't exactly at the top of its game yet.  Bell Labs
> pulled out in 1969.  If that was the 75% point, 100% would be around
> 1971.
>

In context, I don't think Corby's statement was meant to be taken
literally, but rather he used it as more of a colloquialism. His point was
that (at least in his perception) the bulk of the work had been done when
BTL dropped out of the project.

Fano's statements are a bit overshadowed by Corby's here, but when he
talked about each of the three participants in the Multics project at its
outset working on one project but with different goals, he stated that his
impression was that Bell Labs was interested in both the research products
as well as a production system that they actually could use. In particular,
they expected that the latter would be delivered on a specific timetable:
when the research part basically wrapped and the system still wasn't
production ready, they dropped out.

MIT started offering timesharing access on Multics in 1969. A second site
at Griffiss Air Force Base in Rome, NY was operational by 1970. Honeywell
announced the 6180 running Multics as a product in 1973; throughout the 70s
things were tuned, cleaned up, and new subsystems introduced. The "New
Storage System", which started in 1973 and was delivered to customers in
1976. I think it's fair to say that, by the mid-70s, Multics had fully
transitioned from "research project" to "commercial system."

Bell Labs dropping out of Multics in 1969 was, of course, before Unix. This
raises the question, what did Bell Labs use instead? I imagine 360s and
either traditional batch processing or TSS or something?

Of course, by 1976, Unix was at 6th Edition and I can see why no one would
want to go back to Multics (or being tied to a machine costing an order of
magnitude more than a PDP-11). But one wonders what would have happened had
Multics started accepting timesharing, say, 9 months earlier than it did.

It would be interesting to hear what it was like when Bell Labs withdrew
from the Multics project. Does anyone have any stories? Perhaps Ken or
Doug? Also, what was the relationship like with the MIT people after that?
Corby et al seemed somewhat animated in insisting that Multics had been
essential to the creation of Unix, almost as if that had not been
sufficiently acknowledged; I imagine by the time this video was shot, they
must have been feeling somewhat overshadowed by the success of Unix.

        - Dan C.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08 13:34   ` Clem Cole
@ 2022-04-08 14:14     ` Dan Cross
  0 siblings, 0 replies; 20+ messages in thread
From: Dan Cross @ 2022-04-08 14:14 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

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

On Fri, Apr 8, 2022 at 9:34 AM Clem Cole <clemc@ccc.com> wrote:

> On Fri, Apr 8, 2022 at 1:33 AM Lars Brinkhoff <lars@nocrew.org> wrote:
>
>> Multics was started in 1964 and first went online in 1967, although it
>> seems likely it wasn't exactly at the top of its game yet.  Bell Labs
>> pulled out in 1969.  If that was the 75% point, 100% would be around
>> 1971.
>>
> Not to put too fine a point on it, It seems like it would be fair to say
> Multics was 'complete' by the time Organick published his book: *"**The
> Multics System: An Examination of Its Structure**.*" Amazon says the 3rd
> printing was April 72, so that means he must have published it earlier.  I
> don't know when it first appeared and can not seem to find it.  My copy
> is in storage but I bet I have the 3rd printing.   But I had >>thought<<
> that was still in the late 1960s.   Anyone have a first edition around
> with the publication date?ᐧ
>

I have a scanned copy of Organick from MIT that says Copyright 1972 (and
has a stamp from the Barker Engineering Library listing May 16, 1972 as the
acquisition date).  I can't see any indication that this is anything other
than the first printing. Corbato's forward is dated Dec 13, 1971.

However, Organick's book is often said to describe an earlier version of
the system, up to somewhere in the vicinity of 1968/1970 (
https://multicians.org/history.html, also message to the old Multicians
list at Yahoo! I'm not sure about the archives of that, so don't have a
link). I understand that Multics got much better after the move to the 6180
and DPS8/M; Organick's book describes GE 645 Multics only.

        - Dan C.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08 13:59   ` Dan Cross
@ 2022-04-08 15:28     ` Larry McVoy
  2022-04-08 15:35       ` Dan Cross
                         ` (2 more replies)
  2022-04-08 15:45     ` Jon Steinhart
  1 sibling, 3 replies; 20+ messages in thread
From: Larry McVoy @ 2022-04-08 15:28 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

On Fri, Apr 08, 2022 at 09:59:26AM -0400, Dan Cross wrote:
> Of course, by 1976, Unix was at 6th Edition and I can see why no one would
> want to go back to Multics (or being tied to a machine costing an order of
> magnitude more than a PDP-11). But one wonders what would have happened had
> Multics started accepting timesharing, say, 9 months earlier than it did.

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 guess what I'm trying to ask is if Multics had modern hardware
under it, performed well, would we want to be running it?

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  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
  2 siblings, 0 replies; 20+ messages in thread
From: Dan Cross @ 2022-04-08 15:35 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

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

On Fri, Apr 8, 2022 at 11:28 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Fri, Apr 08, 2022 at 09:59:26AM -0400, Dan Cross wrote:
> > Of course, by 1976, Unix was at 6th Edition and I can see why no one
> would
> > want to go back to Multics (or being tied to a machine costing an order
> of
> > magnitude more than a PDP-11). But one wonders what would have happened
> had
> > Multics started accepting timesharing, say, 9 months earlier than it did.
>
> 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 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'm running Multics under emulation at home and I think it's actually
pretty cool.

I imagine that both Doug and Ken would remember it pretty well?

        - Dan C.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08 13:59   ` Dan Cross
  2022-04-08 15:28     ` Larry McVoy
@ 2022-04-08 15:45     ` Jon Steinhart
  1 sibling, 0 replies; 20+ messages in thread
From: Jon Steinhart @ 2022-04-08 15:45 UTC (permalink / raw)
  To: TUHS main list

Dan Cross writes:
> Bell Labs dropping out of Multics in 1969 was, of course, before Unix. This
> raises the question, what did Bell Labs use instead? I imagine 360s and
> either traditional batch processing or TSS or something?

Someone who was older than me at the time like Heinz probably knows more
than I do.  My recollection is that many departments had their own random
systems as minicomputers took over.  We used 516-TSS on a Honeywell DDP-516/
I have no idea what Max Matthews ran on his DDP-224 but would guess that it
was all custom stuff.  I believe that the behemoth GE-635 aka Honeywell 6070
in the computer center ran GECOS.  I don't know if that machine was originally
there for the MULTICS project.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  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
  2 siblings, 0 replies; 20+ messages in thread
From: Rich Morin @ 2022-04-08 19:36 UTC (permalink / raw)
  To: TUHS main list

> On Apr 8, 2022, at 08:28, Larry McVoy <lm@mcvoy.com> wrote:
> 
> ... 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?

On a related note, I'd love to hear from some folks who have used both Multics and Unix(ish) systems about things that differ and how they affect the user experience.

-r



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  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
  2022-04-08 23:34         ` Andrew Warkentin
                           ` (2 more replies)
  2 siblings, 3 replies; 20+ messages in thread
From: Greg A. Woods @ 2022-04-08 21:02 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- 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 --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08 21:02       ` Greg A. Woods
@ 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
  2 siblings, 1 reply; 20+ messages in thread
From: Andrew Warkentin @ 2022-04-08 23:34 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

On 4/8/22, Greg A. Woods <woods@robohack.ca> wrote:
>
> 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!).
>
I think it's useful to have both I/O and memory views for files.
Things like commands that work equally well whether stdout is a disk
file or something like a pipe wouldn't work so well in a system where
disk files can only be accessed through a memory-like interface.
However, I guess the I/O interface could just be implemented with
library functions rather than real I/O syscalls for disk-like files.

Maybe I could try doing something like that in my OS but I'm not
completely sure if it would affect performance because it will be
QNX-like, and reads and writes would probably require the VFS to act
as an intermediary sometimes whereas that wouldn't be the case with
I/O since reads and writes would otherwise map onto kernel message
passing without any intermediary servers.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08 21:02       ` Greg A. Woods
  2022-04-08 23:34         ` Andrew Warkentin
@ 2022-04-09  3:33         ` Adam Thornton
  2022-04-09 12:10         ` tytso
  2 siblings, 0 replies; 20+ messages in thread
From: Adam Thornton @ 2022-04-09  3:33 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- 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 --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08 21:02       ` Greg A. Woods
  2022-04-08 23:34         ` Andrew Warkentin
  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
  2 siblings, 2 replies; 20+ messages in thread
From: tytso @ 2022-04-09 12:10 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

On Fri, Apr 08, 2022 at 02:02:23PM -0700, Greg A. Woods wrote:
> 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!).

To be fair, Multics had it a lot easier, because core memory meant
that every single memory access could be considered "durable storage",
so there was no real need for "fsync(2)" or "msync(2)".

So I/O consistency could be done much like writing to persistent
memory, except that there would be no need for "CLFLUSH" (Who needs
multi-level memory caches when the clock cycle is pathetically slow?)
and no need to worry about write endurance exhaustion with core
memory, either.

So how much of the consistency benefits are due to the hardware, and
how much is due to the OS?  We could just as easily claim that Multics
is superior to Unix because it's immune to Spectre and Meltdown
attacks --- except that Unix on a PDP-11 would be immune to cache
based attacks as well.  Of course, Unix on a PDP-11 is a lot slower
than NetBSD on an modern x86_64 machines....

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

What if we compared Multics dynamic linking to Solaris Doors?

     	   	    	    	    	       - Ted

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-09 12:10         ` tytso
@ 2022-04-09 13:09           ` Dan Cross
  2022-04-09 19:14           ` Greg A. Woods
  1 sibling, 0 replies; 20+ messages in thread
From: Dan Cross @ 2022-04-09 13:09 UTC (permalink / raw)
  To: TUHS main list

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

On Sat, Apr 9, 2022, 8:18 AM tytso <tytso@mit.edu> wrote:

> On Fri, Apr 08, 2022 at 02:02:23PM -0700, Greg A. Woods wrote:
> > 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!).
>
> To be fair, Multics had it a lot easier, because core memory meant
> that every single memory access could be considered "durable storage",
> so there was no real need for "fsync(2)" or "msync(2)".
>

This may have been true of the very first Multics machines, but it appears
they switched to solid state memory sometime in the 70s (it's not clear to
me when the SCUs attached to the 6180 switched from core to DRAM:
https://gunkies.org/wiki/Honeywell_6000_series). By the time the DPS8/M
rolled out we must assume they had DRAM. Apparently a cache hierarchy was
added eventually.

        - Dan C.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-09 12:10         ` tytso
  2022-04-09 13:09           ` Dan Cross
@ 2022-04-09 19:14           ` Greg A. Woods
  1 sibling, 0 replies; 20+ messages in thread
From: Greg A. Woods @ 2022-04-09 19:14 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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

At Sat, 9 Apr 2022 08:10:21 -0400, tytso <tytso@mit.edu> wrote:
Subject: Re: [TUHS] Interesting commentary on Unix from Multicians.
>
> To be fair, Multics had it a lot easier, because core memory meant
> that every single memory access could be considered "durable storage",
> so there was no real need for "fsync(2)" or "msync(2)".

As Dan mentioned, actual "core" memory was long gone by the time Multics
was in commercial use.  Core memory was only used in the
first-generation 6000 series (and presumably the GE-635 too),
i.e. before 1975.

One source says there was cache memory in the CPUs as early as 1974.
The later machines, such as the DPS-8/70M ("M" for Multics) definitely
came with 8KW cache memory that could be expanded up to 32KW.

These systems were also generally used in multi-processing
configurations, especially for Multics, with multiple CPUs, each with
potentially multiple memory units (and multiple IOMm (I/O Multiplexer),
later IMUs (Information Multiplexer Unit)).

As for how this cache memory was used and how its consistency with main
memory and with secondary storage was maintained, I don't know myself,
but of course much documentation about Multics internals is available,
along with all the source code, and it is running on simulators today.


> > 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.
>
> What if we compared Multics dynamic linking to Solaris Doors?

I don't think Doors is really relatable to Multics dynamic linking.
As I understand it, Doors is more like RPC than directly shared code.

In Multics all code, even kernel code, is generally shared -- in broad
terms user processes just "gate" (i.e. jump) directly to code in a
lower/inner "ring" to run system calls (e.g. Ring-0).  Code doesn't even
have to exist when first called (similar to how methods don't have to
pre-exist in Smalltalk) -- the user gets a "linkage fault" and can write
and compile the missing code and continue a program at the fault point.

Also there's no such thing as "relocation" of code in Multics --
segmented memory means all segments have their own zero address and so
all code is pure procedure and can be executed by many processes
simultaneously simply by mapping the shared code segments into each
process (as read-only, executable).  Shared libraries of a sort (bound
segments) do exist, partly because of performance issues (dynamic link
faults are expensive in Multics, especially on hardware of the day), and
partly because of addressing limitations (only a quite limited number of
segments can be attached to any given process), and partly because
otherwise there would be effectively one global namespace for all
symbols exposed by each compilation unit in a user's $PATH.

One of the difficult things for Unix people to wrap their heads around
is the difference between a "process" in Unix and in Multics.  One way
to think about it that has helped me figure it out is this:  In Multics
you have a "shell" program which you interact with just like with "sh"
in Unix, but it's not a separate process in Multics -- just a unit of
code that effectively runs when no other program is running.  So
generally a user only runs one process at a time, even though it may
transition through hundreds or thousands of programs during its
existence.

Multics did eventually have the concept of multi-threading and a form of
co-operative multi-tasking too, though I don't know as much about these.
I think the latter would/could effectively be like having multiple
processes in one login session in Unix and it is said this facility was
used to implement network service daemons for example.

Now I don't believe the Multics concept of "process" is strictly
necessary to support its concepts of Single Level Storage or even
Dynamic Linking.  I believe those could be used equally well in a system
with more Unix-like processes, though some mix of concepts might be
required to truly benefit from all the features of Multics-style dynamic
linking.

One way I've been thinking of Multics lately is that it's more like
modern virtualization (e.g. Xen), but with added OS services such as a
filesystem and controlled access to shared "inner ring" code; and indeed
that's more or less how it was described in early Multics concept
papers, assuming you transmogrify the old terminology of the day into
modern lingo.  Each user gets a computing environment that gives them
the impression they have full use of the machine, and it comes along
with pre-existing useful code and various useful services, including a
filesystem the ability to communicate with other users and other
machines.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-08 23:34         ` Andrew Warkentin
@ 2022-04-09 19:28           ` Greg A. Woods
  0 siblings, 0 replies; 20+ messages in thread
From: Greg A. Woods @ 2022-04-09 19:28 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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

At Fri, 8 Apr 2022 17:34:27 -0600, Andrew Warkentin <andreww591@gmail.com> wrote:
Subject: Re: [TUHS] Interesting commentary on Unix from Multicians.
>
> I think it's useful to have both I/O and memory views for files.
> Things like commands that work equally well whether stdout is a disk
> file or something like a pipe wouldn't work so well in a system where
> disk files can only be accessed through a memory-like interface.
> However, I guess the I/O interface could just be implemented with
> library functions rather than real I/O syscalls for disk-like files.

I/O is good for I/O of course (e.g. to devices, like terminals and
printers and such), and if you can "attach" that I/O to a segment, or to
another program's I/O, all the better:

    https://multicians.org/myths.html#nofile

(One big complication forced by hardware limitations of the day was
rather limited file (i.e. segment) size, and thus Multics developers
invented multi-segment files, and as mentioned in that link, stream
access to them was often through the I/O mechanism, but of course this
was a simulation done by copying (I think) data from a mapped segment of
the file to a buffer in a heap segment.)

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-10 17:14 Noel Chiappa
  2022-04-10 17:31 ` Larry McVoy
@ 2022-04-10 20:41 ` John Cowan
  1 sibling, 0 replies; 20+ messages in thread
From: John Cowan @ 2022-04-10 20:41 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list

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

On Sun, Apr 10, 2022 at 1:18 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:


> Unix had (and still may have, I'm not up on Linux, etc) a really major,
> hard
> boundary beween 'user' code, in processes,and the kernel. There are
> 'instructions' that invoke system primitives - but not too many, and
> limited
> interactions across that boundary. So, restricted semantics.
>

The same is true for the more recent Unix variants, modulo a few special
cases such as Larry mentions, but broadly speaking userland and the kernel
are still separated.

> Imagine building a
> large application which had a hard boundary across the middle of it, with
> extremely limited interactions across the boundary.
>

You mean like the Web?  :-)

In 2000-2005 I wrote a substantial quasi-batch application that supported
$EMPLOYER's main product and was written about half in shell scripts and
half in Perl, or more accurately entirely in shell scripts, but if I needed
a pipeline component that wasn't already available in SunOS or as
third-party open source, I wrote it in Perl.  (There was a single 10-line C
program to eliminate a performance bottleneck.)  So the application as a
whole was full of hard boundaries across which nothing could pass except
text streams; I found that this added substantially to its debuggability
and maintainability.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
  2022-04-10 17:14 Noel Chiappa
@ 2022-04-10 17:31 ` Larry McVoy
  2022-04-10 20:41 ` John Cowan
  1 sibling, 0 replies; 20+ messages in thread
From: Larry McVoy @ 2022-04-10 17:31 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

On Sun, Apr 10, 2022 at 01:14:22PM -0400, Noel Chiappa wrote:
> Unfortunately, one of the two (to me) best things about Unix, is something it
> has since lost - which is its incredible bang/buck ratio - to be more
> precise, the functionality/complexity ratio of the early versions of the
> system.

Amen to that though I think our memory is clouded by V6 that was
uniprocessor, no networking.  With all due respect to Unix, that's
not a hard problem.   Systems today are more complex with SMP, NUMA,
networking, etc.

> Which was good in that it helped keep the system simple and clear - but it
> limited the flexibilty and richness of the interface. (Imagine building a
> large application which had a hard boundary across the middle of it, with
> extremely limited interactions across the boundary. Just so with the
> interface in Unix between 'user' code, and the kernel.)

That has changed in the last decade or two.  Pugs did the work to expose
the IOMMU to user process and that has definitely blurred the line.

Thanks for your thoughtful email, I'm still absorbing it.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
@ 2022-04-10 17:14 Noel Chiappa
  2022-04-10 17:31 ` Larry McVoy
  2022-04-10 20:41 ` John Cowan
  0 siblings, 2 replies; 20+ messages in thread
From: Noel Chiappa @ 2022-04-10 17:14 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Rich Morin <rdm@cfcl.com>

    > I'd love to hear from some folks who have used both Multics and
    > Unix(ish) systems about things that differ and how they affect the
    > user experience.

{This is a bit behind the flow of the conversation, because I wanted to
ponder for a while what I was going to say on this, to me, important topic.}

Technicaly, I don't quite qualify (more below), but I do have an interesting
perspective: I was the very first Unix person in the 'Multics' group at
MIT-LCS - the Computer Systems Group, which contained Corby and Jerry Saltzer.

The interesting thing, which may surprise some people, is that I _never_ got
any 'anti-Unix' static from anyone in the group, that I can remember. (Maybe
one grad student, who was a bit abrasive, but he and I had a run-in that was
mostly? caused by my fairly rapid assumption, as an un-paid undergrad, of a
significant role in the group's on-going research work. So that may have bled
across a bitt, to Unix, which was 'my' baby.)

I'm not sure what _they_ all made of Unix. None of us knew, of course, where
it was going to go. But I don't recall getting any 'oh, it's just a toy
system' (an attitude I'm _very_ familiar with, since it was what the TCP/IP
people got from _some_ members of what later became the ISO effort). Of
course, our Unix was a tiny little PDP-11/40 - not a building-sized
multi-processor 'information utility' mainframe - so they may well have not
thought of it in the same frame as Multics. Also, by the time I arrived the
group was doing nothing on Multics (except below); everyone was focused on
networks. So OS's were no longer a topic of much research interest, which may
also have contributed.


Anyway, technically, I don't count for the above, because I never actualy
wrote code on Multics. However, I had studied it extensively, and I worked
very closely with Dave Clark (a younger Multics light, later a leading figure
in the early TCP/IP work) on projects that involved Multics and my machine,
so I got to see up close what Multics was like as a system environment, as he
worked on his half of the overall project. I've also pondered Multics in the
decades since; so here's my take.

I really, really liked Unix (we were running what turns out to have been
basicaly a PWB1 system - V6, with some minor upgrades). I learned about it
the way many did; I read the manuals, and then dove into the system source
(which I came to know quite well, as I was tasked with producing a piece that
involved a major tweak - asynchronous 'raw' DMA I/O directly to user
processes).

Unfortunately, one of the two (to me) best things about Unix, is something it
has since lost - which is its incredible bang/buck ratio - to be more
precise, the functionality/complexity ratio of the early versions of the
system.

(Its other important aspect, I think, was that its minimal demands of the
underlying hardware [unlike Multics, which was irretrievably bound to the
segmentation, and the inter-segment data and code connection] along with its
implementation in what turned out to be a fairly portable language (except
for the types; I had to make up what amounted to new ones.)


So, what was Multics' major difference from other systems - and why
was it good?

I'd say that it was Multics' overall structuring mechanisms - the
single-level store, with the ability to have code and data pointers between
segments - and what that implied for both the OS itself, and major
'applications' (some of them part of the OS, although not the 'kernel' - like
networking code).

Unix had (and still may have, I'm not up on Linux, etc) a really major, hard
boundary beween 'user' code, in processes,and the kernel. There are
'instructions' that invoke system primitives - but not too many, and limited
interactions across that boundary. So, restricted semantics.

Which was good in that it helped keep the system simple and clear - but it
limited the flexibilty and richness of the interface. (Imagine building a
large application which had a hard boundary across the middle of it, with
extremely limited interactions across the boundary. Just so with the
interface in Unix between 'user' code, and the kernel.)

Multics is very different. The interface to the OS is subroutine calls, and
one can easily pass complex data structures, including pointers to other
data, any of which can be in the 'user's' memory, as arguments to them. The
_exact_ same _kind_ of interface was available to _other_ major subsystems,
not just the OS kernel.

As I've mentioned before, Dave's TCP/IP for Multics was not in the kernel -
it was ordinary user code! And he was able to work on it, test and install
new versions - while the system was up for normal useage!

Dave's TCP/IP subsystem included i) a process, which received all incoming
ackets, and also managed/handled a lot of the timers involved (e.g.
retransmission timeouts); ii) data segment(s), which included things like
buffered un-acknowledged data (so that if a retransmission timer went off,
the process would wake up and retransmit the data); iii) code segment(s):
iiia) some for use by the process, like incoming packet processing; iiib)
some which were logically part of the subsystem, but which were called by
subroutine calls from the _user_'s process; and iiic) some which were
commands (called by the user's shell), which called those iiib) procedures.

(There were issues in security because Multics didn't have the equivalent of
'set-user-id' on a cross-subsystem subroutine calls - although I think there
had been plans early on for that. When Dave's code was taken over by
Honeywell, for 'production' use, whole whole thing was moved into a lower
ring, so the database didn't have to be world-writeable in the user ring.)

This is typical of the kind of structure that was relatively easy to build in
Multics. Yes, one can do similar application without all those underlying
mechanism; but Turing-completeness says one doeesn't need stacks to compute
anything - but would any of us want to work in a system that didn't have
stacks? We have stacks because they are useful.

True, simple user applications don't need all that - but as one builds more
and more complex support subsytems, that kind of environment turns out to be
good to have. Think of a window system, in that kind of environment. Those
'tools' (inter-segment subroutine calls, etc) were created to build the OS,
but they turned out to be broadly useful for _other_ complicated subsystems.

I'm not sure I've explained this all wel, but I'm not sure I can fully
cover the topic with less than a book.

	Noel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] Interesting commentary on Unix from Multicians.
@ 2022-04-08 16:07 Noel Chiappa
  0 siblings, 0 replies; 20+ messages in thread
From: Noel Chiappa @ 2022-04-08 16:07 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Clem Cole

    > Not to put too fine a point on it, It seems like it would be fair to
    > say Multics was 'complete' by the time Organick published his book

This is a pretty ill-judged claim, IMO - but not for any particulars about
the Organick book, etc. The problem is more global.

When was UNIX 'complete' - when the first people were able to do real work on
the PDP-7? When non-programmer clerks from the patent group were able to use
the assembler UNIX on the PDP-11 to format parent documents? When it was
re-written in C for the 4th Edition (since the _portability_ of UNIX was IMO
perhaps the greatest factor in its eventual domination)? Etc, etc, etc.

The exact same problem applies to the question of 'when was Multics
'complete''.

    > don't know when it first appeared and can not seem to find it. ... I
    > bet I have the 3rd printing. ... Anyone have a first edition around
    > with the publication date?

The third printing _is_ the first edition. Anyway, it doesn't matter - see
above. And of course even if the book _wriring_ was finished at time T, it
wouldn't have been printed until some unknown time later. So that's really
pretty useless as a temporal marker; we have much better ones availablw.


    > From: Dan Cross

    > I can't see any indication that this is anything other than the first
    > printing.

My 3rd printing says 3rd was 1980, 2nd in 1976, and copyright 1972.

    > Organick's book is often said to describe an earlier version of the
    > system

Yes; I'm not sure if the version described in it was ever available for
general usege (which could be my definition of 'complete') - or even usage my
Multics system programmers. I don't remember all the details of the
differences (it's been way too long since I read it, and I don't know the
details of the 'first operational' Multics well enough), but for instance:

ISTR that it describes a version which had a linkage segment (holding
intermediate locations in outbound links - since segment >a>b>c might well
have different segment numbers assigned to it in the address spaces of
processes X and Y, so one copy of >a>b>c, shared between X and Y, couldn't
contain direct outbound links) _per segment_ (data or code) - but operational
Multics (I don't know if this is from 'first available to users', or 'first
available to Multics system programmers', or what) collapsed all the linkage
info into a 'combined linkage segment', in which the linkage info from all
the segments in a process' address space were combined (by copying) into a
single linkage segment.

Etc, etc, etc.

    > I understand that Multics got much better after the move to the 6180

I'm not sure that the 6180 made that big a difference to the environment the
average use saw. My understanding (not having been there) was that the big
_architectural_ difference was that cross-ring inter-segment references were
done and monitored in hardware, so a host of security holes caused by
insufficient checking of cross-ring inter-segment pointers were caught
automatically. (The 6180 was also built out of SSI chips, unlike the 645 which
was individual transistors, like a KA10.)

	Noel

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2022-04-10 20:44 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-07 16:32 [TUHS] Interesting commentary on Unix from Multicians 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
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

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).