Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sundc!hadron!cos!fetter
From: fetter@cos.com (Bob Fetter)
Newsgroups: comp.os.misc
Subject: Re: Multics - Whats the current status?
Keywords: Multics
Message-ID: <35771@cos.com>
Date: 31 Aug 90 03:56:22 GMT
References: <R6=%L%=@rpi.edu>
Reply-To: fetter@cos.UUCP (Bob Fetter)
Distribution: na
Organization: Corporation for Open Systems, McLean, VA
Lines: 54


Indeed.  Just before the sale of Honeywell Information Systems back in
1987, Honeywell Corporate canceled ("end-gamed") Multics.  I don't
know the status of the system, however.  MIT has (had?) rights on some
of the system, and I don't know what Bull HN still retains.  I
remember some "discussions" regarding one Mssr. (Olin?) Sibert and a
request by him to buy access to Multics for purposes of porting to the
286/386 back in the middle-late 80's.  Last I remember, the deal fell
through ... more from a political/marketing standpoint than from a
technical one, if the rumor mill fed me correctly.

  I myself would be interested in something of this nature, IF the
rights and/or capability to aquire access to the technology were
possible.  Not so much as to "reincarnate" Multics, but to work from
that base to augment/"add value" to what today is the 'current base of
technology' (read: Unix/POSIX/Mach).  Multics, in and of itself, was a
rather holistically based system, but the model it used has been left
behind.  There were more than a few problems with memory management
(object sizes, etc.), hardware dependencies (not at first, but
creeping dependency syndrome), and language bias (things other than
pl1 or alm were but accommodated, not 'accepted').  

  For example, I'd love to see the infrastructure of Multics dynamic
linking included in a modern Unix system (not these halfway 'dynamic
load library' things), along with a restoration of the unification of
command lines and subroutine calls (I guess today it would be a
unification of the initiation "mechanics" and receiving syntax of
process creation and stack frame allocation/subroutine initiation).
There have been too many times where I've hit the brick wall of having
to bind in *everything* I'd ever *might* need into an 'a.out', and
have every user pay the price of the duplicated disk space, wasted
memory space, etc., for a capabilitity only used once and a while.
Yeah, in Unix one would fork another process, but then you have data
space sharing problems -- hence "special code and unique for the
realization of" lightweight processes, shared segments, writing
RPC-based daemons, etc. hacks.  Like, where is "iox_", Device
Interface Modules, and *application controllable i/o management* now
that I need/want them? (not just at the device driver level, but at
the user process level).

  To try to port Multics to a 386 environment just for the exercise
would be an interesting, but futile, effort.  To try to insert the
Multics approach to consistency, dynamic replacement of
procedures/data references, and a concept of user (read: application
programmer) controllable "firewalling" into the current OS
environments, however, I think has merit.  (But, still, if there was a
Multics on a chip that I could run at my desk/home, given a Unix
encapsulation/subset mode, it would take wild horses to keep me from
having one.)

  I'd be curious if there is anyone from Bull out there who might
comment on the status of Multics technology.

  -Bob-