From: jmfbahciv on
George Neuner wrote:
> On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv <jmfbahciv(a)aol> wrote:
>
>> George Neuner wrote:
>>
>>> Leaving aside why anyone would _want_ to bring back Multics ...
>> To study how to make an OS secure from the beginning project plan
>> to the last edit for shipping?
>
> Ok, but there are other secure systems to study such as Amoeba and
> EROS. They are more modern than Multics, and in particular, were
> designed to be distributed.
>
> I don't mind anyone studying Multic - there is plenty to learn from it
> (including what not to do) ... but I would be against trying to revive
> it as a working operating system.
>
There is nothing, I repeat NOTHING, more instructive than working
on a functional system. It's a computer biz law that, what you
expect to happen, will not happen; the corollary is that the
opposite of what you expect to happen will happen. Only
those who have done OS development for many releases will
understand this one.

ARe you really sure that MULTICs doesn't have old tricks
which have to be relearned and reimplemented again? I'm
not. I'm sure of the opposite.


/BAH
From: Anne & Lynn Wheeler on

George Neuner <gneuner2(a)comcast.net> writes:
> Ok, but there are other secure systems to study such as Amoeba and
> EROS. They are more modern than Multics, and in particular, were
> designed to be distributed.
>
> I don't mind anyone studying Multic - there is plenty to learn from it
> (including what not to do) ... but I would be against trying to revive
> it as a working operating system.

as an aside ... some of the ctss people went to 5th flr, 545 tech sq to
do multics and others went to the science center on the 4th flr and did
(virtual machine) cp40 (on special modified 360/40 with virtual memory
hardware) which morphed into cp67 (when standard virtual memory 360/67
became available) and then morphed into vm370.
http://www.garlic.com/~lynn/subtopic.html#545tech

Old reference to Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

multics page
http://www.multicians.org/multics.html

old post in multics news group (AFDS was Multics installation)
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia

with respect to cp67 ... there seemed to have been a lot of these guys
.... but I didn't become aware of them until much later:
http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

I did assurance panel discussion at 2001 IDF in tcpa track ...
http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13
with their technical director
http://web.archive.org/web/20011106111653/www.intel94.com/idf/spr2001/speakerdescriptions.asp?id=bsnow

Coyotos is successor to EROS ... EROS was based on tymshare's (370)
gnosis capability operating system ... which was spun off as keykos when
m/d bought tymshare (I was brought in to do gnosis audit/review as part
of the spin-off).
http://en.wikipedia.org/wiki/Coyotos

There were also some number of "object" operating system efforts
.... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink
technology went to Taligent ... and (possibly) some of SPRING/DOE shows
up in java (and java virtual machine)

Recent reference about being asked about coming in to head up
commercialization of SPRING/DOE for shipping as product
http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing

misc. past posts mentioning gnosis, keykos, eros, coyotos
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#7 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#43 Secure design
http://www.garlic.com/~lynn/2005d.html#50 Secure design
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
http://www.garlic.com/~lynn/2005s.html#12 Flat Query
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#34 PDP-1
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007o.html#25 LAX IT failure: leaps of faith don't work
http://www.garlic.com/~lynn/2007s.html#17 Oddly good news week: Google announces a Caps library for Javascript
http://www.garlic.com/~lynn/2008b.html#24 folklore indeed
http://www.garlic.com/~lynn/2008b.html#50 How does ATTACH pass address of ECB to child?
http://www.garlic.com/~lynn/2008e.html#12 Kernels
http://www.garlic.com/~lynn/2008g.html#7 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008g.html#23 Doug Engelbart's "Mother of All Demos"
http://www.garlic.com/~lynn/2008h.html#14 Two views of Microkernels (Re: Kernels
http://www.garlic.com/~lynn/2008s.html#3 New machine code
http://www.garlic.com/~lynn/2009b.html#4 Possibility of malicious CPUs
http://www.garlic.com/~lynn/2009f.html#28 Opinion: The top 10 operating system stinkers
http://www.garlic.com/~lynn/2010d.html#84 Adventure - Or Colossal Cave Adventure

