The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] Were cron and at done at the same time? Or one before the other?
Date: Wed,  9 Dec 2020 14:25:36 -0500 (EST)	[thread overview]
Message-ID: <20201209192536.9A55018C088@mercury.lcs.mit.edu> (raw)

    > From: Niklas Karlsson

    > Just consider Multics, or IBM's "Future System".

Here's a nice irony for you: one of the key people in killing off FS was
reported to me (by someone who should have known) to be Jerry Saltzer (of
Multics fame). That wasn't the only time he did something like thst, either;
when MIT leaned on him to take over Athena, the first thing he did was to take
a lot of their ambitious system plans, and ditch them; they fell back to
mostly 'off the shelf' stuff: pretty much vanilla 4.2, etc.


Multics itself has an interesting story, quite different from the popular
image among those who know little (or nothing) of it. The system, as it was
when Honeywell pulled the plug on further generations of new hardware (in the
mid-80's) was very different from the system as originally envisaged by MIT
(in the mid-60's); it had undergone a massive amount 'experience-based
evolution' during those 20 years.

For instance, the original concept was to have a process per command (like
Unix), but that was dropped early on (because Multics processes were too
'expensive'); they wound up going with doing commands with inter-segment
procedure calls. (Which has the nice benefit that when a command faults, you
can get dropped right into the debugger, with the failed instance there to
look at.) If you read the Organick book on Multics, it describes a much
different system: e.g. in Organick there's a 'linkage segment' (used for
inter-segment pointers, in pure-code segments) per code segment, but in
reality Multics, as distributed, used a single 'combined linkage segment'
(which also contained the stack, also unlike the original design, where the
stack was a separate segment).

There were also numerous places where major sub-systems were re-implemeneted
from scratch, with major changes (often great simplifications): one major
re-do was the New Storage System, but that one had major new features (based
on operationally-shown needs, like the 4.1/.2 Fast File System), so it's not a
'simplification' case. There's one I read about which was much simpler the second
time it was implemented, I think it was IPC?

	Noel

             reply	other threads:[~2020-12-09 19:26 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 19:25 Noel Chiappa [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-12-13  2:02 Noel Chiappa
2020-12-13  2:08 ` Clem Cole
2020-12-09  4:35 M Douglas McIlroy
2020-12-09 15:40 ` Clem Cole
2020-12-09 15:46   ` Niklas Karlsson
2020-12-09 16:01   ` Bakul Shah
2020-12-09 16:11     ` Clem Cole
2020-12-09 17:05       ` Bakul Shah
2020-12-09 17:42         ` Dan Stromberg
2020-12-09 23:46           ` Nemo Nusquam
2020-12-14 20:28     ` Dave Horsfall
2020-12-14 22:23       ` Thomas Paulsen
2020-12-14 23:04         ` Andrew Hume
2020-12-14 23:59       ` Harald Arnesen
2020-12-17  4:08         ` John Cowan
2020-12-15  2:57       ` Bakul Shah
2020-12-15  3:05         ` Warner Losh
     [not found]   ` <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>
2020-12-09 16:04     ` John Foust
2020-12-09 16:40   ` Warner Losh
2020-12-09 16:53     ` Jon Steinhart
2020-12-09 16:58   ` Theodore Y. Ts'o
2020-12-09 19:58     ` Dan Cross
2020-12-09 20:30       ` Will Senn
2020-12-13  1:07       ` Theodore Y. Ts'o
2020-12-13  1:56         ` Jon Steinhart
2020-12-13  2:58           ` Theodore Y. Ts'o
2020-12-13  3:07             ` Jon Steinhart
2020-12-13 16:49               ` Theodore Y. Ts'o
2020-12-13  3:02         ` Dan Cross
2020-12-09 23:22     ` Bakul Shah
2020-12-09 23:44       ` Steffen Nurpmeso
2020-12-09 23:51         ` Steffen Nurpmeso
2020-12-12  2:56   ` Dave Horsfall
2020-12-12 19:10     ` scj
2020-12-08 18:11 ron minnich
2020-12-08 18:51 ` Mary Ann Horton
2020-12-08 19:05   ` Larry McVoy
2020-12-08 19:20     ` Michael Kjörling
2020-12-09  2:00       ` Dave Horsfall
2020-12-08 19:39   ` Clem Cole

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=20201209192536.9A55018C088@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --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).