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
> 

Re: [TUHS] Public access multics

[Doug McIlroy]

> Was Algol 60 any kind of viable alternative at the time?

The operating system for the Burroughs B5000 had been written in
Burroughs Algol. That punctured the widespread belief that OS's
were so particular to the hardware that they had to be written
in machine language. I don't recall how far Burroughs Algol
went beyond Algol 60, nor why Multics did not want to follow
that lead.  ("Viable" is a slippery concept when choosing
among Turing-complete alternatives.)

Doug

Re: [TUHS] Public access multics

[Dave Horsfall]

On Mon, 3 Sep 2018, Doug McIlroy wrote:

>> Was Algol 60 any kind of viable alternative at the time?
>
> The operating system for the Burroughs B5000 had been written in 
> Burroughs Algol. That punctured the widespread belief that OS's were so 
> particular to the hardware that they had to be written in machine 
> language. I don't recall how far Burroughs Algol went beyond Algol 60, 
> nor why Multics did not want to follow that lead.  ("Viable" is a 
> slippery concept when choosing among Turing-complete alternatives.)

Call me memory-challenged (which I am these days), but wasn't Burroughs' 
OS known as Master Control Program (MCP - Male Chauvinist Pig)?

-- Dave, who has fond memories of the B1500...

Re: [TUHS] Public access multics

[Jeffrey H. Johnson]

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

Yes, correct - I don't want to bring the list too off-topic, but Unisys (UNIVAC + Burroughs) still maintains those two platforms (OS 2000 from the UNIVAC line and MCP from Burroughs), and they have a hobbyist program for both systems.

https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-os-2200-software/clearpath-os-2200-express

and

https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-mcp-software/clearpath-mcp-express

Unisys has also released older versions of MCP (1970s) as well with less restrictive licensing, and the community has built an emulator capable of running them on an emulated B5500 system - http://www.phkimpel.us/B5500/

The Burroughs MCP name supposedly inspired the MCP villain in TRON as well. 

I've never used Burroughs Algol nor Honeywell Algol, but I am aware you can use Honeywell Algol on Multics via gcos_tss (the GCOS Time Sharing Simulator).

-- Jeff

> On Sep 3, 2018, at 7:41 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Mon, 3 Sep 2018, Doug McIlroy wrote:
> 
>>> Was Algol 60 any kind of viable alternative at the time?
>> 
>> The operating system for the Burroughs B5000 had been written in Burroughs Algol. That punctured the widespread belief that OS's were so particular to the hardware that they had to be written in machine language. I don't recall how far Burroughs Algol went beyond Algol 60, nor why Multics did not want to follow that lead.  ("Viable" is a slippery concept when choosing among Turing-complete alternatives.)
> 
> Call me memory-challenged (which I am these days), but wasn't Burroughs' OS known as Master Control Program (MCP - Male Chauvinist Pig)?
> 
> -- Dave, who has fond memories of the B1500...

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

Re: [TUHS] Public access multics

[Doug McIlroy]

Caveat: As a member of the PL/I committee, and the person who brought
the new and unimplemented language to the attention of Multics, let a
disastrous contract for a compiler, and finally helped cobble together
a rudimentary compiler that got the project off the ground, I am not
exactly an unbiased observer.

A ground tenet of Multics was that it would be programmed in a higher
level language. A subsidiary requirement, which was generally agreed
upon, was language-level access to the logical operators and address
manipulation inherent in the hardware.  No widely used language of the
time met this requirement.  And they didn't want to get sidetracked into
language design.

Discussions finally boiled down to AED, developed at MIT by Doug Ross, and
PL/I. Ross was a brilliant software innovator with a mystical outlook that
made it difficult to distinguish his vision of what could be done from
what actually existed. AED was definitely a moving target. By contrast
PL/I had a written spec, so you knew exactly what could be done in it,
though not how well the compiler would do it.

PL/I  was very big; we deliberately (and explicitly) omitted about
half the spec. The remainder was definitely seen as a "plausible
systems programming language".

From the perspective of the time, why do you think the contrary?

Doug

Re: [TUHS] Public access multics

[arnold]

