guy@gorodish.Sun.COM (Guy Harris) (01/27/88)
(Redirecting to comp.unix.wizards; at this point it has far more to do with UNIX than C++.) > >I specifically asked Bill Joy about the merging of incompatible Unix > >features at the Sun Convention, and he stated that all the design > >specification work had already been done. Specifically, Sockets are > >to be replaced by Streams, and BSD job control is to be cleaned up. > > While I agree with these two cases, I sure hope that whatever is > done will track the POSIX FIPS (and ANSI C) specs. Otherwise we > really won't care what the system is like, we won't be buying any. I don't know why people fear that the merged UNIX would *not* do either of those. For instance, a lot of the cleanup of BSD job control will probably be adoption of POSIX job control.... (Disclaimer: I do not speak officially here for AT&T nor for Sun.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/30/88)
In article <40109@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >> >... Bill Joy ... stated that all the design >> >specification work had already been done. >> I sure hope that whatever is done will track the POSIX FIPS (and ANSI C) specs. >I don't know why people fear that the merged UNIX would *not* do either of >those. >(Disclaimer: I do not speak officially here for AT&T nor for Sun.) Ok, here's why people might worry. How can the design specification work be "done" and the design still track an evolving standard that has NOT yet been "done"? We also haven't heard the intention of complying with the standards from the particular crop of people involved with this project, and I don't think they've been reported as stating that as one of the project goals. The ones who reassured us about this previously do not seem to be involved this time. (For example, the related question, "Does this mean that the merged Xenix/System V is also going to have the SunOS stuff in it, or will the result be two separate, different System V products?", hasn't been answered publicly by an official spokesman, to the best of my knowledge.) Of course it would be pretty stupid for the AT&T/Sun merged OS project to not track the standards, but they haven't been immune from stupidity in the past.
guy@gorodish.Sun.COM (Guy Harris) (01/30/88)
> Ok, here's why people might worry. How can the design specification > work be "done" and the design still track an evolving standard that > has NOT yet been "done"? I have no idea whether Bill Joy is being correctly quoted or, if he is, to what he is referring when he says that "the design specification work had already been done." I can state, however, that the design specification for the merged UNIX has *NOT* been "done" in the sense that the procedural interface is cast in concrete; design of this interface is currently in progress. > We also haven't heard the intention of complying with the standards from > the particular crop of people involved with this project, and I don't think > they've been reported as stating that as one of the project goals. I believe that it has been publicly stated, in at least some forums, that POSIX, NBS FIPS, and X3J11 compatibility *are* goals of the merged system. Whether it has been so publicly stated or not, this is the case. (Of course, if any of those standards are not in their final form in time to incorporate them into the system, these goals may not be achieved, but that's another matter.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) (01/31/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> >Of course it would be pretty stupid for the AT&T/Sun merged OS >project to not track the standards, but they haven't been immune >from stupidity in the past. I believe the following comment is beyond idle chatter but I'd rather not get into quoting names etc. Basically the standards committees have spent most if not all their time standardizing Unix as it existed in 1978 with a few new items thrown in here and there (some of which were very important, I don't mean that to be disparaging, just that the vast majority of the efforts are devoted to relatively old stuff.) There's nothing wrong with this, but there's nothing particularly inspired or useful about it either. Very little to none of the effort has been dealing with issues like networking, remote file systems, windowing etc, aka "modern needs". This is not a damnation, it is simply a statement of fact that on the one hand standards committees tend to focus on old, well-trod ground while something as dynamic as the Unix industry desperately needs acceptable industry standards in these new areas fast, even if they're only based on widely accepted de-facto standards (eg. TCP/IP, NFS, X, NeWS), or they're dead. I believe some folks at Sun and ATT recognized this fact and decided to plow ahead with a bold super-set of what the standards committees were working on, determined to present to the industry these badly needed standards so we could move on to other things quickly. Sometimes this works, sometimes it doesn't (Unix itself could be considered such a bold venture for its time, I'm quite sure any standards committee of its time would never have approved C as an implementation language, for example, they only have eyes in the backs of their heads, as they probably should, and surely would have considered the issue of a SIL wide open, Bliss, Algol variants, PL/I etc, as many of you are right now saying to yourselves "but, but, but whaddabout...", yet to many of us who were around then Unix was obviously a much needed standard the first day we got it out of the box and got past Irma Biren's nice cover letter.) I have no doubt that many are frantically clinging to the concept that many of these issues such as networking protocols are still wide-open and shouldn't be standardized on something like TCP/IP. Be that as it may, but nothing else really exists (eg. you can't say ISO exists, whether it ever will exist remains an open question) and the rest of the world needs to get on with things and be able to assume that these are standards so those "nuisance little things" called applications can be written. Their adoption by Sun and ATT (not to mention de facto adoption by dozens of other vendors) ensures that they cannot be way off the mark, reality is its own excuse. Let's codify them and get on with the show, I say. So the issue is not entirely whether or not the ATT/Sun merge tracks standards as it purports to standardize areas that no current standards area seems to even be addressing. Obviously this could cause some incompatibility with standards as they are being written unless the standards are powerful enough to support these expanded needs. I suspect the tendency will be to try to do no worse than superset (there's a fine line between supersets and incompatibility.) Personally, I consider the ATT/Sun merger a welcome and long overdue kick in the ass. -Barry Shein, Boston University P.S. Again, this is not anyone's official policy, just the situation as I understand it.
gnu@hoptoad.uucp (John Gilmore) (02/02/88)
One reason that a merged Unix might not track the standards is if the
standards themselves do not track. There are still incompatabilities
between ANSI C and POSIX (last I heard), and standards committees have
a long track record of producing botched products -- I trust Bill Joy
and Guy Harris and the folks who implement it *as* they write it,
a lot more than I trust committees who write it and later see if it
really works. The busted "multi volume tar" stuff from the POSIX
standard is a great example of camel design by committee.
On the business aspects of the merger, there's a big article in the SF
Chronicle Business section today about "Sun Micro's New Forays Unsettle
Competitors", by Don Clark of the Chronicle. Mostly it explains the
stuff we all know, but:
"Representatives of 15 major computer makers flew to New York to
meet with Vittorio Cassoni, president of AT&T's computer operations.
Not all were reassured.
"`Frankly, the concerns I walked in with I still have,' said
Barbara Shelhoss, Apollo Computer's representative at the meeting.
..."After AT&T's investment with Sun was announced in early
January, the critics gathered in secret at Digital Equipment's Palo Alto
offices. Signatories to a resulting telegram of protest included chief
executives at HP, Tandem Computer, Prime, and Apollo.
"`If there hadn't been an equity stake, nobody's antennae would
have gone up,` said Robert Miller, chief executive of Mips Computer
Systems, who also signed the letter.
..."Some of the critics have suggested fielding a rival Unix
development team, though they would much rather be guaranteed input in
the Sun-AT&T effort.
"`The idea of having one Unix coordinated by AT&T is a major
advantage for the entire industry,' said Ed McCracken, chief executive
of Sun rival Silicon Graphics Inc."
Here's my two cents on the issue (disclaimer: I was emp #5 of Sun,
though I've been gone more than two years). DEC, HP, Apollo, etc were
happy with AT&T controlling Unix when it was clear AT&T was not a
competitive threat. AT&T's inability to sell computers is legendary.
In a tighter partnership with Sun, AT&T might actually be able to make
money at computers, which would give the protesters a major competitor
rather than a pussycat.
DEC, HP, and other major players have certainly had to watch Sun as a
competitor, but the threat was limited by Sun's ability to grow,
increase manufacturing volume, and find new distribution channels.
With AT&T capital, marketing, and distribution channels, they can't
afford to treat Sun as a minor player any more.
Had AT&T come up to them with an offer to buy 20% of their companies,
they probably wouldn't be yelling. But they didn't pick up the ball
with Unix and run as far or as fast as Sun did. I can't see AT&T
coming to HP to define the new Unix standard, I mean HP/UX is probably
OK but it's not worldshaking. Ditto Ultrix. Apollo has been working
hard to cram Unix into their OS but it's still not Unix. These
companies have concentrated on locking their customers into the
existing hardware & software base, not in opening their systems to
innovation and competition, or on enhancing "what is Unix and what it
provides".
Sun has not only defended and expanded the BSD "territory" against
AT&T, while just about everybody else was knuckling under to AT&T's
"consider it standard" marketing blitz, but has also pushed the state
of the art of Unix networking and graphics. Not to mention having the
design sense, technical ability, and skilled negotiation to produce a
merged SV/BSD Unix, ending the years-long split, rather than a "dual
port" or a Unisoft-like mishmash. AT&T showed uncommon sense in
teaming up with Sun, the only company in the Unix market able and
willing to beat them technically.
Considering some of the other companies AT&T bought once it got
de-reg'd, Sun may be its best investment so far.
In summary, I think the 15 companies are bitching because the AT&T/Sun
partnership is a strong competitor.
And a standard for Unix binaries for a particular chip line is a great
idea, which should've happened in 1981 for the 68000, but didn't. That
Sun remembered to do it for the SPARC should bring them roses, not
thorns. This doesn't hurt anybody. One would hope that HP/UX
applications that run on various Spectrum models are all binary
compatible, but of course it doesn't matter to the outside world since
they don't license Spectrum implementations to outsiders. So is their
complaint that Sun is giving away the SPARC design?
I heard that DEC got Tektronix out of the workstation market by
threatening to stop buying Tek graphics terminals -- DEC was their
biggest customer. Maybe the 15 whiners should threaten to switch to
MCI for phone service :-) and see if AT&T responds.
If they are concerned about basing their products on AT&T/Sun-controlled
Unix, why don't they fund the GNU project, like they're funding the X
project, so they and the world can all share a non-AT&T-licensed
Unix like system? A major open-systems effort is probably the right
medicine, if they are feeling a bit green around the gills. This could
even impact the ABI stuff -- who would buy ABI applications in binary
when they could get full sources of a GNU-based Unix?
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
"Watch me change my world..." -- Liquid Theatrereggie@pdn.UUCP (George W. Leach) (02/02/88)
In article <11558@brl-adm.ARPA> bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) writes: >From: Doug Gwyn <gwyn@brl-smoke.arpa> >>Of course it would be pretty stupid for the AT&T/Sun merged OS >>project to not track the standards, but they haven't been immune >>from stupidity in the past. [Barry's discussion concerning the needs to address various "Modern Needs" deleted.....] >Personally, I consider the ATT/Sun merger a welcome and long overdue >kick in the ass. > -Barry Shein, Boston University Clap, clap, clap!!! I agree! For several years I participated in a task force at Bell Communications Research where we had been charged with the mission of establishing a UNIX Standard Operating Environment. I felt that for the most part, we were not going to dictate to vendors what features to include in their UNIX offerings. It also seemed obvious that many vendors, starting with Pyramid's OSx, were offering dual ports of BSD and System V flavored UNIX. To me this indicated that the two had to be merged some day in order for UNIX to survive and thrive in the future. This action by Sun and AT&T is simply the logical extension of this work. They are for the most part the two main proponents of the two strains of UNIX. Who else should do this? A committee? I think we can all agree that any language or OS that is designed by committee is destined to fail due to the politics involved. The key here is what AT&T and Sun will do to ensure that the rest of the industry will go along with them. -- George W. Leach Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826
roskos@csed-1.UUCP (Eric Roskos) (02/02/88)
In article <11558@brl-adm.ARPA>, bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) writes: > Basically the standards committees have spent most if not all their > time standardizing Unix as it existed in 1978 with a few new items > thrown in here and there ... > Very little to none of the effort has been dealing with issues like > networking, remote file systems, windowing etc, aka "modern needs". > [Additional discussion of philosophies of standardization] One thing to realize is that a standard that is too large and complex is not likely to be accepted. If standards are to tell people how to build something (rather than just telling them to accept some existing product as the standard), they have to be simple enough for people to be able to build things to meet the standard. In terms of the "modern needs" above, how much of that is *really* necessary? For example, for remote file systems you'd ideally like them to look, to the user, like a local filesystem (with possibly a small number of maintenance services added, but independent of the normal filesystem services). Likewise for windowing (an opinion based on experience with the Macintosh, although I am expecting that discussion of this issue will reemerge when OS/2 and its Presentation Manager come out, given experience also with programming under Windows). If you accidentally standardize a lot of low-level features that turn out to be unnecessary, you end up severely limiting future growth. As for networking, issues of protocols should not show up in a mainline Unix standard, should they? This is not to say someone should not standardize network protocols (and of course that is being done), rather that they should not tie in with Unix at the level the current standards groups are working. The point being, standards *should* be kept simple, the way the 1978-era Unix was kept simple. That's the only way you can keep the growth of complexity under control. -- Eric Roskos, IDA (...dgis!csed-1!roskos or csed-1!roskos@HC.DSPO.GOV) "Only through time time is conquered." -- Burnt Norton
reggie@pdn.UUCP (George W. Leach) (02/04/88)
In article <3991@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >DEC, HP, and other major players have certainly had to watch Sun as a >competitor, but the threat was limited by Sun's ability to grow, >increase manufacturing volume, and find new distribution channels. >With AT&T capital, marketing, and distribution channels, they can't >afford to treat Sun as a minor player any more. > Most of the companies that are complaining are the same ones that really never wanted to get involved with UNIX at all. DEC would much rather you use VMS and they have in the past bad mouthed ULTRIX and recommend VMS! These companies are being forced by market demand to go with UNIX and they don't like it. Having one, unified version of UNIX will only compound their difficulties in selling proprietary solutions. Sun and AT&T are viewed as the major proponents of BSD and System V flovored systems. Who better than them to oversee and direct the melding of the two into one system? Both companies can draw upon people who were originally involved with BSD and System V. POSIX is not the answer. A real, breathing, working system is! -- George W. Leach Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826
terryl@tekcrl.TEK.COM (02/04/88)
In article <3991@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > > Delete MANY lines about Sun/ATT merger, and UNIX's future, most of which I > heartily agree with.... > >I heard that DEC got Tektronix out of the workstation market by >threatening to stop buying Tek graphics terminals -- DEC was their >biggest customer. Maybe the 15 whiners should threaten to switch to >MCI for phone service :-) and see if AT&T responds. Whoa, there, Mr. Gilmore. Not entirely true, but almost just true enough that I'll let it slide. There was some DEC influence, but I'd have to say it was VERY MINOR. There were MANY more reasons, which unfortunately I can't divulge do to impropriety, etc. But to say DEC got Tektronix out of the work- station business is stretching it, just a tad. Terry Laskodi of Tektronix, Inc.
jsq@longway.TIC.COM (John S. Quarterman) (02/04/88)
NBS is also doing some interestingly fast stuff, in their varous FIPS. I imagine they'll be present at UniForum and USENIX next week.
bzs@bu-cs.BU.EDU (Barry Shein) (02/05/88)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) (Responding to a note from Eric Roskos) Actually, I disagree. >In terms of the "modern needs" above, how much of that is *really* >necessary? For example, for remote file systems you'd ideally like them >to look, to the user, like a local filesystem (with possibly a small number >of maintenance services added, but independent of the normal filesystem >services). Likewise for windowing (an opinion based on experience with >the Macintosh, although I am expecting that discussion of this issue >will reemerge when OS/2 and its Presentation Manager come out, given >experience also with programming under Windows). If you accidentally >standardize a lot of low-level features that turn out to be unnecessary, >you end up severely limiting future growth. Remote file systems are a tough example because their goal of course is transparency (ie. support all Unix system calls precisely as the local disk does.) Unfortunately in practice there are these "little" nits (eg. statelessness vs statefulness, perhaps new error codes or mount options), I suppose one could come up with an abstract super-set, so let's leave all that for a moment. The real issue is from the vendor's point of view. Sure I can deliver any reasonably transparent remote file system software, ok, here I am with my WHIZBANG1000 just out of hardware engineering. Which remote file system do I put on it? If I want to support a remote file system I have to pick one, the fact that they're all roughly alike and don't interoperate is a problem, not a solution. If one is standard and is even right on the source tape, hmm, maybe... Windowing I think is an easy issue to respond to. It's critical. Again, you're a vendor, you're planning an interactive software product which could use windows effectively. What do you choose to code? You don't want to code all of them, you have to choose one. To improve marketability you want to choose something standard. In fact, this particular issue is so bad that the truism going around (which may very well be true, I don't know) is one reason you don't see products like Excel on Unix workstations is simply that they're waiting until Unix presents a standard window interface so they can port their code once and just sell it, not port it over and over again to everyone's new idea on how to arrange little boxes of 1s and 0s on a tube. Absolutely critical. >As for networking, issues of protocols should not show up in a mainline >Unix standard, should they? This is not to say someone should not >standardize network protocols (and of course that is being done), rather >that they should not tie in with Unix at the level the current standards >groups are working. Why not? In the first place, a standard just says you should support this to claim you are standard, not that you don't have anything else, so it shouldn't limit anyone other than the time and trouble to get the standard working correctly (if it's truly a successful standard the effort should be worthwhile.) Something like networking ripples to other parts of the system, like remote file systems and windowing software (although most can work with any byte stream, they still need to use a standard stream interface to interoperate, you still have to pick one.) What's the problem anyhow? TCP/IP is a de facto standard, almost all vendors offer it as a primary product anyhow, it's available, it works etc. Let's put it into the standard and onto the source tape and go on to other things. If something else comes along we'll argue about it then. You're not burning bridges with standards, you're saying there is a way across the river even if a better bridge comes along later. -Barry Shein, Boston University
dce@mips.COM (David Elliott) (02/05/88)
In article <2184@pdn.UUCP> reggie@pdn.UUCP (George W. Leach) writes: > Most of the companies that are complaining are the same ones that >really never wanted to get involved with UNIX at all. DEC would much >rather you use VMS and they have in the past bad mouthed ULTRIX and >recommend VMS! These companies are being forced by market demand to >go with UNIX and they don't like it. Having one, unified version of >UNIX will only compound their difficulties in selling proprietary >solutions. What do you mean "most"? You name one company out of the list of "complaining" companies, and you call it "most"? My view of this (which is obviously somewhat biased) is that nobody has a problem with a unified system, but that they have a problem with the unifiers being such strong competition. Look at how a new version of System V (like release 3.1) is distributed. You can get a 3B2 source distribution *after* AT&T makes it available to all customers. Then, you can pour resources into getting your system together and hopefully not have this be an issue with your customers. One of the problems I have with having Sun and AT&T doing all of the merging is that I have to wait until they are finished before I can do any of the work. If Sun and AT&T are willing to send me all of their changes as they make them, and allow me to send them my fixes and use them, I can get my software ready to release when they release theirs. One of the great things about BSD Unix is that it wasn't Berkeley people developing a system by themselves. A lot of people sent in bug fixes and new programs and helped develop the ideas. POSIX and X/Open keep this kind of thing alive. Hasn't AT&T learned their lesson about monopolies yet? (NOTE: The opinions expressed herein are MINE, and not those of Mips Computer Systems, Inc.) -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
weiser.pa@xerox.com (02/09/88)
In article <foo> Eric Roskos <roskos@csed-1.uucp> writes: > One thing to realize is that a standard that is too large and complex is > not likely to be accepted. Which is one of the serious problems with the Sun/AT&T merge: can a standard that has both NFS and RFS, and both X and NeWS, be all that simple? The Phase III version might be great, but I'm not holding my breath waiting for phases I and II. -mark
martin@kuling.UUCP (Erik Martin) (02/10/88)
In article <262@csed-47.csed-1.UUCP> roskos@csed-1.UUCP (Eric Roskos) writes: > >One thing to realize is that a standard that is too large and complex is >not likely to be accepted. If standards are to tell people how to build >something (rather than just telling them to accept some existing product >as the standard), they have to be simple enough for people to be able >to build things to meet the standard. > On the other hand, too small a standard is not accepted as is. People start to ship standard products with non-standard extensions so we end up with a multitude of almost compatible implementations. A standard must be *large* enough to be accepted as it is. -- ((Per-Erik Martin, Computing Science Dept., Uppsala University, ) (Box 520, S-751 20 Uppsala, Sweden ) (UUCP: martin@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!martin)))
henry@utzoo.uucp (Henry Spencer) (02/17/88)
> Which is one of the serious problems with the Sun/AT&T merge: can a standard > that has both NFS and RFS, and both X and NeWS, be all that simple? ... An observation occurred to me at Usenix: the problem with the people who talk about bringing SysV and BSD together is that they don't want to narrow the gap between the two, they want to fill it in. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
dcw@doc.ic.ac.uk (Duncan C White) (02/18/88)
In article <632@kuling.UUCP> martin@kuling.UUCP (Per-Erik Martin) writes: *In article <262@csed-47.csed-1.UUCP> roskos@csed-1.UUCP (Eric Roskos) writes: *> *>One thing to realize is that a standard that is too large and complex is *>not likely to be accepted. If standards are to tell people how to build *>something (rather than just telling them to accept some existing product *>as the standard), they have to be simple enough for people to be able *>to build things to meet the standard. *> * *On the other hand, too small a standard is not accepted as is. *People start to ship standard products with non-standard extensions *so we end up with a multitude of almost compatible implementations. *A standard must be *large* enough to be accepted as it is. * I am reminded of Albert Einstein's famous suggestion: Make things as simple as possible, but not simpler... >-- >((Per-Erik Martin, Computing Science Dept., Uppsala University, ) > (Box 520, S-751 20 Uppsala, Sweden ) > (UUCP: martin@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!martin))) Duncan ---------------------------------------------------------------------------- Duncan White, | Flying is the art of aiming oneself Dept. Of Computing, | at the ground and missing. Imperial College, | -- Douglas Adams, So Long and Thanks London SW7, England | for all the fish.
benoni@ssc-vax.UUCP (Charles L Ditzel) (02/19/88)
In article <1988Feb16.182913.226@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > An observation occurred to me at Usenix: the problem with the people who > talk about bringing SysV and BSD together is that they don't want to narrow > the gap between the two, they want to fill it in. An observation occurred to me last night :) the problem with the people that are know griping the most about AT&T and Sun bring SysV and BSD together are the people that would have sold you their very own closed systems yesterday. :^) (Did you also notice that their the companies that don't have a large marketshare in the workstation market OR they are losing market share REAL fast!!) Like DEC and Apollo...(Funny DEC and Apollo didn't complain when Mr. Joy gave them BSD 4.[23]... :^) --------------------------------------------------------------------------- The Opinions expressed are my own. No one else would have them. :)
mash@mips.COM (John Mashey) (02/22/88)
(I ESPECIALLY SPEAK FOR ME ONLY!) In article <1684@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: ... >An observation occurred to me last night :) the problem with the people that >are know griping the most about AT&T and Sun bring SysV and BSD together are >the people that would have sold you their very own closed systems yesterday. >:^) This is a drastic over-simplification of a complex issue, which is NOT a protest of merging BSD & SYSV, which after all, has been done by various parties before. Having been involved in a number of the relevant meetings, I can't really say much. I would say that more the real issues have been surfaced, and attempts are being made to deal with at least some of them by the appropriate parties. The issues are complicated, and there are many involved, all with different agendas; by the time things filter thru the press, it is VERY hard to know what's going on, and almost anything you see printed is probably at best a partial story! >(Did you also notice that their the companies that don't have a large >marketshare in the workstation market OR they are losing market share >REAL fast!!) >Like DEC and Apollo...(Funny DEC and Apollo didn't complain when Mr. Joy >gave them BSD 4.[23]... :^) Some of this might be rewriting history: I was under the impression that a number of people had contributed to 4.X BSD, and in fact, had included some people who at the time worked for DEC. I also thought DEC contributed in other ways; could somebody closer to this clarify that impression? -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
benoni@ssc-vax.UUCP (Charles L Ditzel) (02/23/88)
In article <1645@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: > In article <1684@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > >An observation occurred to me last night :) the problem with the people that > >are know griping the most about AT&T and Sun bringing SysV and BSD together > >are the people that would have sold you their very own closed systems > >yesterday. > This is a drastic over-simplification of a complex issue, which is NOT Of course it is. But there just happens to be alot of truth to it. There are certainly two sides to this issue. Both Apollo, DEC and the other companies involved have a vested interested in all this. Apollo (according to the trade rags) is losing ground quite rapidly in the workstation market. the year before things were pretty even between Apollo & Sun. Last year Apollo's share had dwindled to 19% while Sun was up to about 28%. Meanwhile DEC is trying to become a major player. The posturing and alliances that are going on now has high stakes for the companies involved. I don't think anyone is going to convince me that DEC and Apollo would not just as soon sell you VMS and Aegis (respectively). > >Like DEC and Apollo...(Funny DEC and Apollo didn't complain when Mr. Joy > >gave them BSD 4.[23]... :^) > > Some of this might be rewriting history: I was under the impression that > a number of people had contributed to 4.X BSD, and in fact, had included some Before you take this last comment TOO seriously note that their is a :^) on it...(obviously Mr. Joy was not the only person involved, i suppose humor is a matter of perspective :^). -------------- Naturally my ideas are my own, since no one else would have them.
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (02/24/88)
In article <1684@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > > Like DEC and Apollo...(Funny DEC and Apollo didn't complain when Mr. Joy > > gave them BSD 4.[23]... :^) In article <1645@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: > Some of this might be rewriting history: I was under the impression that > a number of people had contributed to 4.X BSD, and in fact, had included some > people who at the time worked for DEC. I also thought DEC contributed in > other ways; could somebody closer to this clarify that impression? Bill Joy had a great deal to do with 4.2BSD, my understanding (worth what you're paying for it, I wasn't there) is that much of the design was his, and the implementation was done with Sam Leffler. He had little, if any, direct input into 4.3BSD. DEC has contributed the full-time services of four people, at various times, to the BSD effort; both DEC and SUN have made significant contributions to BSD software. --keith
rick@seismo.CSS.GOV (Rick Adams) (02/24/88)
The "Preface to the 4.2 Berkeley distribution" which is printed at the front of the manual set credits: Bill Shannon (DEC & Sun) Robert Elz (U of Melbourne) Rob Gurwitz (BBN) Eric Allman (Britton-Lee) Bill Croft (SRI & Sun) Dennis Ritchie (Bell Laboratories) Helge Skrivervik (no affliation) and of course "numerous others". That acknowledgement is signed by (note the order): Sam Leffler Bill Joy Kirk McKusick There are others who are credited with earlier 4bsd releases. ---rick (Yes, some of the people on the above list do get annoyed when Bill Joy is credited with developing 4.2bsd UNIX and no one else is mentioned)