From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: Greenwald@cs.stanford.edu, thvv@multicians.org,
osibert@oxford.com, jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] Fwd: Public access multics
Date: Sat, 1 Sep 2018 19:25:37 -0400 (EDT) [thread overview]
Message-ID: <20180901232537.615A418C09E@mercury.lcs.mit.edu> (raw)
> From: Will Senn
> I was thinking that Multics was a failed predecessor of unix
> ... straighten me out :)
I'd start with:
https://multicians.org/myths.html
> From: Clem Cole <clemc@ccc.com>
> https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole
Clem, I think that's too limited in scope.
Like a lot of 'big' 'failures' (defined in Multics' case as 'failure to grow
to significant market share, and continue in the long term'), I don't think
Multics 'failed' for a single reason.
In general, in large failures, there are a number of causes, all doing their
bit. Now, if there are M causes, ranked in priority, maybe the first N1 are
_each_ big enough that _any one_ of them could have led to that outcome. Or
maybe not; maybe it needed the first N2, all acting in concert.
My crystal ball isn't that accurate. But here's my take on _some_ of Multics'
main issues.
- Management: if you look at:
https://multicians.org/hill-mgt.html
it's clear that Honeywell top management didn't understand Multics, and
didn't understand that it had a long-term potential. They terminated
investment in new hardware, and that was what finally killed Multics.
- Non-portability: the system was too tied to a specific platform; it
couldn't really be moved elsewhere. (E.g. the code is riddled with 'fixed bin
18'; yes, that could be changed with a program to edit the source, but there
are lots of dependencies on the specifics of the machine's architecture.) It
would be possible to re-write it to run on, say, a 386, but you'd pretty much
have to start from scratch.
- Built for the wrong future: a key assumption was that people would continue
to get their computes from large centralized machines. Clearly, that was
wrong (and it played into the issues with Honeywell management)>. Multics
_could_ have made the transition to today's 'small' (physically) machines, in
which case it would have been really good to have - e.g. if we could run
browsers in AIM boxes a lot of malware simply would not be an issue. But the
point above prevented that.
Those are some of the big ones; I may come up with more. I've CC'd a couple
of Multicians - perhaps they can add additional insight.
Noel
next reply other threads:[~2018-09-01 23:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-01 23:25 Noel Chiappa [this message]
2018-09-02 4:05 ` Will Senn
2018-09-02 4:25 ` [TUHS] " Jeffrey H. Johnson
2018-09-02 22:30 ` Will Senn
-- strict thread matches above, loose matches on Subject: below --
2018-09-01 20:31 Will Senn
[not found] ` <CAC20D2N-Q4VY8TLZagS6J2-US1G3emXVcOdX1BQZ44HYukD6ug@mail.gmail.com>
2018-09-01 20:50 ` [TUHS] Fwd: " 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=20180901232537.615A418C09E@mercury.lcs.mit.edu \
--to=jnc@mercury.lcs.mit.edu \
--cc=Greenwald@cs.stanford.edu \
--cc=osibert@oxford.com \
--cc=thvv@multicians.org \
--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).