Was Algol 60 any kind of viable alternative at the time? IIRC
manufacturers in Europe were using it for systems programming.
(This is all before my time, so I could be wrong, which is why
I'm curious.)  In the US Burroughs used Algol, but that may have
been later than the mid-60s timeframe of Multics.

Thanks,

Arnold

Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> Caveat: As a member of the PL/I committee, and the person who brought
> the new and unimplemented language to the attention of Multics, let a
> disastrous contract for a compiler, and finally helped cobble together
> a rudimentary compiler that got the project off the ground, I am not
> exactly an unbiased observer.
>
> A ground tenet of Multics was that it would be programmed in a higher
> level language. A subsidiary requirement, which was generally agreed
> upon, was language-level access to the logical operators and address
> manipulation inherent in the hardware.  No widely used language of the
> time met this requirement.  And they didn't want to get sidetracked into
> language design.
>
> Discussions finally boiled down to AED, developed at MIT by Doug Ross, and
> PL/I. Ross was a brilliant software innovator with a mystical outlook that
> made it difficult to distinguish his vision of what could be done from
> what actually existed. AED was definitely a moving target. By contrast
> PL/I had a written spec, so you knew exactly what could be done in it,
> though not how well the compiler would do it.
>
> PL/I  was very big; we deliberately (and explicitly) omitted about
> half the spec. The remainder was definitely seen as a "plausible
> systems programming language".
>
> From the perspective of the time, why do you think the contrary?
>
> Doug

Re: [TUHS] Public access multics

[Jeffrey H. Johnson]

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

Greetings,

Multics, while not a 'massive' sales success in retrospect, was certainly not the failure commonly believed and wasn't treated as one in the press of the time - at least not until after the decision was made by Honeywell-Bull to phase out the the Multics (and CP-6) products to focus on GCOS - GCOS7/GCOS8 is still a major player today.

"Honeywell is having considerable — and surprising — success with the ultra-secure Multics operating system … Besides 3-5 systems within Honeywell, Multics has been installed or committed within Nippon Electric, Rome Air Development Center, USAF Data Services Center, and Ford." from mid-1970's industry press.

See also https://multicians.org/myths.html

We have about 120 members on BAN - including many original and new Multicians who make the project possible. We're always working on new things and projects - see "pmotd -a" when logged in for some of the most recent activity.

I'd be happy to answer any questions on BAN.AI if anyone has particular questions - or just ssh to dps8@m.trnsz.com - feel free to use the guest account. I don't want to take the list too off-topic. We have many exclusive features that I hope makes BAN.AI a 'special' (and loved) system, a lot more coming.


--
https://ban.ai/multics

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

Re: [TUHS] Public access multics

[Noel Chiappa]

    > From: jcs

    > The real mystery is what it's running on. ... It's=20 probably a
    > simulator but I've never heard of one for the H6000.

Per:

  https://multicians.org/multics.htmlhttps://multicians.org/multics.html

"Harry Reed and Charles Anthony reached a major milestone on the Multics
simulator on Saturday 08 November, 2014. Their SIMH-based simulator booted
Multics MR 12.5, came to operator command level, entered admin mode, created a
small PL/I program, compiled and executed it, and shut down. Release 1.0 of
the simulator is now available."

    Noel

Re: [TUHS] Public access multics

[jcs]

Noel Chiappa <jnc@mercury.lcs.mit.edu> writes:

> Per:
>
>   https://multicians.org/multics.htmlhttps://multicians.org/multics.html
>
> "Harry Reed and Charles Anthony reached a major milestone on the 
> Multics
> simulator on Saturday 08 November, 2014. Their SIMH-based 
> simulator booted
> Multics MR 12.5, came to operator command level, entered admin 
> mode, created a
> small PL/I program, compiled and executed it, and shut down. 
> Release 1.0 of
> the simulator is now available."

Hmmm. That's interesting. Back in the 70's I earned my living 
working on H6000s (although not on Multics). I'm pretty sure that 
no one would have bothered with a simulator if not for Multics so 
that's another reason not to dismiss Multics as a failure: 
someone, today, still cares enough to write a simulator just to 
run it.

[TUHS] Public access multics

[Will Senn]

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

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

Will



Sent from my iPhone

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

Re: [TUHS] Public access multics

[jcs]

Will Senn <will.senn@gmail.com> writes:

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

Failed only in the sense that the Labs withdrew from the project. 
Honeywell, which bought out GE's computer division, sold Multics 
systems, although I don't remember them being very successful.

The real mystery is what it's running on. Multics originally ran 
on the GE/H 600(0) systems. I doubt any are still around. It's 
probably a simulator but I've never heard of one for the H6000.

Re: [TUHS] Public access multics

[John P. Linderman]

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

I was at MIT in the late 60's, using Multics when Bell Labs decided to pull
out. A problem, in retrospect, was the use of PL/I as the primary language.
PL/I was a language designed by a committee, and it showed. It would never
have made a plausible systems programming language. But Multics was a lot
more fun to use than CTSS, which it replaced.

On Sat, Sep 1, 2018 at 5:27 PM, jcs <lists@irreal.org> wrote:

>
> Will Senn <will.senn@gmail.com> writes:
>
> 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 :)
>>
>
> Failed only in the sense that the Labs withdrew from the project.
> Honeywell, which bought out GE's computer division, sold Multics systems,
> although I don't remember them being very successful.
>
> The real mystery is what it's running on. Multics originally ran on the
> GE/H 600(0) systems. I doubt any are still around. It's probably a
> simulator but I've never heard of one for the H6000.
>

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

