[TUHS] Public access multics

Will Senn will.senn at gmail.com
Mon Sep 3 08:30:25 AEST 2018


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



More information about the TUHS mailing list