The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Jeffrey H. Johnson" <trnsz@pobox.com>
To: tuhs@tuhs.org
Subject: Re: [TUHS] Public access multics
Date: Sun, 2 Sep 2018 00:25:44 -0400	[thread overview]
Message-ID: <0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com> (raw)
In-Reply-To: <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com>

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


  reply	other threads:[~2018-09-02  4:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-01 23:25 [TUHS] Fwd: " Noel Chiappa
2018-09-02  4:05 ` Will Senn
2018-09-02  4:25   ` Jeffrey H. Johnson [this message]
2018-09-02 22:30     ` [TUHS] " Will Senn
  -- strict thread matches above, loose matches on Subject: below --
2018-09-03 13:29 Doug McIlroy
2018-09-03 23:41 ` Dave Horsfall
2018-09-04  2:47   ` Jeffrey H. Johnson
2018-09-02 21:47 Doug McIlroy
2018-09-03  6:18 ` arnold
     [not found] <5B48F6A3-374A-4579-AE8F-35BD328D07F9@reagan.com>
2018-09-02  3:17 ` Jeffrey H. Johnson
2018-09-01 23:33 Noel Chiappa
2018-09-01 23:44 ` jcs
2018-09-01 20:31 Will Senn
2018-09-01 21:27 ` jcs
2018-09-01 23:24   ` John P. Linderman
2018-09-02 13:06     ` Dave Horsfall
2018-09-02 16:23       ` Charles Anthony
2018-09-02 18:18       ` Paul Winalski
2018-09-02 19:09         ` Paul Winalski
2018-09-02  0:57   ` Dan Cross
2018-09-02  2:06     ` Grant Taylor via TUHS
2018-09-02  2:32   ` Charles Anthony
2018-09-02  2:52     ` Larry McVoy

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=0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com \
    --to=trnsz@pobox.com \
    --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).