Re: [TUHS] Fwd: Public access multics

Re: [TUHS] Fwd: Public access multics

[Noel Chiappa]

    > 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

Re: [TUHS] Fwd: Public access multics

[Will Senn]

On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

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

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

Re: [TUHS] Public access multics

[Jeffrey H. Johnson]

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@gmail.com> wrote:
> 
> On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> 
>>> 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
> 
> 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

Re: [TUHS] Public access multics

[Will Senn]

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@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@gmail.com> wrote:
>> 
>> On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>> 
>>>> 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
>> 
>> 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
> 

[TUHS] Fwd: Public access multics

[Clem Cole]

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

below...

On Sat, Sep 1, 2018 at 4:37 PM Will Senn <will.senn@gmail.com> wrote:

> So, it looks like someone has gone and started running a multics instance:
>
> http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html
>
> That’s interesting, and y’all may even have been aware of it. But, I was
> thinking that Multics was a failed predecessor of unix and it’s craziness
> an inspiration for how unix isn’t multics... straighten me out :)
>
>
https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole
ᐧ
ᐧ

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