gregh@cup.portal.com (Greg S Hinton) (03/05/89)
Since I only got one response with this restricted to the Bay Area, I'm
reposting with a wider distribution:
To anybody following BSD Unix for a while, my question will probably seem
pretty lame. But I'm fairly new to all this, so please bear with me...
I've heard two conflicting predictions lately about the future of Unix
development at Berkeley. One school of thought says that CSRG has lost
most of its funding (Dept. of Defense?) and so the evolution of BSD has
come to an end; all their wonderful ideas will be absorbed into System V
and the world will acheive homogeneous standardhood.
The other school of thought maintains that CSRG has only just begun; in
fact, a version 4.4 BSD will soon be upon us with some pretty radical
innovations. And more will follow.
Who's right? Or is the truth -- as I suspect -- somewhere between those
two extremes?
-------------
Greg Hinton
gregh@cup.portal.com
{hplabs!pyramid,amdahl!sun}!cup.portal.com!greghdebra@alice.UUCP (Paul De Bra) (03/06/89)
In article <15407@cup.portal.com> gregh@cup.portal.com (Greg S Hinton) writes: } }I've heard two conflicting predictions lately about the future of Unix }development at Berkeley. One school of thought says that CSRG has lost }most of its funding (Dept. of Defense?) and so the evolution of BSD has }come to an end; all their wonderful ideas will be absorbed into System V }and the world will acheive homogeneous standardhood. } }The other school of thought maintains that CSRG has only just begun; in }fact, a version 4.4 BSD will soon be upon us with some pretty radical }innovations. And more will follow. } }Who's right? Or is the truth -- as I suspect -- somewhere between those }two extremes? You got it. I don't know about the funding aspect though. System V release 4 will merge System V release 3 with Bsd 4.3, as much as possible. This however is mostly AT&T's commitment, and does not stop BSD from changing Bezerkeley Unix again. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
chris@mimsy.UUCP (Chris Torek) (03/06/89)
In article <15407@cup.portal.com> gregh@cup.portal.com (Greg S Hinton) writes: >I've heard two conflicting predictions lately about the future of Unix >development at Berkeley. One school of thought says that CSRG has lost >most of its funding (Dept. of Defense?) and so the evolution of BSD has >come to an end; all their wonderful ideas will be absorbed into System V >and the world will acheive homogeneous standardhood. Hah. >The other school of thought maintains that CSRG has only just begun; in >fact, a version 4.4 BSD will soon be upon us with some pretty radical >innovations. And more will follow. Hah again. >Who's right? Or is the truth -- as I suspect -- somewhere between those >two extremes? More or less. 4.4BSD% is already funded and in progress. As I understand it, the money is being laundered%% through NIST%% (nee NBS), and is intended for ISO/OSI integration. 4.2BSD *was* DoD funded, for the purpose of developing a widely-used TCP/IP implementation. I guess someone figured if 4.2BSD had such an effect, 4.4BSD could do the same for OSI. ----- % Not an official name; `8BSD' or `9BSD' might be more appropriate. %% `Government is just like organized crime, only less efficient.' [author forgotten, if not persecuted by the government :-) ] %%% As in `the Knights of NIST' (apologies to Python fans). ----- CSRG is a University project; it works like all University projects: it continues as long as someone maintains interest. Where there is sufficient interest, someone will find funds. There is certainly more to be done than just ISO development; it seems likely that there will be a 4.5BSD. I just hope no one starts numbering them `4.3 Release 2 Version 2'... :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rob@violet.berkeley.edu (Rob Robertson) (03/07/89)
In article <16230@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >I just hope no one starts numbering them [future BSD releases as] `4.3 >Release 2 Version 2'... :-) as opposed to cool hacker names such as 4.3tahoe and 4.3classic. rob
jeffrey@algor2.UUCP (Jeffrey Kegler) (03/07/89)
In article <15407@cup.portal.com> gregh@cup.portal.com (Greg S Hinton) writes: >One school of thought says that CSRG has lost >most of its funding (Dept. of Defense?) and so the evolution of BSD has >come to an end I heard exactly that rumor in 1983. It has clearly passed the test of time :-) -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1788 Wainwright DR, Reston VA 22090
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/08/89)
Is there a future for BSD? Ignoring the issue of when new releases
will be available, I get the impression that virtually all of the
hardware vendors have joined OSF or UNIX International. Since both of
these systems will be SysV based, will there be a demand for BSD in
three years? Five?
With commercial sites going to SysV based releases I predict that more
software will be coming out using the SysV features, both in commercial
and public domain. The only vendor with a BSD committment seems to be
DEC. The last statement I saw from them was Ken Olsen saying something
like "we support portable standards, we support OSF, and we're going to
continue to offer Ultrix and support our customers."
Information or rational comments desired.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mechris@mimsy.UUCP (Chris Torek) (03/08/89)
In article <13324@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > Is there a future for BSD? Ignoring the issue of when new releases >will be available, I get the impression that virtually all of the >hardware vendors have joined OSF or UNIX International. Since both of >these systems will be SysV based, will there be a demand for BSD in >three years? Five? BSD is a research vehicle. What does `vendor demand' have to do with its existence? Remember, *no* release of 2BSD has been officially supported by *anyone*. (2BSD may be dead---the 2.10 BSDers have been trying to kill it for years---since PDP-11s are just Too Small these days. But there is still research interest in 4BSD.) 3BSD (the first VAX system) was done at Berkeley for Berkeley. 4.0BSD and 4.1BSD ran on VAXen when DEC's position was `VAX == VMS'. 4.2BSD primarily got out of hand because the U.S. Federal government demanded both Unix *and* TCP/IP. Vendors found they had the choice of either adding TCP/IP to SysV or using 4.2BSD---or losing the government market. Government, of course, *is* *the* Big Business. (The only one that can afford to show a loss year after year, too. Hmm....) Vendors scrambled to port Unix to their hardware. Many of them quite sensibly used 4.2BSD---it was easier to add any demanded SysV features to BSD than it was to add networking to SysV---and, alas, many of them simply ported the kernel, then stopped. Since 4.2BSD was released before it was finished, it was naturally quite buggy. I cannot guess how much that effect contributed to the move toward SysV, but I think it was rather small in the end. Making SysV standard is attractive to AT&T for the obvious reason; it is good for IBM as well, since one of their major government market competitors (DEC) has made a commitment to BSD. So there is plenty of money behind the `consider SysV standard' campaign (which I naturally buck with `consider it substandard' :-) ). Okay, so what does this imply for future government funding for BSD? Suppose the Feds buy the `standard' line. The bureaucrats grind out new Official Regulations mandating that new buys meet the SVID. But say DoD wants feature X (ISO, Mach VM, pick your favourite). They can: - get an exception so that they need not meet SVID - fund someone to put feature X in SysV - fund someone to make BSD SVID-compliant and put X in BSD The second and third cost options about the same, and are cheaper than the first. Pouf!: instant research money. (`Hey, Joe, run off another 250,000 $20s'... :-> ) Who gets it? Pouf!: instant politics. Obviously CSRG gets a shot. Is option 2 cheaper? I.e., would CSRG start doing SysV-based systems? Maybe. But the Feds are not going SVID: they are going POSIX, and CSRG are going that way too. The research money is sure to go to some university, and universities prefer BSD. Implication: future government funding is likely to be around. CSRG may or may not get some. Suppose the Feds pull out. (Say George B. catches on to the fact that half the Pentagon's paper-pushers are actually just moving the papers round and round the building.) The deficit starts shrinking and the depression shows up full force. Money gets scarce (as Joe in the print shop stops the presses). Only the Really Big universities are going to be able to keep things going. Berkeley is one. Would CSRG survive? No telling. But they have a better chance than many. All in all, the only thing sure to kill BSD is lack of interest (pun required). > Information or rational comments desired. Oh. Too late. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
naim@eecs.nwu.edu (Naim Abdullah) (03/09/89)
Chris Torek writes: >CSRG is a University project; it works like all University projects: >it continues as long as someone maintains interest. Where there is >sufficient interest, someone will find funds. There is certainly more ^^^^^^^^^^^^^^^^^^^^^^^ >to be done than just ISO development; it seems likely that there ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >will be a 4.5BSD. It is fairly well known (though I don't know how true) that 4.4BSD will have POSIX compatible tty drivers, some kind of file system switch, reworked VM, memory mapped files and ISO. So the 4.4BSD features appear to have been frozen. Chris mentions that there is more to be done than just ISO. I have been wondering what innovative features would people like to see in future versions of BSD such as 4.5BSD ? Which of these ideas are not already present in System Vr4, Mach, V9 or Sprite ? Here is your chance to give everybody your wishlist. Naim Abdullah Dept. of EECS, Northwestern University Internet: naim@eecs.nwu.edu Uucp: {oddjob, chinet, att}!nucsrl!naim
mike@cimcor.mn.org (Michael Grenier) (03/10/89)
From article <13324@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr): > > Is there a future for BSD? Ignoring the issue of when new releases > will be available, I get the impression that virtually all of the > hardware vendors have joined OSF or UNIX International. Since both of > these systems will be SysV based, will there be a demand for BSD in > three years? Five? > I don't know about OSF (and don't really care :-) but UNIX International is basing its standard on System V Release 4 which I believe has or will have most BSD features in it. Its unclear as your article points out what demand there will be for pure BSD without System V features but I suspect the demand will be there if for no other reason than the lack of availability of V.4 for your machine and the nature of University/Research types who think BSD is the greatest (actually, many others think it is too!) Unfortuntely, there will only be UNIX V.2 for this lowly Intel 80286 box and that company may be in trouble :-( ... of course, I could run XENIX :-( ... or should that be VENIX :-? ... or OS/2 (cough, choke ...) -Mike Grenier mike@cimcor.mn.org uunet!rosevax!cimcor!mike
donn@titan.rice.edu (Donn Baumgartner) (03/17/89)
In article <665@cimcor.mn.org> (Michael Grenier) writes: >From article <13324@steinmetz.ge.com>, (William E. Davidsen Jr): >> >> Is there a future for BSD? Ignoring the issue of when new releases > : >> will there be a demand for BSD in three years? Five? > >I don't know about OSF (and don't really care :-) but UNIX International > : >types who think BSD is the greatest (actually, many others think it is too!) > >Unfortuntely, there will only be UNIX V.2 for this lowly Intel 80286 box... (plug) My recent request for help brought in several new recruits to the ATbsd project (I'm thankful to the net for this), leading me to speculate that Mike will not be permanently destined to run V.2 on his box, and to further suggest that there are thousands of similar people with 286 machines that will continue to be interested in BSD (perhaps casting doubt on Mr. Davidsen's implication that BSD is on it's way out). If any of (the rest of) you berzerkeley supporters/freaks missed my last plea for help (and you have a BSD source license, sigh), don't hesitate to send me mail asking for details on how you can help with the ATbsd project. The more people working on this, the sooner it'll get done. - Donn Baumgartner (donn@rice.edu, rice!donn) ATbsd project coordinator (and hacker :-)
bzs@bu-cs.BU.EDU (Barry Shein) (03/18/89)
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) > Is there a future for BSD? Ignoring the issue of when new releases >will be available, I get the impression that virtually all of the >hardware vendors have joined OSF or UNIX International. Since both of >these systems will be SysV based, will there be a demand for BSD in >three years? Five? The unasked question here is "Is there a need for an experimental, research version of Unix"? Note that a lot of what is becoming SYSVR4 and OSFIX are the incorporation of BSD features which, when introduced, were experimental (and other experimental features over the years which have been dropped.) Right now there are three major sources of experimental Unix implementations, Bell Labs, BSD and Mach. They are already incorporating experimental ideas which the standards people are probably a few years behind on standardizing. Some examples: 1. What is the Unix parallel processing standard interface? How should things like spinlocks and barriers be incorporated? What exactly are the set of primitives the kernel should provide to support such development? How is the scheduler to be affected? 2. Is network-wide virtual memory a good idea? How would you implement it? How should it be presented to the application programmer? 3. How can Unix be "personalized". Right now Unix's structure is strongly oriented towards centralized time-sharing. Although it's not that hard to use in a workstation environment a lot of its facilities presume knowledgeable system administrators and operations personnel. At other levels assumptions exist (taking an idea from the very good Mark Weiser/L. Peter Deutsch article in a recent Unix Review), why can't I single step a debugger into the kernel from an application (I can do the equivalent on other workstation OS's) etc. Should I be able to? How would it work? 4. Is the Unix file system, unenhanced, the right view for personal workstations with a few GB of disk? I would claim that the MacOS file system view has collapsed as an abstraction with the popularity of 300MB or larger disks, as cute as it was with a few files. Is there a similar threshold for the Unix system? It's 10PM, do you know where your sources are? 5. Fujitsu claims they will be producing 64Mbit memory chips in a couple of years. This means a 16Mbyte workstation, with the same chip count, becomes a 1GB workstation. Does anything need to be evolved to utilize this kind of change? Is it really sufficient to treat it as "more of the same"? 6. What exactly should we be doing with networking hardware which runs at memory bus speeds? Who would answer these questions? Standards organizations? I hope not! Granted a lot of folks ran BSD simply as a production Unix system, particularly in Universities. Now production systems are available as commodity items from manufacturers so they wonder why, given that their needs are fulfilled, would anyone continue with the BSD releases? But that's all wrong, you were running research versions of the system. If you're satisfied with being about 5 years behind the state of the art (4.2 came out in 1983 and that's about where most manufacturers are today, 4.3 is 1986 software so that's only three years behind) then by all means do so. In short, standardizing what we have today should not mean abandoning the future. -Barry Shein
bph@buengc.BU.EDU (Blair P. Houghton) (03/19/89)
In article <28819@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >4. Is the Unix file system, unenhanced, the right view for personal >workstations with a few GB of disk? I would claim that the MacOS file >system view has collapsed as an abstraction with the popularity of >300MB or larger disks, as cute as it was with a few files. Is there a >similar threshold for the Unix system? It's 10PM, do you know where >your sources are? Well put. I'd just like to clarify my misgivings about the simple-tree directory system: it's too hard to find what you put down when you were drunk, or six weeks ago, or...well... Some sort of cross-referencing, indexing, dewey-decimal systematization, etc., would be exceptionally helpful. Having a README in the directories that collect cryptically-named files just doesn't cut it. At the moment I'm personally responsible for around three thousand files on the four largest machines I use (and please don't ask how many bytes that is...there are some things better left uninvestigated...:-S), few of them interrelated. You'd think I would have seen it coming. Any good ideas? --Blair "Better living through the sheer weight of stored charge..."
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/25/89)
In article <28819@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: | | From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) | > Is there a future for BSD? Ignoring the issue of when new releases | > [ ... ] | The unasked question here is "Is there a need for an experimental, | research version of Unix"? Unasked by me, for sure. What I'm looking at is "will any non-research sites still be running anything other than SysV for commercial production use?" Not that your question isn't a good one, but it's not my question. | Right now there are three major sources of experimental Unix | implementations, Bell Labs, BSD and Mach. They are already | incorporating experimental ideas which the standards people are | probably a few years behind on standardizing. Well, three places which have their own kermel, although there is a lot of V7 still in BSD, it seems. Other improvements and non-kernel features come from places like MIT (X-windows and I think kerborous), Sun (NFS), Venturcom (real time kernel mods), etc. I'm sure others can think of dozens of other organizations which have made advances which have been picked up by BSD, SysV or both. | Granted a lot of folks ran BSD simply as a production Unix system, | particularly in Universities. Now production systems are available as | commodity items from manufacturers so they wonder why, given that | their needs are fulfilled, would anyone continue with the BSD releases? | | But that's all wrong, you were running research versions of the | system. If you're satisfied with being about 5 years behind the state | of the art (4.2 came out in 1983 and that's about where most | manufacturers are today, 4.3 is 1986 software so that's only three | years behind) then by all means do so. That's what I was asking. Ten years ago there was some reason to go with the latest version of BSD because you needed virtual memory, fast file system, etc. This stuff will now be in SysV, along with NFS, RFS, streams, and a bunch of realtime things which are supposed to come in V.4.1 as I recall. Will there still be a need for BSD or mach among the people who don't do kernel research? If the commercail vendors go with SysV, as it seems they will, will universities find it easier to get fund$ for research on what vendors are selling and the government is buying? I'm looking for good reasons other than kernel research, and I don't think you need a totally new kernel to do that. -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
bzs@bu-cs.BU.EDU (Barry Shein) (03/25/89)
> That's what I was asking. Ten years ago there was some reason to go >with the latest version of BSD because you needed virtual memory, fast >file system, etc. This stuff will now be in SysV, along with NFS, RFS, >streams, and a bunch of realtime things which are supposed to come in >V.4.1 as I recall. Will there still be a need for BSD or mach among the >people who don't do kernel research? If the commercail vendors go with >SysV, as it seems they will, will universities find it easier to get >fund$ for research on what vendors are selling and the government is >buying? I'm looking for good reasons other than kernel research, and I >don't think you need a totally new kernel to do that. >-- > bill davidsen (wedu@crd.GE.COM) The point is that there's more to the experimental unix versions than kernel research. For example, it's likely that BSD will be the first major variant with an ISO stack and you might be interested in using that as a platform. Mach already has a form of lightweight processes and if you're buying a parallel machine it's the closest you'll find to some sort of widely used interface for writing truly parallel programs. These are not just little goodies, these open whole vistas of opportunity to those who need these things. Parallelism looks like the best shot we have at delivering thousands of MIPS at reasonable costs in the next few years. In fact, I believe that latter example should be enough to answer the question. How exactly are you going to exploit the parallel hardware you're going to be screaming for soon (:-) with SysV or OSFix? Sure, you can limit yourself to coarse-grained parallelism and get a lot of benefit (eg. piped shell commands run in parallel, various compiles in make can run in parallel by just firing up more than one cc command, time-sharing obviously benefits without doing anything special.) But what about data-driven programs where you need to fire up CPUs as you run, probably dynamically calculating the optimal number of CPUs to use for the next calculation? You can use vanilla Unix fork() but it's lacking seriously and everyone I know who's thinking about the problem has proposed at least some major change to fork semantics. Otherwise the advantage you might have seen from parallelism goes down the fork creation time rat-hole (actually, fork+shmem+signal setup etc.) Where do you think this sort of thing will come from? It's really quite fundamental, not something a vendor is likely to whip together satisfactorily. And when it shows up and you need it you'll start considering running one of these research versions. Again, if you don't need it obviously you won't perceive the value. I know plenty of people who don't need computers also. I think research in Unix futures has become MUCH more critical now that almost every vendor is relying on it to plot their fate. I'm just having trouble seeing your point, do you think operating systems are "finished" with the release of SysV/OSFix? Or do you see a lesser percentage of folks running research versions? Of course, that's because of all the folks who are running Unix but used to be running VMS/DOS/PRIMOS/AOS/MVS/VM/CPM. Of course the herd heads straight for the recent past, they never run research versions, nor should they in most cases. What was that Dennis Ritchie quote? "The number of Unix installations has grown to 12 with more expected in the near future". Let's keep some perspective here! -Barry Shein, Software Tool & Die
schwartz@shire.cs.psu.edu (Scott Schwartz) (03/26/89)
In article <13428@steinmetz.ge.com>, davidsen@steinmetz (Wm. E. Davidsen Jr) writes: >Will there still be a need for BSD or mach among the >people who don't do kernel research? If the commercail vendors go with >SysV, as it seems they will, will universities find it easier to get >fund$ for research on what vendors are selling and the government is >buying? I'm looking for good reasons other than kernel research, and I >don't think you need a totally new kernel to do that. How about source availability at reasonable cost? Lots of people want it very badly. Currently, of course BSD requires a licence from AT&T, but aren't they planning on removing all AT&T code from the system? In that case, I'd say that continuing BSD development is essential! -- Scott Schwartz <schwartz@shire.cs.psu.edu>
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/28/89)
In article <28955@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: | In fact, I believe that latter example should be enough to answer the | question. How exactly are you going to exploit the parallel hardware | you're going to be screaming for soon (:-) with SysV or OSFix? I'm not sure just what you have in mind... SysV does multiple processors now (UniCOS, etc) and V.4 is going to have Sun lightweight processes (it hasn't been pulled, has it?). | I'm just having trouble seeing your point, do you think operating | systems are "finished" with the release of SysV/OSFix? Or do you see a | lesser percentage of folks running research versions? UNIX and "operating systems" are not the same thing. After SysV.4 when most of the stuff which distinguishes BSD from SysV is in SysV, will researchers want to continue to try to keep upgrading their reasearch system to include SysV stuff (yes folks, msg queues, named pipes, lp spooling, shared memory, and even mmap when it comes are useful)? If I were doing research I'd rather write new utilities, develop new applications, and design new {filesystems, swapping, networking}. If someone is going to write a new o/s that's one thing, but to write another UNIX, ho hum. You're right, I don't see a lot of research versions. I would bet that most of the sites running BSD don't do research, they just need some feature not currently in SysV. If SysV will do the jobs and have better support, they will run SysV. All predicated on vendors putting their policy where their money is. -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
hwt@bnr-public.uucp (Henry Troup) (03/29/89)
Some years ago, when I was an undergrad at the University of Toronto, a prof had just completed TUNIS, the Toronto UNIx System. This was a Unix (BSD) kernel written in Concurrent Euclid. Anyone know what if anything happened with this? utgpu!bnr-vpa!bnr-fos!hwt%bnr-public | BNR is not | All that evil requires hwt@bnr (BITNET/NETNORTH) | responsible for | is that good men do (613) 765-2337 (Voice) | my opinions | nothing.
madd@bu-cs.BU.EDU (Jim Frost) (04/02/89)
In article <13451@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: |I would bet that |most of the sites running BSD don't do research, they just need some |feature not currently in SysV. "Connectivity." jim frost madd@bu-it.bu.edu