larry@geowhiz.UUCP (Larry McVoy) (05/23/86)
[muncha buncha cruncha muncha...]
I have heard rumors (from cmu, uci, ucberkeley, and wisc) that research Unix
will no longer be developed at bezerkely after 4.3. I hear that Darpa
support for such development has dried up. I have heard that cmu has a
OS called MACH (???) which runs 4.3 programs faster than 4.3BSD runs them,
and that they may be taking over where berkeley leaves off.
What I want to know is:
1) Why is Unix departing from berkeley? Who initiated the departure, them
or DOD?
2) What's this about MACH? I heard it's based on Accent, but I know nothing
beyond that. Is the claim that 4.3 progs run faster possible?
3) Is the DOD going to support cmu?
4) What about Version 8 Unix? I hear (I know, I know, I hear a lot) that
it is very nice, almost a "clean" version of 4.x. Streams sound very
nice.... Are there any plans to follow in berkeley's footsteps with
a version of unix based on version 8?
5) [This has very little to do with 1-4, I just thought I'd tack it on...]
What about a merger? I work on a Masscomp system which is really pretty
nice: they have this universe stuff in which both 4.2 & SysV system calls
can be supported. Also, both 4.2 and SysV utilities are available, I
very rarely am faced with "I can't do it because I don't have the
widget utility". Is there any chance of the various 4.x utils being
merged into AT&T Unix?
--
Larry McVoy
-----------
Arpa: mcvoy@rsch.wisc.edu
Uucp: {seismo, ihnp4}!uwvax!geowhiz!larry
"Just remember, wherever you go -- there you are."
-Buckaroo Banzaichris@umcp-cs.UUCP (Chris Torek) (05/28/86)
In article <440@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: >I have heard rumors (from cmu, uci, ucberkeley, and wisc) that research Unix >will no longer be developed at bezerkely after 4.3. I hear that Darpa >support for such development has dried up. I have heard that cmu has a >OS called MACH (???) which runs 4.3 programs faster than 4.3BSD runs them, >and that they may be taking over where berkeley leaves off. I have not heard most of this; but as no one else has done so, I will try to answer the questions below. The only thing that I did hear is that DARPA is not funding network development beyond 4.3 (the 4.3 TCP/IP is `done', in someone's opinion, I suppose; and `the gummint' seems to like funding project A for 5 years, then project B elsewhere for another 5 years, then project C at still another place). Please note that everything below is also taken from rumours. I speak only for myself! >What I want to know is: >1) Why is Unix departing from berkeley? Who initiated the departure, them > or DOD? I know nothing about `departing'. Why should a lack of DARPA money for networking stop things? There are many sources of funding. >2) What's this about MACH? I heard it's based on Accent, but I know nothing > beyond that. Is the claim that 4.3 progs run faster possible? Anything is possible; but I doubt that particular claim. (Unless the hardware is faster.) >3) Is the DOD going to support cmu? I do not care to guess who is backing the Software Engineering Institute grants, but CMU already has piles of equipment, and seems to be doing well in the research grant area too . . . . >4) What about Version 8 Unix? I hear (I know, I know, I hear a lot) that > it is very nice, almost a "clean" version of 4.x. Streams sound very > nice.... Are there any plans to follow in berkeley's footsteps with > a version of unix based on version 8? AT&T has, so far, released it only to a few universities. And I hear that they intend to sell it as part of System V release N (N likely tending towards infinity :-) ). >5) [This has very little to do with 1-4, I just thought I'd tack it on...] > What about a merger? Berkeley would love to distribute lots of System V goodies. The problem is licensing. Talk to the lawyers. (This last is a pretty solid rumour.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
henry@utzoo.UUCP (Henry Spencer) (06/06/86)
Nah, 4BSD isn't dead, it just smells that way... :-) > 1) Why is Unix departing from berkeley? Who initiated the departure... I have no idea whether the rumor is true, but if it is... why should Unix STAY at Berkeley? Universities are not software houses (it has been said, not altogether untruthfully, that 4.2BSD is a bunch of M.Sc. theses loosely stitched together). If they lose interest and/or funding, it departs. > 3) Is the DOD going to support cmu? CMU often gives the impression of being a wholly-owned subsidiary of DoD. I'd guess that almost any major project they undertake would use DoD funds. > 4) What about Version 8 Unix? ... > Are there any plans to follow in berkeley's footsteps with > a version of unix based on version 8? Any such plan would have to be cleared with AT&T, who probably would be very much opposed to it, on grounds of competition with System V. Existing V8 licences are few and far between, and AT&T is serious about nondisclosure on V8. Do not hold your breath. > What about a merger? I work on a Masscomp system which is really pretty > nice: they have this universe stuff in which both 4.2 & SysV system calls > can be supported... Is there any chance of the various 4.x utils being > merged into AT&T Unix? To some extent this is already in progress; a few things have filtered over. As far as the system calls... what ever happened to the idea that you should do things once, right, instead of supporting every possible variation? -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
guy@sun.uucp (Guy Harris) (06/10/86)
> > What about a merger? I work on a Masscomp system which is really pretty > > nice: they have this universe stuff in which both 4.2 & SysV system calls > > can be supported... > > ...As far as the system calls... what ever happened to the idea that you > should do things once, right, instead of supporting every possible > variation? "What happened" is that people wrote code to use the 4.2 socket system calls, or the S5 IPC system calls (to cite a couple of your favorite bugbears), and those people aren't in a mood to change their code to use some Wonderful New set of system calls which Do Things Right. I agree that there's a lot of crap in all current versions of UNIX (I'll bet there's even some crap in V8 if you look hard enough) but I don't think you can abolish it all by fiat. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
brett@wjvax.UUCP (06/13/86)
In article <6778@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Nah, 4BSD isn't dead, it just smells that way... :-) >... >> What about a merger? I work on a Masscomp system which is really pretty >> nice: they have this universe stuff in which both 4.2 & SysV system calls >> can be supported... Is there any chance of the various 4.x utils being >> merged into AT&T Unix? > >To some extent this is already in progress; a few things have filtered over. >As far as the system calls... what ever happened to the idea that you should >do things once, right, instead of supporting every possible variation? That's well and good, but there is a crucial difference between features that are implemented differently and features that are omitted. For example, I am involved in some software development that relies on the 4.2bsd select() call, (select() blocks on multiplexed input). As near as I can tell, SYSV allows NO way to block on input from more than one file descriptor, short of doing a poll loop (yuch!). Select() is a MAJOR feature missing from SYSV (which apparently is part of V8). If SYSV offered a comparable feature, even with a different interface, I would be more than willing to #ifdef my code to make it portable to SYSV. But I can't, because the feature is missing from SYSV. In short, "doing something right" is not a good defense when major features have been omitted -- they may not have been done right elsewhere, but that is no justification for not doing them at all. ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
larry@geowhiz.UUCP (Larry McVoy) (06/14/86)
Since I posted the original questions several people have come forward to
sustain them. Here's what I know:
1) Apparently, 4.3 is as far as it goes. I am reasonably certain that the
networking part of 4BSD will no longer be developed (at least not w/dod
funding). I am less certain that 4BSD will stop at 4.3; I will say that
nobody from ucb had anything to say. You would think that they would
complain if I was flapping my gums w/o cause.
2) There is an operating system, called "MACH", which is based on Accent. Both
were developed at cmu. Both are message based systems; Mach is supposedly
*binary compatible* with 4.3. Mach has a lot of neat features including
(as of yet unimplemented[??]) someting called threads. Threads are like
subdivisions of a process; they run concurrently but are lighter weight
than prcesses themselves. I think that means that context switches betweens
threads is easy. Also, it's a multi-processor system. They have it running
on a VAX 784 (as well as other flavors of vaxen).
3) It is not clear whether cmu will get the reins or not. They have something
that looks pretty nice and as Henry Spencer mentioned they get a lot of
funding from DoD. Does that mean they're the next Unix house? Who knows?
Maybe there won't be anything except sys5/version8.
Disclaimer (read this or my *ss is grass): Everything I've said is somewhat
necessarily vague. Obviously neither ucb nor cmu nor DoD consults me when
making these decisions. What I've learned is largely second hand info;
anyone who cared to ask could get the same.
--
Larry McVoy
-----------
Arpa: mcvoy@rsch.wisc.edu
Uucp: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!larry
"Just remember, wherever you go -- there you are."
-Buckaroo Banzaigwyn@brl-smoke.ARPA (Doug Gwyn ) (06/15/86)
In article <713@wjvax.wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes: >I am involved in some software development that relies on the 4.2bsd >select() call, (select() blocks on multiplexed input). As near as I can tell, >SYSV allows NO way to block on input from more than one file descriptor, short >of doing a poll loop (yuch!). Select() is a MAJOR feature missing from SYSV >(which apparently is part of V8). "Fixed in SVR3." There are enough features in SVR3 that have no counterpart in 4.3BSD that this would be a very good time to merge the functionality of these two major UNIX variants. I'm sure that several vendors will be trying to do this anyway; the question is, can we get the principals to adopt the combined version rather than continue to diverge? Who gets to be the keeper of the UNIX?
bsteve@gorgo.UUCP (06/16/86)
["No Emily, it is VIOLENCE, not violins...". "Oh, well that's very different."] ["Never mind."] Lets get it all straight. CMU has an implementation of a modularized os kernel that is inspired by UNIX and its numerous parents. They have separated the the execution path of a process into a task (consisting of pieces atomic to the processor) and an execution thread. It currently (MACH-1) offers source level compatibility with 4.3BSD UNIX. This may not always be there..., it is there now as a building block. Ultimiatly the project should yield an OS for the distributed / parallel processing environment that includes those things that people have learned over the past few years and have often put into UNIX. That's it. 4BSD isn't dead, it has reproduced. EDITORIAL COMMENTARY - I don't think that we should utterly dump 4BSD. On the other hand, if marry it then we are just like the JCL lectroids, ignoring new ideas and clinging to what we already know. Steve Blasingame (Oklahoma City) ihnp4!occrsh!gorgo!bsteve attmail!sblasingame (This is obviously purely my own opinion)
eric@osiris.UUCP (Eric Bergan) (06/17/86)
> That's well and good, but there is a crucial difference between features that > are implemented differently and features that are omitted. For example, > I am involved in some software development that relies on the 4.2bsd > select() call, (select() blocks on multiplexed input). As near as I can tell, > SYSV allows NO way to block on input from more than one file descriptor, short > of doing a poll loop (yuch!). Select() is a MAJOR feature missing from SYSV > (which apparently is part of V8). If SYSV offered a comparable feature, even > with a different interface, I would be more than willing to #ifdef my code to > make it portable to SYSV. But I can't, because the feature is missing from > SYSV. System V rel 3 introduces the "poll" system call, which I understand does pretty much the same thing as "select". While one could have wished that they had stuck with the BSD syntax, at least they are providing functionality. I also heard that the release of streams in V.3 will include a "socket library" which is supposed to keep existing socket based applications working. -- eric ...!seismo!umcp-cs!aplcen!osiris!eric
henry@utzoo.UUCP (Henry Spencer) (06/18/86)
> > ...As far as the system calls... what ever happened to the idea that you > > should do things once, right, instead of supporting every possible > > variation? > > "What happened" is that people wrote code to use the 4.2 socket system > calls, or the S5 IPC system calls (to cite a couple of your favorite > bugbears), and those people aren't in a mood to change their code to use > some Wonderful New set of system calls which Do Things Right. Actually, I wasn't thinking so much of the IPC stuff, which is indeed a difficult problem, as of all the other incompatibilities. For those, would it be too much to ask that people relink their code with a special library (given that they'll probably have to recompile to get their stuff to run on the machine at all) which emulates system X's system calls using system Y's system calls? Instead of having to put both in the kernel? As for people who've written code and don't want to change it... Do those people expect to upgrade to 4.4BSD when it arrives? If so, they'd better brace themselves for another almighty sh*tload of gratuitous incompatibility, because last I heard Berkeley had made it quite clear that 4.3->4.4 compatibility was most unlikely. The real solution to this mess, of course, is that you isolate the stuff that depends on such things in as small a portion of code as possible, so that you DON'T have to rewrite from scratch when some crazed Berkloid bit-hacker or USG programming zombie does something stupid. (Have I offended everybody yet? :-) "I've got all these 7094 Fortran programs that run just fine on the 7094 emulator on my old IBM 360/65. You mean to say I'm going to have to change them to run on a Celerity machine under Unix? That's outrageous." > I agree that > there's a lot of crap in all current versions of UNIX ... > but I don't think you can abolish it all by fiat. Of course, if you don't make some attempt to abolish it, you end up living with it forever. The more patient you are with it, the worse the problem gets, too. "Backward compatibility means never being able to say 'that was a mistake'." -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jqj@gvax.cs.cornell.edu (J Q Johnson) (06/19/86)
In article <1361@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >There are enough features in SVR3 that have no counterpart in 4.3BSD >that this would be a very good time to merge the functionality of these >two major UNIX variants. I'm sure that several vendors will be trying >to do this anyway; the question is, can we get the principals to adopt >the combined version rather than continue to diverge? Who gets to be >the keeper of the UNIX? Is there any reason to believe that this process converges? A plausible future is one in which all the major vendors (ATT, SUN, DEC, now IBM) claim to offer versions of UNIX that merge SysV.3 with 4.3BSD, but which are mutually incompatible. Perhaps they will agree at the SVID level, but I get scared when each vendor points proudly to all the improvements it has made. A test case might be comatibility of window systems, OSI networking support, or distributed file systems. And what about all the "little" vendors who have specialized UNIX ports, e.g. Sequent, Amdahl (little???), etc.? My guess is that incompatible UNIX versions will be with us as long as UNIX is, but they will no longer be bsd vs SysV.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/20/86)
In article <419@gvax.cs.cornell.edu> jqj@gvax.UUCP (J Q Johnson) writes: >My guess is that incompatible UNIX versions will be with us as long as UNIX >is, but they will no longer be bsd vs SysV. This is quite true. My concern is not to preclude true value-added enhancements by vendors, but rather to obtain a guaranteed portable subset environment to support applications. Such an environment must be sufficiently rich to limit the need to reach outside it to variably- interfaced features. I think that the ANSI X3J11 C language standard (which specifies a large amount of the C library too) will go a long way toward this; IEEE 1003.n will cover much of the remaining specifically UNIX environment. Both of these have a good chance of becoming ISO standards. AT&T's SVID is nice too, but it suffers from being associated with a commercial entity (that is, it would be less hassle to specify ANSI/IEEE/ISO standards in a procurement contract). Much of the SVID is available now; IEEE 1003.1 is out for public review in the form of a "trial use" standard; and the ANSI X3J11 proposed C standard may be sent out for public review before the end of 1986. Fortunately all three standards agree quite closely with each other. The biggest problem I am aware of is that 4.3BSD as shipped by Berkeley is still far from compliance with these standards. This is the issue I would like to see satisfactorily addressed soon, at the source rather than individually by each BSD-based system vendor. (I volunteer to do some of the work; perhaps Sun would feed back some of their work to UCB, if Berkeley would agree to pick it up.)
larry@geowhiz.UUCP (Larry McVoy) (06/21/86)
In article <13200008@gorgo.UUCP> bsteve@gorgo.UUCP writes: >Lets get it all straight. CMU has an implementation of a modularized os kernel >that is inspired by UNIX and its numerous parents. They have separated the the >execution path of a process into a task (consisting of pieces atomic to the >processor) and an execution thread. It currently (MACH-1) offers source level >compatibility with 4.3BSD UNIX. This may not always be there..., it is there >now as a building block. Ultimiatly the project should yield an OS for the >distributed / parallel processing environment that includes those things that >people have learned over the past few years and have often put into UNIX. >That's it. 4BSD isn't dead, it has reproduced. > >EDITORIAL COMMENTARY - I don't think that we should utterly dump 4BSD. >On the other hand, if marry it then we are just like the JCL lectroids, >ignoring new ideas and clinging to what we already know. > > Steve Blasingame (Oklahoma City) > ihnp4!occrsh!gorgo!bsteve > attmail!sblasingame 1) It is *binary* compatible with 4.[23]. I quote from "MACH-1 KERNEL INTERFACE MANUAL" by Baron, Rashid, Tevanian, & Young: "On all VAX hardware MACH-1 is binary compatible with 4.2 bsd". 2) 4BSD is dead. It's a gawd-awful kludge & everyone who has looked at the code (should & usually) agrees. At a recent presentation by the Sequent company the speaker asked first "How many people have looked at the 4.3 kernel source?" and second "How many did it on a full stomach?" I rest my case in this respect. 3) MACH-1 is more than a distributed/parallel system. It is compatible and provides the functionality of 4BSD and it does it in a logical/rational/ extensible way (as opposed to the quick fix hacking I've come to expect). 4) MACH-1 is not alone. Ken Thompson & crew are working on a similar system at Bell Labs... Who knows what will come out on top... -- Larry McVoy ----------- Arpa: mcvoy@rsch.wisc.edu Uucp: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!larry "Just remember, wherever you go -- there you are." -Buckaroo Banzai
mwm@eris.berkeley.edu (06/21/86)
In article <13200008@gorgo.UUCP> bsteve@gorgo.UUCP writes: >Lets get it all straight. Hi steve. Not a bad idea; sorry I have to correct you. >CMU has an implementation of a modularized os kernel >that is inspired by UNIX and its numerous parents. They have separated the the >execution path of a process into a task (consisting of pieces atomic to the >processor) and an execution thread. Correct so far. >It currently (MACH-1) offers source level compatibility with 4.3BSD UNIX. First, the MACH kernel I have says "MACH/4.3/2.1" (or something similar, I don't have a console log handy :-) when it boots. Second, it is not merely source compatible with 4.3, it's BINARY compatible. I copied a MACH kernel onto a 4.3 system, rebooted, and found nothing wrong (ps worked, etc.). Nothing got recompiled. I expect this to compatability to stay in the system, but not being a MACH developer, can't say for sure. <mike
roger@celtics.UUCP (Roger Klorese) (06/24/86)
In article <6824@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >"I've got all these 7094 Fortran programs that run just fine on the 7094 >emulator on my old IBM 360/65. You mean to say I'm going to have to change >them to run on a Celerity machine under Unix? That's outrageous." > Gee, Henry, I agree; we'll have to work on it! (Right after TRS-80 emulation mode...) :-) -- =================================== "Speak for the company?! Gee, I have a hard enough time speaking for myself!" ==================== Roger B.A. Klorese | ///==\\ | Celerity Computing (Eastern Region) | /// | 40 Speen St., Framingham, MA 01701 +1 617 872-1552 | \\\ | | \\\==// | celerity!rklorese@sdcsvax.ARPA (sdcsvax!celerity!rklorese) ==================== celtics!roger@seismo.CSS.GOV (seismo!celtics!roger)