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
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) --
bader+@ANDREW.CMU.EDU (Miles Bader) (03/27/89)
cat.cmu.edu!jps@pt.cs.cmu.edu (James Salsman) writes: > 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. Actually, it's been ported (or mostly so) to AIX (ibm sysv), but I don't know how this relates to vanilla sysv.
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
chris@MIMSY.UMD.EDU (Chris Torek) (03/28/89)
You need only a 32V license to get Berkeley source. Of course, AT&T will no longer sell you a 32V license; fortunately, a SysVR<any> license is also sufficient. Chris
bzs@BU-CS.BU.EDU (Barry Shein) (03/28/89)
From: steinmetz!davidsen@uunet.uu.net (Wm. E. Davidsen Jr) >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?). Yes, several vendors have enhanced their Unix systems to support parallelism, all differently...that's the problem (well, challenge, to figure out one model that is satisfactory to everyone, or at least a limited, standardized choice of models [I am hedging because, eg, SIMD vs. MIMD hardware probably requires different models.]) Mere lightweight processes is not sufficient (and may not even be necessary!*) to provide a parallel programming model, there's also scheduling and coordination among processors in the same task. In fact, it's worse than most people think (!?), it may require changes to programming languages (eg. if you want to lock a critical section you can't afford the overhead of jumping to a subroutine to do that, it leaves open a window which, with true multiprocessors, is easily smashed through, inline expansion is probably sufficient to solve that but hey, show me a C manual that defines a standard for inlining!) * For example, suppose I keep the current fork() semantics (with shared memory) but allocate all the forks (or more) I will need at the beginning of the task and immediately suspend them all (using job control) and, when I need N processes I just continue the forks I need now...suddenly fork creation overhead becomes irrelevant, no? Except for the most trivial case where I probably won't gain much with parallelism anyhow. Question everything! Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
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
bzs@BU-CS.BU.EDU (03/29/89)
From: auspex!guy@uunet.uu.net (Guy Harris) >...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. Interestingly Mach's file mapping only supports that transparency on read operations, write() still has to go through the system call interface so you get this asynchrony of being able to read a file as if it were an array of bytes (or whatever) in memory but you then have to do seek/write pairs on the underlying fd if you want to update it. The reasoning (as I heard it) had to do with maintaining consistency in a distributed environment, read consistency across machines is of course trivial but write consistency requires real work. Somehow I still felt that one didn't have mmap'ing if only that easy case was solved, not sure why they couldn't mark pages read-only and take the hit on modifies (and warn programmers that using write() might be more efficient.) You only have to take the hit once per page and only ("only!") inform the other systems with the file open that page XYZ is modified (ie. don't have to xfer the whole page, they may never need it, lazy evaluation) and set the page invalid on the other systems and xfer it if they try to access it (on a fault, or perhaps some more aggressive algorithm.) Oh what an evil web we weave when first we venture to transmit and receive! >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". The last I heard AFS was being modified to respond to NFS requests ("oh, that was an NFS-oid mount request, better remember to speak NFS to that guy.") Round and round. >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. I think the time has long passed for a completely non-proprietary source source for a UNIXoid system. Back when machines were expensive resources we had the sources but couldn't get enough downtime to really hack. Now that a machine capable of running a respectable O/S is, I dunno, like $3K (386+4MB+80MB disk), about the same as dumb CRT's back then, the sources are slipping out of our hands...unfortunate. It will change. -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
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
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
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!