Re: [TUHS] Public access multics

[Dave Horsfall]

On Sat, 1 Sep 2018, John P. Linderman wrote:

> PL/I was a language designed by a committee, and it showed. [...]

I have never seen a full-blown PL/I compiler (only subsets), and I recall 
being told that there never will be one because it is simply impossible, 
given the spec.

Naturally I am happy to be proven wrong on this.

-- Dave

Re: [TUHS] Public access multics

[Charles Anthony]

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

On Sun, Sep 2, 2018 at 6:07 AM Dave Horsfall <dave@horsfall.org> wrote:

> On Sat, 1 Sep 2018, John P. Linderman wrote:
>
> > PL/I was a language designed by a committee, and it showed. [...]
>
> I have never seen a full-blown PL/I compiler (only subsets), and I recall
> being told that there never will be one because it is simply impossible,
> given the spec.
>
> Naturally I am happy to be proven wrong on this.
>
>
AM83 Multics PL1 Reference Manual, pg 1-1: "Multics PL/I is closely related
to American National Standards Programming Language PL/I. ... ANSI
X3.53-1976... For a complete description of the differences between Multics
PL/I and Standard PL/I, see Appendix A of the PL/I Language Specification."

Appendix A, pp A-1 to A-4:
https://drive.google.com/open?id=12wRW7vgCVTP4bL7942YiEEUQc2J9bWes
https://drive.google.com/open?id=1McndftW6HPioowfIAmL1P8WhabpvYeWg
https://drive.google.com/open?id=1XJdaj8YGHTERjTu9xq3KEM0nAGiAFm2M
https://drive.google.com/open?id=18VdXROFQmkm_9zL1XLHZCeOxiPLmWDMD

-- Charles



-- Dave
>

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

Re: [TUHS] Public access multics

[Paul Winalski]

On 9/2/18, Dave Horsfall <dave@horsfall.org> wrote:
>
> I have never seen a full-blown PL/I compiler (only subsets), and I recall
> being told that there never will be one because it is simply impossible,
> given the spec.
>
> Naturally I am happy to be proven wrong on this.

IBM had PL/I compilers for TOS, DOS, and OS on System/360, and for
DOS/VS and OS/VS on System/370.  If those weren't full implementations
of the original spec, they were pretty close.

IBM PL/I had a good number of what I call toxic language features,
such as the DEFAULT statement (which was Fortran's IMPLICIT on
steroids).  Most PL/I shops had as part of their coding standards a
set of language features banned from the code.  The ANSI standard
eliminated a lot of these, although it also threw out some useful
features such as iSUB defining and by-name structure assignment.

One of my favourite features was sterling pictures, with pounds,
shillings, and pence fields (represented internally as a packed
decimal value in pence).  Sterling pictures weren't finally deprecated
in the IBM PL/I compilers until 1979, IIRC.

-Paul W,.

Re: [TUHS] Public access multics

[Paul Winalski]

On 9/2/18, Paul Winalski <paul.winalski@gmail.com> wrote:
>
> IBM had PL/I compilers for TOS, DOS, and OS on System/360, and for
> DOS/VS and OS/VS on System/370.  If those weren't full implementations
> of the original spec, they were pretty close.

