multics@clotho.acm.rpi.edu (Richard Shetron) (08/30/90)
Whats the current status of the Multics hardware and software? I used to be a Multics analyst for HIS about 10 years ago and I've been thinking of working on a version for the 386 chip. I figure other people may be of similier mind and figured I'd ask here. I've heard that HIS is/has canceled Multics. Is there any old pre HIS versions that might be public domain from the project MAC days? Thanks A good bureaucracy is the best tool of oppression ever invented. Richard Shetron USERFXLG@rpi.mts.edu multics@clotho.acm.rpi.edu
barmar@think.com (Barry Margolin) (08/30/90)
In article <R6=%L%=@rpi.edu> multics@MTS.RPI.EDU (Richard Shetron) writes: >Whats the current status of the Multics hardware and software? I used to be >a Multics analyst for HIS about 10 years ago and I've been thinking of >working on a version for the 386 chip. I figure other people may be of >similier mind and figured I'd ask here. I've heard that HIS is/has canceled >Multics. Is there any old pre HIS versions that might be public domain from >the project MAC days? Honeywell Information Systems (now Bull HN Worldwide Information Systems, or just Bull) capped Multics development about five years ago. There's still a small group of developers in Phoenix supporting the system for existing customers, but it's no longer being marketed. Efforts in the past by third parties to get the rights to Multics source code in order to port and market it on other hardware have failed miserably. There never has been a public domain version; at the time of its conception it was a joint project with GE and Bell Labs, and presumably had joint copyright. I've seen and heard of Multics clones running on the 386. I once saw a friend using MicroPrimos on a portable Compaq, and it looked externally like Multics (but I don't know whether it did dynamic linking and all the other neat Multics stuff). And Richard Soley, formerly of AI Associates, told me that he implemented a Multics clone for the 386, I think as part of the HummingBoard project (a Lisp accelerator for Golden Common Lisp). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
fetter@cos.com (Bob Fetter) (08/31/90)
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-wos@Oxford.COM (Olin Sibert) (09/03/90)
I don't normally read this newsgroup, but a colleague forwarded me this discussion, so I thought I'd say a bit [more than I ought to, perhaps]. In article <R6=%L%=@rpi.edu> [Boy, is *that* a weird message-ID], multics@MTS.RPI.EDU (Richard Shetron) asks: > Whats the current status of the Multics hardware and software? Alas. It's dead. It is an ex-parrot. There's a handful of installations (in the U.S., Canada, England, and France) still struggling with the question "Gosh, what could we possibly migrate to after having used the best operating system in the world for so many years?" -- and I can understand their consternation. I'm not sure what the numbers are now, but at one time (late 1985) there were about 70 sites (65 customers, 85-90 systems). Indeed, I use one of the remaining systems nearly every working day, but it seems more of a dinosaur each time. Multics is still "supported", in one sense of the word: a spin-off from the University of Calgary, the Advanced Computing Technology Corporation, has a contract with Bull HN Information Systems, Inc. (nee Honeywell Bull, nee Honeywell Information Systems, hereinafter HoneyBull) to do what little software work that the customers require (things like occasional crash analysis, trivial software enhancements, and the like), but there's no real development. In fact, there's no longer even the "small group of developers in Phoenix"--it's all in Calgary now. The big Multics system in Phoenix ("System-M") remains, and Frank Martinson still runs it, though I don't know how long it will stay in operation. > I've heard that HIS is/has canceled Multics. Yes, indeed: in July, 1985, they sent a letter to customers announcing that the (long-anticipated) new hardware had been cancelled, and that the software would be in maintenance mode immediately, and no longer supported at all after July 1990. Various customers, in rough proportion to their size and/or desperation, quickly negotiated support contracts to help them through migration--but I think even those mostly run out in 1995 (which no longer seems that far away). There had been no significant new Multics hardware designed since the late 1970s, and though it still worked pretty well, it was nearing the end of its design life even then. > I've been thinking of working on a version for the 386 chip. There's a lot to Multics. About 2 - 2.5 million lines, as I recall. It's also written in Full (nearly-)ANSI PL/I, which qualifies as a pretty dead language these days. Although there are lots of PL/I subsets for small machines, and I believe even a few for the 386, the full language awfully complicated, and is heavily used by Multics. Then, of course, there's the 36-bit problem: Multics code is well aware that it lives in a world with 36-bit words, 9-bit bytes and, 18-bit address offsets, and would be pretty tough to convert to 32 and 8. A toy Multics would be easier--I'll bet a lot of the commands could be ported to UNIX pretty easily, along with the command processor itself (it'd be easiest, I think, as a complete transliteration to C). But what's the point? Multics is an integrated environment, and the rough edges would quickly appear. > Is there any old pre HIS versions that might be public domain from > the project MAC days? As Barry says, there never was a public domain version. In theory, MIT holds the sole copyright to the 1972 version, but that's *really* old (pre-6180), and the theory has not been tested recently. In the 1970s, MIT did give Control Data a license to that version, but nothing was ever heard after that. Who knows? Maybe it made some meaningful contribution to NOS/VE, another operating system that now seems on the skids (that's also a great shame--the Cyber 180 hardware is also quite well-suited to a Multics-style operating system). And, in article <35771@cos.com>, fetter@cos.com (Bob Fetter) adds: > 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'm he; there were, and it did. Your rumour mill is pretty close to the mark (and spells my name correctly, too, thanks). There were two attempts to rescue Multics, one by me in late 1985-86, and one by Michael Tague about a year later. I planned new 36-bit hardware (closely based on what HIS had been developing, but cancelled), followed by a transition to Intel architecture. Michael, being later, planned to transition directly. HoneyBull didn't much want to talk to me at the outset, and never really warmed to my proposal. They finally told me, with great vigor, to go away and darken their doorstep never more. All in all, I was grateful that I didn't have to hire a lawyer, and relieved that the attempt only wasted about a year. Michael had better luck initially, but also got the shaft in the end. I've since concluded that Multics would have been a good short term business (4-8 years), but probably doomed in the long run. I'd like to credit HoneyBull with that same vision, but I think it was more that they couldn't figure out how they'd deal with it whether it succeeded or not. They clearly wanted to get out of the computer business in the worst way, and most would agree that they have. They just weren't looking for new and risky opportunities to make money in computers. > Multics, in and of itself, was a rather holistically based system, > but the model it used has been left behind. Indeed, and this is why I think a Multics business would have been ultimately unsuccessful. There's a lot in Multics that still isn't matched, even in research systems like Mach. On the other hand, there's a lot of new technology out there that's extremely useful and appropriate, but simply couldn't be incorporated into the Multics model no matter how big a crowbar one used. I also haven't seen any system that approaches Multics for its internal consistency and integration, which I believe to be the result of a close-knit development community working together, not for years, but for decades. That, too, would be extremely hard to do in today's marketplace--a lot of things were easier when computers stood seven feet tall and fifty units a year was respectable volume. It sure would be nice to see, today, another broad-based effort like Multics to advance the state of the art in all areas of computer technology. It's been 25 years since the last one, so maybe it's about time. Today's nine hundred and seventeen research projects to make a (slightly) better UNIX certainly don't qualify. Anyway, thanks for asking. --------------------------------- Olin Sibert, Oxford Systems, Inc. Sibert@Oxford.COM uunet!oxford!sibert -- W. Olin Sibert |Internet: Sibert@Oxford.COM Oxford Systems, Inc. |UUCP: uunet!oxford!sibert
ellard@bbn.com (Dan Ellard) (09/04/90)
It seems like no discussion of Operating Systems can occur without someone mentioning Multics and how gracefully it solved problems which still plague other OS's twenty five years later. From what I have heard, it certainly sounds like an interesting system, and one that I should learn more about. Can anyone point me towards a source for Multics documentation? And perhaps more importantly, is there anyone out there who has a internet-accessible Multics system who would be willing to give me a guest account? Thanks in advance, Dan
haynes@ucscc.UCSC.EDU (99700000) (09/05/90)
In article <1990Sep3.155823.13261@Oxford.COM> Sibert@Oxford.COM (Olin Sibert) writes: >I've since concluded that Multics would have been a good short term >business (4-8 years), but probably doomed in the long run. I'd like to > > > Multics, in and of itself, was a rather holistically based system, > > but the model it used has been left behind. > >Indeed, and this is why I think a Multics business would have been >ultimately unsuccessful. There's a lot in Multics that still isn't Yeah, seems to me that Multics as we know it is rather rooted in the "computing utility" concept of the 60s that has been completely obsoleted by microcomputers. That's the "business end" of those 2.5 million lines of PL/I code. Now the way it looks to the individual user is something else again; that's what we want to mine for good ideas and transfer them to modern platforms. But there's no future in building humongous machines to be time-shared among many users as a way of getting the cost of computing down. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (09/05/90)
In article <6579@darkstar.ucsc.edu> haynes@ucscc.UCSC.EDU.UUCP (Jim Haynes) writes: > But there's no future in >building humongous machines to be time-shared among many users as a >way of getting the cost of computing down. But there is a future in building humongous distributed machines to be time-shared among many users. See Plan 9 and Amoeba. You don't have stick a fast CPU on every desk when it won't be used most of the time and will have awful disk I/O when it is used. -- "Perhaps I'm commenting a bit cynically, but I think I'm qualified to." - Dan Bernstein
fetter@cos.com (Bob Fetter) (09/06/90)
In article <6579@darkstar.ucsc.edu> haynes@ucscc.UCSC.EDU.UUCP (Jim Haynes) writes: >In article <1990Sep3.155823.13261@Oxford.COM> Sibert@Oxford.COM (Olin Sibert) writes: >>I've since concluded that Multics would have been a good short term >>business (4-8 years), but probably doomed in the long run. I'd like to >> >> > Multics, in and of itself, was a rather holistically based system, >> > but the model it used has been left behind. >> >>Indeed, and this is why I think a Multics business would have been >>ultimately unsuccessful. There's a lot in Multics that still isn't > >Yeah, seems to me that Multics as we know it is rather rooted in the >"computing utility" concept of the 60s that has been completely >obsoleted by microcomputers. That's the "business end" of those >2.5 million lines of PL/I code. Now the way it looks to the individual >user is something else again; that's what we want to mine for good >ideas and transfer them to modern platforms. But there's no future in >building humongous machines to be time-shared among many users as a >way of getting the cost of computing down. Well, Multics == "MULTIplexed Information and Computing Service", but there, I think, is where your assertion stops. There never was any intrinsic reason that Multics was a "humongous machine" -- it was built as a general-purpose system. Yes, it was built as a "time sharing" system, but then what multitasking workstation today isn't a "time sharing" system. As regards the "2.5 million lines of PL/I code", take a real close look at Unix SysV or BSD 4.3 -- you will see at least 2 million+ lines of code if you include networking (which the 2.5 above includes). This is really not a big point in categorizing operating systems.... In that the concept of a "computing utility" being obsoleted by microcomputers, I submit the existence of CompuServe, Prodigy, and tens of thousands of bulletin board systems throughout the world refutes that point. Microcomputers have been a great boon to the world, but they have let us isolate ourselves in a new and insinuous way. Regarding "how it looks to the individual user", I defy anyone to present a user environment (both end-user and programmer-user) which is as consistent and as **malleable** as the Multics environment is/was. A Multics use would -->know<-- that "-brief" would be an acceptable argument to virtually ANY command to which the user would wish to get "just the facts, ma'am". In the same guise, "-long" would give the total and complete case. This was not the only example. For the progammer, the canonical control over I/O management *on the application level* gave one an incredible degree of freedom. I must be blunt on this point--Unix I/O redirection is but a shadow of what capabilities are possible. Yes, the Unix shell environment gives one a cleaner interface to this capability than the standard Multics command_processor_ did, but that's because people developed "a better way to use", not that the system itself was lacking in *providing*. In closing, the problem of "getting the cost of computing down" has not been solved by the systems currently in existance. In particular, today's "modern platforms" do not address the dynamic relocation *regardless of the mode or method of program implementation* of multiple threads of execution across the realm of 1) multiple processor (tightly or otherwise) coupled cpus ** and in a transparent and invisible manner ** 2) networked and/or otherwise co-operative cpus This does not mean that Multics solved 2) above. But, then, nothing else to-date does either. It does/did deal with 1) above as well (if not better) than anything else in commercial existance today... What we *do* have, regardless, is a homogenized environment in which Unix (or Unix work-alikes) predominate. Whether this is "a good thing" is indeed the the basis of this thread. >haynes@ucscc.ucsc.edu >haynes@ucscc.bitnet >..ucbvax!ucscc!haynes > >"Any clod can have the facts, but having opinions is an Art." > Charles McCabe, San Francisco Chronicle