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

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