TOS, DOS, and DOS/VS PL/I didn't implement PL/I's multitasking
features (such as TASKs and EVENTs) because those OSes had no
multitasking support.

-Paul W.

Re: [TUHS] Public access multics

[Dan Cross]

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

On Sat, Sep 1, 2018 at 6:15 PM jcs <lists@irreal.org> wrote:

> Will Senn <will.senn@gmail.com> writes:
> > 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.
>

Yup. A few Multics sites are publicly accessible; the one at the Living
Computer Museum has a guest account, a few others one can get an account if
one asks the site administrator nicely. Some amount of Multics maintenance
has been restarted.

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

Multics was the immediate predecessor of Unix, and one can certainly see
some of the influence, though of course many of the details are different.

Failed only in the sense that the Labs withdrew from the project.
> Honeywell, which bought out GE's computer division, sold Multics
> systems, although I don't remember them being very successful.
>

The multicians.org site has a lot of good information on Multics and what
ultimately become of it. (jcs probably knows this already; I'm writing this
more for general information of those who may not have been following these
developments.) The TL;DR was that a smallish number of sites eventually
installed Multics and it was a moderate success for Honeywell, but for the
reasons that have been mentioned (failure to market, lack of management
understanding, tied to a decomposing architecture well past its prime) it
never carved out more than a niche.

The real mystery is what it's running on. Multics originally ran
> on the GE/H 600(0) systems. I doubt any are still around. It's
> probably a simulator but I've never heard of one for the H6000.
>

The last working hardware installation was shut down in, I think, 2000. An
DPS8/M emulator has been built on top of the SIMH framework, and is what
folks are running Multics on. Some more details are here:
https://multicians.org/simulator.html.

        - Dan C.

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

Re: [TUHS] Public access multics

[Grant Taylor via TUHS]

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

On 09/01/2018 06:57 PM, Dan Cross wrote:
> Yup. A few Multics sites are publicly accessible; the one at the Living 
> Computer Museum has a guest account, a few others one can get an account 
> if one asks the site administrator nicely. Some amount of Multics 
> maintenance has been restarted.

I was chatting with modern day Multicians within the last week.  They 
were actively working on getting a 3270 interface working for Multics 
running in an emulator.

They are hanging out in the #multics channel on freenode.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] Public access multics

[Charles Anthony]

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

>
>
>
> The real mystery is what it's running on. Multics originally ran
> on the GE/H 600(0) systems. I doubt any are still around. It's
> probably a simulator but I've never heard of one for the H6000.
>

A simulator. Originally running Multics release 12.5, but a dedicated team
of new and original Multicians have completed the Y2K transition, fixed
some bugs and added some features, so now running release 12.6f.

All of the original systems are believed to be destroyed with the exception
of DOCKMASTER (an NSA machine), now in possession of the National
Cryptographic Museum, but warehoused.

A video of the Living Computer Museum's Multics emulator (with maintenance
panel) booting: https://www.youtube.com/watch?v=jni7wk7bjxA

At least one of the new Multicians (me) is subscribed to TUHS.

-- Charles

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

Re: [TUHS] Public access multics

[Larry McVoy]

On Sat, Sep 01, 2018 at 07:32:53PM -0700, Charles Anthony wrote:
> At least one of the new Multicians (me) is subscribed to TUHS.

Welcome.  You'll find this list to be pleasant, it's mostly Unix but
we've got Ted from Linux (which is a big deal, he has a lot of history
in his head and is a good guy), Ken is on here though he rarely posts
(and we all try and be nice to keep him around), Doug is here, Steve is
here, and all of us wannabes are here.

I love being on this list, as a young dude I was pretty unhappy that I 
was born at the wrong time, I really really wanted be part of Bell Labs.
But I got to be part of Sun, which I think was the Bell Labs of their
time.  And then there is this list which has some of the Bell Labs folks.

It reminds me of the Band, there is a video and Neil Young says "it's
one of the pleasures of my life to be on stage with these people".  
Yeah, it's one of the great pleasures of my life to be able to talk
the Bell Labs people on this list.  And other fans of the Unix history,
love this list.

https://www.youtube.com/watch?v=J2z7LXpAX3Q