--
42yrs virtualization experience (since Jan68), online at home since Mar1970
From: nmm1 on
In article <hosqpu41t4u(a)news7.newsguy.com>, jmfbahciv <jmfbahciv(a)aol> wrote:
>>
>There is nothing, I repeat NOTHING, more instructive than working
>on a functional system. It's a computer biz law that, what you
>expect to happen, will not happen; the corollary is that the
>opposite of what you expect to happen will happen. Only
>those who have done OS development for many releases will
>understand this one.

Not at all. I have never done that, but I have done such things
as implement fully-functional language run-time systems (including
exception handling, non-trivial I/O and associated recovery).
I am VERY familiar with that principle, and it holds true even
after 40+ years experience ....

>ARe you really sure that MULTICs doesn't have old tricks
>which have to be relearned and reimplemented again? I'm
>not. I'm sure of the opposite.

I don't object to people reinventing the wheel, but I do wish they
would get the number of sides right!

That is especially true as people attempt to use Unix derivatives
(including Microsoft ones, of course) for servers. Mainframes had
lots of defects, but avoided many of the current ones.


Regards,
Nick Maclaren.
From: George Neuner on
On Tue, 30 Mar 2010 10:13:07 -0400, Anne & Lynn Wheeler
<lynn(a)garlic.com> wrote:

>
>George Neuner <gneuner2(a)comcast.net> writes:
>> Ok, but there are other secure systems to study such as Amoeba and
>> EROS. They are more modern than Multics, and in particular, were
>> designed to be distributed.
>>
>> I don't mind anyone studying Multic - there is plenty to learn from it
>> (including what not to do) ... but I would be against trying to revive
>> it as a working operating system.
>
>as an aside ... some of the ctss people went to 5th flr, 545 tech sq to
>do multics and others went to the science center on the 4th flr and did
>(virtual machine) cp40 (on special modified 360/40 with virtual memory
>hardware) which morphed into cp67 (when standard virtual memory 360/67
>became available) and then morphed into vm370.
>http://www.garlic.com/~lynn/subtopic.html#545tech

Yup. Multics did a lot of things first and got quite a bit of it
right. Internally, at least, Multics was quite nice. However, the
security API was not fun to work with and the user experience could be
unpleasant at times. I personally did not use Multics extensively,
but I know people who did and many of them disliked it - as I did.

Of course, I also disliked using VMS ... so I'm probably going to be
cast out 8) I quite enjoyed programming VAXen, but I was much happier
using Unix than VMS.


>Coyotos is successor to EROS ... EROS was based on tymshare's (370)
>gnosis capability operating system ... which was spun off as keykos when
>m/d bought tymshare (I was brought in to do gnosis audit/review as part
>of the spin-off).
>http://en.wikipedia.org/wiki/Coyotos

Coyotos seems still to be a research project. CapROS, though is a
commercial spin off of EROS. http://www.capros.org/


>There were also some number of "object" operating system efforts
>... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink
>technology went to Taligent ... and (possibly) some of SPRING/DOE shows
>up in java (and java virtual machine)

Pink wasn't designed with security in mind (Apple was still thinking
single user) and it never really materialized anyway. Taligent's OS
was more focused on being reliable than being secure.

EROS (and follow-ons) and Amoeba were designed from the ground up as
capability based secure operating systems.

George
From: Anne & Lynn Wheeler on

George Neuner <gneuner2(a)comcast.net> writes:
> Pink wasn't designed with security in mind (Apple was still thinking
> single user) and it never really materialized anyway. Taligent's OS
> was more focused on being reliable than being secure.

re:
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later

I did a one week JAD with taligent (there were dozen or so top taligent
people in the session and their JAD person) going over what would be
required for business critical (both reliable and secure).

the net was approx. 30% hit to the taligent base ... two new frameworks
plus hits to the existing frameworks.

However, I believe the taligent security guru was on business trip that
week ... visiting some gov. agency on the east coast.

misc. past posts referencing the taligent JAD:
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2007m.html#36 Future of System/360 architecture?
http://www.garlic.com/~lynn/2008b.html#22 folklore indeed
http://www.garlic.com/~lynn/2009m.html#26 comp.arch has made itself a sitting duck for spam

--
42yrs virtualization experience (since Jan68), online at home since Mar1970