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
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..."
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/19/89)
In article <2344@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >it's too hard to find what you put down when ... >Any good ideas? Use so-called "associative memory", or a good DBMS.
joe@hanauma.stanford.edu (Joe Dellinger) (03/20/89)
In article <2344@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: > >Some sort of cross-referencing, indexing, dewey-decimal systematization, >etc., would be exceptionally helpful. > In our research group the problem was with tracking down source code. IE, did someone ever write a Burg deconvolution program I could use instead of having to write a new one from scratch? It used to be the solution was to ask the one person who knew everything that existed on the system. Then he graduated! Our current solution is to have everybody put a "keyword" line into useful source code they might write, for example: /* keywords: burg deconvolution */ The first 100 lines of every .c, .f, .r, etc, file in the entire file system is searched every Sunday morning for such keyword lines, and a database is created. There is another database which gives synonyms. Then you can do "keyword decon", and get something like: Synonyms for decon: decon deconvolution whiten pef prediction weiner /usr/src/our/cube/proc/pefsubs.f prediction /usr/src/our/cube/proc/RCtoIF.r prediction reflection-coefficient /usr/src/our/cube/proc/Pef.c prediction-error /usr/src/our/cube/proc/Whiten.c whiten decon /users/joe/Work/Burg/Medc.c burg deconvolution Hope this idea is helpful. \ /\ /\ /\/\/\/\/\/\/\.-.-.-.-.......___________ \ / \ / \ /Dept of Geophysics, Stanford University \/\/\.-.-....___ \/ \/ \/Joe Dellinger joe@hanauma.stanford.edu apple!hanauma!joe\/\.-._
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
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/25/89)
In article <2344@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: | 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. Something is needed. I tried building a small database on a per-inode basis, with multiple keywords and a one line description. Too much work. Useful for keeping track of some of your files, but not a general solution to the problem you address. -- 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>
cdr@amdcad.AMD.COM (Carl Rigney) (03/26/89)
This has no business in Unix Wizards, so I editted that out.
In article <28955@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
[Why people will still be interested in BSD after System V becomes "standard"]
I agree with many of the points Barry makes, but I'd like to add a word
from a System Administrator working at a Fortune 500, $1 billion
company - Advanced Micro Devices. Except for our large installed base
of Mentor (Apollo) CAD workstations, the vast majority of our computers
run some flavor of BSD (counting SunOS). And it's our intention to
continue running BSD-compatible systems into the future. If some
vendor has a System V that looks exactly like 4.3BSD, that's OK. But
to follow the herd just because some marketing person at AT&T keeps
shouting loudly "We're the standard! We're the standard!" strikes me
as useless.
We choose the best hardware to accomplish our mission, and so far that
hardware runs 4.3 ports. We try to follow (although not nearly as
closely as I wish I had time for) current research in distributed computing.
We're looking into ISIS, and as other distributed systems appear we'll
look into them, because every night a thousand mips of CPU power are idling
for lack of software to use them effectively. In Chip Design, CPU Power
translates directly into better product designs and faster time to market -
there's no limit to how much CPU power we could use if we could get it,
but there is a limit to our resources, so by staying near the front of the
pack instead of using 5-year old technology & software, we get a very real
boost to our bottom line, intangible as it may be to quantify.
I don't want to see this degenerate into another System V vs. 4.3 argument,
but I just thought I'd express a few reasons for why BSD is far from
disappearing in the business place.
--Carl Rigney
cdr@amdcad.AMD.COM
{ames decwrl gatech pyramid sun uunet}!amdcad!cdr
408-749-2453
Disclaimer: I'm not an official spokesperson for AMD. (I am, however,
currently evaluating various computers for a major purchase, and it
*will* be running a 4.3-based OS.)jps@cat.cmu.edu (James Salsman) (03/26/89)
BSD will have more innovative features than SysV for a long time, but SysV will always be more stable. Witness AFS, the Andrew File System: the first nationwide file system. It runs under BSD, and I don't think it'll be on SysV machines for a while. But, I could be wrong. BSD code is more accessable; if AT&T wants major innovations under SysV, they are going to have to be more easy-going with the sources and software hooks. -- :James P. Salsman (jps@CAT.CMU.EDU) --
guy@auspex.UUCP (Guy Harris) (03/27/89)
>BSD will have more innovative features than SysV for >a long time, I presume then that some future BSD release will have a dynamic linking mechanism, complete with a programmatic interface to the run-time loader, so that you can map a dynamically-linked object into your address space, look up functions in that object by name and get pointers to them, and unmap the object from your address space? I expect S5R4 to have that.... (It'll also be interesting to see whether 4.4BSD, with an "mmap" that lets you map files into your address space, comes out before S5R4, with an "mmap" that lets you map files into your address space.) Now, CMU already has something of that general nature that runs on BSD systems, as I understand it (Andrew uses it, as I remember), so in that sense BSD will have it, even though it may not be on the tape you get from Berkeley. >Witness AFS, the Andrew File System: the first nationwide >file system. It runs under BSD, and I don't think it'll be >on SysV machines for a while. But, I could be wrong. It depends; if a version of AFS is made whose kernel-level functions plug into a VFS-type interface, it will be possible to plug it into an S5R4 system. Does AFS run under an unmodified BSD? If not, then the real question to ask is "how easy is it to modify BSD to support it vs. how easy is it to modify S5 to support it". >BSD code is more accessable; if AT&T wants major innovations >under SysV, they are going to have to be more easy-going >with the sources and software hooks. I'm not sure what you mean by "more easy-going... with the software hooks"; if you have the source, you can put in whatever hooks you want, and I suspect the number of hooks of that flavor that come with the system off the distribution tape won't be higher for BSD than S5. I think the bottom line for BSD vs. S5 is: 1) availability of source. Unless S5 source is missing critical pieces that are present in BSD releases (which could conceivably happen), then unless Berkeley comes out with a completely AT&T-code-free release (which they may well do, at some point), you'll have to buy S5 source anyway to get BSD source (unless you already have a licence sufficent to get you BSD releases "in perpetuity", which I suspect many, possibly most, research institutions already have). Given the parenthetical phrases listed there, it could well be that BSD source is more available to research institutions than S5 source is. 2) familiarity. I have the impression that BSD dominates in research institutions, especially universities; it may be that adapting either projects or people to an S5 release may require sufficient effort so as to discourage such adaptation. The barrier may reduce with S5R4. Of course, some of the machines in those institutions may be running the vendor's OS, rather than BSD; even for vendor's OSes that come, in part, from BSD, there are probably barriers of that sort. (SunOS is *not* BSD, for example. It's not *intended* to be "a BSD port to Suns".) The issue of "what research projects, or innovative features, run under BSD vs. System V" - this basically refers to features that *don't* come on the distribution tape, e.g. the Andrew File System - is probably governed by the issues above. Of course, this also brings up the issue of "will any of those features get *on* the distribution tape." It's conceivable that they'll get on the BSD tape more easily than they'll get on the S5 tape. My personal guess, for what it's worth (which isn't a hell of a lot; from what I've seen, I don't put much stock in predictions of the future in this field), is that some research flavor of UNIX will continue to be popular in universities and other research institutions. I don't know whether it'll be BSD, or Mach, or something else; I suspect it'll be less stable than S5-from-AT&T, as suggested by others, and that its relative lack of stability will be precisely one of those features that *makes* it popular - for instance, it'll be easier to get innovations onto the distribution tape. It may be easier to get source for it, which may help as well.
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
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/28/89)
In article <4572@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: | BSD code is more accessable; if AT&T wants major innovations | under SysV, they are going to have to be more easy-going | with the sources and software hooks. Really? I thought you had to buy a SysV source license before you could get BSD source. Has that changed? Of course there are more *unlicensed* copies of BSD around, that I agree. -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
scott@dtscp1.UUCP (Scott Barman) (03/29/89)
In article <13452@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <4572@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >| BSD code is more accessable; if AT&T wants major innovations >| under SysV, they are going to have to be more easy-going >| with the sources and software hooks. > > Really? I thought you had to buy a SysV source license before you >could get BSD source. Has that changed? Of course there are more >*unlicensed* copies of BSD around, that I agree. Speaking of licensing: When bsd and System V are merged, will the holders of 32V licenses still be able to get source to newer bsd versions? Or will everyone wishing to get source have to go out and get a SV.4 licence? Also, in the recent wave of AT&T f***ing up licensing procedures (it used to be soooo easy), are they planning any changes for SV.4? -- scott barman {gatech, emory}!dtscp1!scott
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/29/89)
In article <601@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: > When bsd and System V are merged, will the holders of 32V licenses >still be able to get source to newer bsd versions? That depends on whether the newer BSD releases incorporate code derived from post-UNIX/32V releases of UNIX or not. > Also, in the recent wave of AT&T f***ing up licensing procedures (it >used to be soooo easy), are they planning any changes for SV.4? What do you think is wrong with the licensing procedures? I've dealt with AT&T software licensing many times and haven't had significant problems.
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.
aad@stpstn.UUCP (Anthony A. Datri) (03/29/89)
In article <4572@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >a long time, but SysV will always be more stable. Let's see: svr1,svr2,svr3,svr3.2,svr4... Seems like they come out with versions a lot more often. >Witness AFS, the Andrew File System: the first nationwide >file system. It runs under BSD, and I don't think it'll be >on SysV machines for a while. My experiences with AFS have been that it's slow as molasses, and has no support for diskless machines. I think much of it is done with additions to the BSD kernel, and I've heard that it's been done to AIX now. >BSD code is more accessable; if AT&T wants major innovations BSD-only code is more accessible, but things with AT&T code still in them are still a real pain. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
karish@forel.stanford.edu (Chuck Karish) (03/30/89)
In article <3095@stpstn.UUCP> aad@stepstsone.com wrote: >In article <4572@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >>a long time, but SysV will always be more stable. >Let's see: svr1,svr2,svr3,svr3.2,svr4... Seems like they come out with >versions a lot more often. Yes, but it's a stable development environment because AT&T specifies what backward compatibility they'll provide in new versions. This may be carried a bit too far, to the extent that they're reluctant to fix misfeatures for fear of breaking customers' work-arounds. Any developer who's happy with the old functionality can ship products for the newer version of the OS without having to port to it. Chuck Karish hplabs!hpda!mindcrf!karish (415) 493-7277 karish@forel.stanford.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/30/89)
In article <3095@stpstn.UUCP> aad@stepstsone.com writes: -In article <4572@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: ->a long time, but SysV will always be more stable. -Let's see: svr1,svr2,svr3,svr3.2,svr4... Seems like they come out with -versions a lot more often. He said "stable", not "stagnant".
guy@auspex.UUCP (Guy Harris) (03/30/89)
> When bsd and System V are merged, will the holders of 32V licenses >still be able to get source to newer bsd versions? Or will everyone wishing >to get source have to go out and get a SV.4 licence? I think you misunderstand what "when bsd and System V are merged" means. It means that S5R4 will be picking up BSD stuff, not that S5 and BSD will become one and the same thing. As far as I know, Berkeley isn't going to convert to S5R4, so presumably a 32V licence should continue to be sufficient.
larry@macom1.UUCP (Larry Taborek) (03/30/89)
My question is, since Berkeley has been paying licsence fees to AT&T for portions of their code, will AT&T pay Berkeley for portions of their code included in SVR4? If not, then will AT&T price SVR4 so that users are not paying for portions of code that AT&T did not buy or develop? Anyone from AT&T or Berkeley wish to comment? -- Larry Taborek ..!uunet!grebyn!macom1!larry Centel Federal Systems larry@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 703-758-7000
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/31/89)
In article <4814@macom1.UUCP> larry@macom1.UUCP (Larry Taborek) writes: >My question is, since Berkeley has been paying licsence fees to >AT&T for portions of their code, will AT&T pay Berkeley for >portions of their code included in SVR4? If not, then will AT&T >price SVR4 so that users are not paying for portions of code that >AT&T did not buy or develop? I'm sure that AT&T's lawyers have made the necessary contractural arrangements with all providers of software that AT&T will be distributing. I'm also sure that they're not going to disclose the details of any such arrangement just because you're curious about it. The pricing for SVR4 has not yet been announced. The implied accusation of theft that lies behind your questions is, to the best of my knowledge (and I do have some inside knowledge) unfounded and demands an apology.
ekrell@hector.UUCP (Eduardo Krell) (03/31/89)
In article <4814@macom1.UUCP> larry@macom1.UUCP (Larry Taborek) writes: >My question is, since Berkeley has been paying licsence fees to >AT&T for portions of their code, will AT&T pay Berkeley for >portions of their code included in SVR4? As far as I know, AT&T is negotiating with Sun to merge SunOS features into SVR4, not with Berkeley. What the financial arrangements between AT&T and Sun are, I have no idea. Does Sun pay Berkeley for using BSD code in SunOS? How about all other vendors who are "BSD derivatives"? Isn't BSD code public domain (that is, BSD code that is not derived from AT&T)? If so, why should AT&T or Sun or anyone else have to pay for getting something that's already in the public domain? Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
fischer@iesd.dk (Lars P. Fischer) (04/01/89)
In article <9957@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: >In article <4814@macom1.UUCP> larry@macom1.UUCP (Larry Taborek) writes: >>My question is, since Berkeley has been paying licsence fees to >>AT&T for portions of their code, will AT&T pay Berkeley for >>portions of their code included in SVR4? If not, then will AT&T >>price SVR4 so that users are not paying for portions of code that >>AT&T did not buy or develop? > >... >The implied accusation of theft that lies behind your questions >is, to the best of my knowledge (and I do have some inside >knowledge) unfounded and demands an apology. Very good. Don't ever use provoking or humorous language. Doug does not like that, you see. And he's always *so* polite :-). Lighten up, Doug. Read the question as "will i have to pay $$ to get something from ATT that I could have for free from Berkeley?". We all appreciate your help and information, but try not to throw rocks at people all the time, OK? /Lars -- Lars Fischer, fischer@iesd.dk, {...}!mcvax!iesd!fischer Dept. of Math. and Comp. Sci., University of Aalborg Strandvejen 19, DK-9000 Aalborg, DENMARK Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke
madd@bu-cs.BU.EDU (Jim Frost) (04/02/89)
My addition to the SysV versus Berkeley argument is: when is AT&T going to put in a more advanced filesystem and memory management? Running large applications on BSD machines is much less painful than it is under vanilla SysV. And this 14 character bugaboo and disk fragmentation is just driving me nuts. But give me job control and I can live with it. jim frost madd@bu-it.bu.edu
rogerk@mips.COM (Roger B.A. Klorese) (04/02/89)
In article <29183@bu-cs.BU.EDU> madd@buit4.bu.edu (Jim Frost) writes: >My addition to the SysV versus Berkeley argument is: when is AT&T >going to put in a more advanced filesystem and memory management? In SVR4. >But give me job control and I can live with it. In SVR4. -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,pyramid}!mips!rogerk 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@servitude.mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) +1 408 991-7802 "Committing a gross indecency shows you do things in a big way." - J. Broughton
guy@auspex.auspex.com (Guy Harris) (04/02/89)
>My addition to the SysV versus Berkeley argument is: when is AT&T >going to put in a more advanced filesystem and memory management? S5R4. >Running large applications on BSD machines is much less painful than >it is under vanilla SysV. What about it is less painful? Surely it's not just that BSD has paging, because S5 has had paging since Release 2 Version 2 on the VAX and some unknown flavor of R2, I think, on the 3B2. S5R4's VM will be derived from the SunOS 4.x VM (complete with "mmap"). >And this 14 character bugaboo and disk fragmentation is just driving me >nuts. S5R4 will support the BSD file system, 255-character file names and all. (Since the code will be derived from the SunOS code, it won't have the 8-bit-character bugaboo of the vanilla BSD version.) >But give me job control and I can live with it. S5R4 will have that as well.
aad@stpstn.UUCP (Anthony A. Datri) (04/03/89)
>S5R4's VM will be derived from the SunOS 4.x VM (complete with "mmap").
Oops, all you SVR4 sites better double your physical memory then.
--
@disclaimer(Any concepts or opinions above are entirely mine, not those of my
employer, my GIGI, my VT05, or my 11/34)
beak is@>beak is not
Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aadgwyn@smoke.BRL.MIL (Doug Gwyn ) (04/04/89)
In article <11389@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >Isn't BSD code public domain ... ? /* * Copyright (c) 1982, 1986 Regents of the University of California. * All rights reserved. The Berkeley software License Agreement * specifies the terms and conditions for redistribution. */
zjat02@cra2.uucp (Jon A. Tankersley) (04/04/89)
I seem to remember some hot notes around the time that 4.2BSD came out. Or was it 4.1. AT&T and other big companies (shudder, supporting IBM?!?!) tend to have a cleaner migration path for their customers than the 4.x step did. -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */
john@frog.UUCP (John Woods) (04/04/89)
> | BSD code is more accessable; if AT&T wants major innovations > | under SysV, they are going to have to be more easy-going > | with the sources and software hooks. > Really? I thought you had to buy a SysV source license before you > could get BSD source. Has that changed? Of course there are more > *unlicensed* copies of BSD around, that I agree. One System V (or System III, for that matter) source license gets you BSD source releases in perpetuity. Upgrading from System V Release 2.1.1.4.9.69 to System V Release 2.1.1.4.9.69.2 and each successive release thereafter is like being nibbled to death by VERY LARGE ducks. -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Remainder Khomeini!
john@frog.UUCP (John Woods) (04/04/89)
In article <601@dtscp1.UUCP>, scott@dtscp1.UUCP (Scott Barman) writes: > Speaking of licensing: > When bsd and System V are merged, will the holders of 32V licenses > still be able to get source to newer bsd versions? Or will everyone wishing > to get source have to go out and get a SV.4 licence? SunOS and System V are merging. I don't think that 4.4BSD is necessarily going to have any input from this (though it might). > Also, in the recent wave of AT&T f***ing up licensing procedures (it > used to be soooo easy), are they planning any changes for SV.4? From my notes from the System V.4.0 Software Developer Conference from last December, they are changing the licensing quite a bit, and are trying to be more flexible (but I'd wait until their actual terms come out before I'd really believe it). I have a quote in my notes where the AT&T licensing speaker stated (roughly) ``The Archer Group (now UNIX(R) International) asked for advising rights on Terms&Conditions and Pricing, since they considered SVR3 a "debacle"'' (debacle was the word used). I'd say they definitely plan to be more sensitive. They may still plan to exterminate all of their competitors with ruthless and silly licensing procedures, but they will be sensitive about it :-). (CRDS does not, of course, consider me a spokesman of their views, and any obnoxious tone observed is intended to amuse rather than insult.) -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Remainder Khomeini!
rbj@dsys.icst.nbs.gov (Root Boy Jim) (04/04/89)
? From: Doug Gwyn <gwyn@smoke.brl.mil> ? Date: 29 Mar 89 17:07:04 GMT ? In article <3095@stpstn.UUCP> aad@stepstsone.com writes: ? -In article <4572@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: ? ->a long time, but SysV will always be more stable. ? -Let's see: svr1,svr2,svr3,svr3.2,svr4... Seems like they come out with ? -versions a lot more often. ? He said "stable", not "stagnant". I have to agree with Doug here. More releases == more bug fixes, and new features in the field faster. The same is true with SunOS, and even VMS. And hey, GNU emacs is up to version 18.53! Catman Rshd <rbj@nav.icst.nbs.gov> Author of "The Daemonic Versions"
rick@uunet.UU.NET (Rick Adams) (04/04/89)
> S5R4's VM will be derived from the SunOS 4.x VM (complete with "mmap").
Does this mean S5R4 won't run reasonably on machines with less than 8 megabytes
of memory...roc@sequent.UUCP (Ron Christian) (04/05/89)
In article <16410@servitude.mips.COM> rogerk@servitude.mips.COM (Roger B.A. Klorese) writes: #In article <29183@bu-cs.BU.EDU> madd@buit4.bu.edu (Jim Frost) writes: #>My addition to the SysV versus Berkeley argument is: when is AT&T #>going to put in a more advanced filesystem and memory management? # #In SVR4. # #>But give me job control and I can live with it. # #In SVR4. But is SVR4 going to be mature enough to use? Why should I purchase an immature, possibly buggy product from AT&T when I can get the real thing from Berkeley? Ron
ag@cbmvax.UUCP (Keith Gabryelski) (04/05/89)
To pick a nit ... In article <9972@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn <gwyn>) writes: >In article <11389@ulysses.homer.nj.att.com> ekrell@hector.UUCP writes: >>Isn't BSD code public domain ... ? > >/* > * Copyright (c) 1982, 1986 Regents of the University of California. > * All rights reserved. The Berkeley software License Agreement > * specifies the terms and conditions for redistribution. > */ /* * Copyright (c) 1980 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ Pax, Keith Ps, For those who just don't get it ... SOME of the Berkeley code (with no AT&T code in it) has been release under the above policy. Doug's header was from the code that was restricted for one reason or another. -- This article is freely ditributable under the terms of the GNU License. Keith Gabryelski ag@cbmvax.commodore.com
dwc@homxc.ATT.COM (Malaclypse the Elder) (04/05/89)
In article <52184@uunet.UU.NET>, rick@uunet.UU.NET (Rick Adams) writes: > > S5R4's VM will be derived from the SunOS 4.x VM (complete with "mmap"). > > Does this mean S5R4 won't run reasonably on machines with less than 8 megabytes > of memory... i believe that the observed 8M requirement for suns is due to the size of its window management system. if you are running a strict "standard" tty type system, you should be okay with 4M (unless of course you run large applications). i guess what i'm saying is that the kernel hasn't gotten that much larger and as long as you stay away from paging/swapping, you should be okay. this is of course, only my opinion. danny chen att!homxc!dwc
greywolf@unisoft.UUCP (The Grey Wolf) (04/05/89)
In article <9957@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <4814@macom1.UUCP> larry@macom1.UUCP (Larry Taborek) writes: >> [ a question regarding (more or less) since Berkeley has been paying >> license fees to AT&T for portions of their code, will the reverse hold >> true for AT&T WRT Berkeley? ] > > [ Doug is sure that everything is taken care of ] > > >The implied accusation of theft that lies behind your questions >is, to the best of my knowledge (and I do have some inside >knowledge) unfounded and demands an apology. Oh, and who are you to decide that it demands an apology, let alone to decide that he was making an accusation of theft? It looked to me like he was just curious about how things were going to be arranged. The fact that you work at a military organisation for the Good Ol' U S of A doesn't give you the right to chastise or condescend someone like that. Loosen up, guy! -- ...TheysaidDoyouseethebiggreenglowinthedarkhouseuponthehill?andIsaidYesIseethebiggreenglowinthedarkhouseuponthehillTheresabigdarkforestbetweenmeandthebiggreenglowinthedarkhouseuponthehillandalittleoldladyonaHoovervacuumcleanersayingIllgetyoumyprettyandyourlittledogTototoo I don't even *HAVE* a dog Toto...
friedl@vsi.COM (Stephen J. Friedl) (04/05/89)
In article <11389@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >Isn't BSD code public domain ... ? In article <9972@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > /* > * Copyright (c) 1982, 1986 Regents of the University of California. > * All rights reserved. The Berkeley software License Agreement > * specifies the terms and conditions for redistribution. > */ Hmmm, I wonder if any copyright has been violated by posting the above IN ITS ENTIRETY? Steve :-) P.S. to Doug: ":-)" means I'm kidding, just a joke, etc. -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "I do everything in software, even DMA" - Gary W. Keefe (garyk@telxon)
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/06/89)
In article <13842@sequent.UUCP> roc@crg2.UUCP (Ron Christian) writes:
Why should I purchase an immature, possibly buggy product from AT&T
when I can get the real thing from Berkeley?
Please keep such questions in talk.politics.misc, where they belong :-)
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: dhesi@bsu-cs.bsu.edugwyn@smoke.BRL.MIL (Doug Gwyn ) (04/06/89)
In article <13842@sequent.UUCP> roc@crg2.UUCP (Ron Christian) writes: >But is SVR4 going to be mature enough to use? Why should I purchase an >immature, possibly buggy product from AT&T when I can get the real thing >from Berkeley? What "real thing"? You mean really buggy, or really less functionality, or what?
friedl@vsi.COM (Stephen J. Friedl) (04/06/89)
In article <13842@sequent.UUCP>, roc@sequent.UUCP (Ron Christian) writes: > > But is SVR4 going to be mature enough to use? Why should I purchase an > immature, possibly buggy product from AT&T when I can get the real thing > from Berkeley? Hmm. You mean that from Berkeley you can get a *mature*, possibly buggy product? Hmmm. Steve :-) -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "I do everything in software, even DMA" - Gary W. Keefe (garyk@telxon)
terry@tah386.UUCP (Terry Hull) (04/06/89)
In article <52184@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >> S5R4's VM will be derived from the SunOS 4.x VM (complete with "mmap"). > >Does this mean S5R4 won't run reasonably on machines with less than >8 megabytes of memory... I just came from a meeting of the University UNIX User's Group and one of the thigs AT&T presented there was an overview of SysV R4.0 and 4.1. They said that the kernel size had not increased significantly on the 3B2 from R3.2 and it would run with no major performance problems in a 4 MB machine. The nice thing about R4.0 is many of the new features are optional. If you don't want them, don't link them into the kernel. -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: rutgers!ksuvax1!eecea!tah386!terry
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (04/06/89)
In article <13842@sequent.UUCP> roc@crg2.UUCP (Ron Christian) writes: | But is SVR4 going to be mature enough to use? Why should I purchase an | immature, possibly buggy product from AT&T when I can get the real thing | from Berkeley? Really old and still buggy? Seriously, any new release will have a few warts, what's new about that? Having seen 4.2, Ultrix3.0, and V.3 come out I would say that there is not much to choose. My personal experience was that the bugs in V.3 didn't crash the system or corrupt the files in most cases, and that there were more avoidable bugs. I think that the testing of this will be *very* carefully done, since this is AT&T/Sun's flagship against OSF. Please let's not discuss AT&T vs. OSF again, just making the point that there is an incentive to get this one really right. -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me