1 Sep
2018
1 Sep
'18
11:25 p.m.
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(a)ccc.com>
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
2 Sep
2 Sep
4:05 a.m.
New subject: Fwd: Public access multics
On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
Noel, Fascinating read. I must’ve read at least a good handful of the references leading
to the myths described in the writeup. As usual, I can trust the folks who lived history
to remember it more clearly than many revisionists writing about it later.
Thanks for sharing.
Now, I’m wondering what awesome features Multics had that we’re still lacking in modern
*nices... anything as amazing as say, my favorite filesystem, ZFS?
Will
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
> 
4:25 a.m.
New subject: Public access multics
While the best loved feature is probably the pervasive dynamic linking, which is still
unrivaled, and the security features (ring brackets, AIM (multilevel labeling), and ACLs)
which are the most famous, a feature that isn't built in to Unix and is constantly
being reinvented that was available in Multics is the ability to easily set aside a CPU
and some memory and disk, while leaving the system in operation, and start another
separate instance to do development work, and then when the work is done, be reconfigured
to merge the system back into one instance, without disrupting production work.
That dynamic reconfiguration was one original design specifications of the system, as
opposed to being added later. Much of what makes Multics wonderful to me is just how
amazingly sturdily it's engineered and how complete the implementations of these
ideas are.
Another thing to comes to mind immediately is how hierarchical the system is. For example,
users are registered on to projects, and a project administrator can be delegated the task
of registering and deregistering user accounts and managing the system resources such as
disk quota and access to printers and other physical resources for their project.
The system administrator can manage the resources assigned to projects, and the project
administration handles how that's further carved up amongst the users.
You can have similar granularity in assigning the distribution of resources such as CPU
and memory use, by using the workload management features to ensure that high priority
tasks/users/projects will always have needed resources available, preempting lower
priority tasks if necessary.
The I/O system, (while not exceedingly elegant - see iox_), far exceeds what is available
in Unix today, but by design.
The reputation of Multics as a 'complex' system is, in my experience, well
deserved, but that complexity does not mean it's a terrible system to use or
administer. I find it quite refreshing and it almost never feels dated.
-- Jeff
https://ban.ai/multics
On Sep 2, 2018, at 12:05 AM, Will Senn
<will.senn(a)gmail.com> wrote:
On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
Noel, Fascinating read. I must’ve read at least a good handful of the references leading
to the myths described in the writeup. As usual, I can trust the folks who lived history
to remember it more clearly than many revisionists writing about it later.
Thanks for sharing.
Now, I’m wondering what awesome features Multics had that we’re still lacking in modern
*nices... anything as amazing as say, my favorite filesystem, ZFS?
Will
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
10:30 p.m.
New subject: Public access multics
Nice. I’ve always marveled at how, dare I say it while not doing anything about it, badly,
dynamic linking has fared in nearly every os I can think of? It is a very convenient
feature to have, but the way are implemented can be a little frustrating to a user who
isn’t steeped in the internals of the implementation.
Thanks for the lesson!
Sent from my iPhone
On Sep 1, 2018, at 11:25 PM, Jeffrey H. Johnson
<trnsz(a)pobox.com> wrote:
While the best loved feature is probably the pervasive dynamic linking, which is still
unrivaled, and the security features (ring brackets, AIM (multilevel labeling), and ACLs)
which are the most famous, a feature that isn't built in to Unix and is constantly
being reinvented that was available in Multics is the ability to easily set aside a CPU
and some memory and disk, while leaving the system in operation, and start another
separate instance to do development work, and then when the work is done, be reconfigured
to merge the system back into one instance, without disrupting production work.
That dynamic reconfiguration was one original design specifications of the system, as
opposed to being added later. Much of what makes Multics wonderful to me is just how
amazingly sturdily it's engineered and how complete the implementations of these
ideas are.
Another thing to comes to mind immediately is how hierarchical the system is. For
example, users are registered on to projects, and a project administrator can be delegated
the task of registering and deregistering user accounts and managing the system resources
such as disk quota and access to printers and other physical resources for their project.
The system administrator can manage the resources assigned to projects, and the project
administration handles how that's further carved up amongst the users.
You can have similar granularity in assigning the distribution of resources such as CPU
and memory use, by using the workload management features to ensure that high priority
tasks/users/projects will always have needed resources available, preempting lower
priority tasks if necessary.
The I/O system, (while not exceedingly elegant - see iox_), far exceeds what is available
in Unix today, but by design.
The reputation of Multics as a 'complex' system is, in my experience, well
deserved, but that complexity does not mean it's a terrible system to use or
administer. I find it quite refreshing and it almost never feels dated.
-- Jeff
https://ban.ai/multics
On Sep 2, 2018, at 12:05 AM, Will Senn
<will.senn(a)gmail.com> wrote:
On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
Noel, Fascinating read. I must’ve read at least a good handful of the references leading
to the myths described in the writeup. As usual, I can trust the folks who lived history
to remember it more clearly than many revisionists writing about it later.
Thanks for sharing.
Now, I’m wondering what awesome features Multics had that we’re still lacking in modern
*nices... anything as amazing as say, my favorite filesystem, ZFS?
Will
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
2076
days inactive
2077
days old
3 comments
3 participants
participants (3)
-
Jeffrey H. Johnson -
jnc＠mercury.lcs.mit.edu -
Will Senn