devine@cookie.dec.com (Bob Devine) (03/08/88)
I've stayed on the side in this latest Battle of the Network Flamers of VMS vs Unix because I've been properly inculcated with the notion that I can't speak for DEC. But since they are now buying my beer, let me state the facts. All the information stated below has been publicly expressed; I'm just repeating it. Approximately 10% of all VAXen sold run Unix (or variations). This number has been consistently at this level for quite a while. Workstations are currently at about the 30% level. DEC has decided that it is in its best interest to offer Unix as well as VMS. To that end, an equal amount of development funds and people are now devoted to each OS. DEC has also stated that in the future new developments will be made available to both OSs. For the future, DEC is behind POSIX. Not some vendor-specific version of Unix that would be closed to others (subtle, aren't I?).
sullivan@vsi.UUCP (Michael T Sullivan) (03/09/88)
In article <8803071927.AA02829@decwrl.dec.com>, devine@cookie.dec.com (Bob Devine) writes: > For the future, DEC is behind POSIX. Not some vendor-specific version > of Unix that would be closed to others (subtle, aren't I?). As opposed to the open VMS standard backed by millions of vendor-types? -or- Yeah, I know what you mean. Next thing you know, DEC will want to change VMS without letting everybody in on it! -- Michael Sullivan {uunet|attmail}!vsi!sullivan {ucbvax|ihnp4|sun}!amdcad!uport!vsi!sullivan HE V MTL sullivan%vsi.uucp@uunet.uu.net
devine@cookie.dec.com (Bob Devine) (03/11/88)
I wrote: > For the future, DEC is behind POSIX. Not some vendor-specific version > of Unix that would be closed to others (subtle, aren't I?). Michael Sullivan replied: > As opposed to the open VMS standard backed by millions of vendor-types? > Yeah, I know what you mean. Next thing you know, DEC will want to change > VMS without letting everybody in on it! Yes, VMS is a proprietary OS; I never said it wasn't. The discussion is on the future direction of Unix. Should it be an open standard or should it be controlled by AT&T? As we get closer to final approval of the Posix standard, AT&T seems to be regretting letting the Genie out of the profitable bottle. Each new version of System V has become more onerous, why? The AT&T reps to Posix have now voted against final approval, again why? Bob Devine
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/12/88)
In article <8803101924.AA03437@decwrl.dec.com> devine@cookie.dec.com (Bob Devine) writes: >Should it be an open standard or should it be controlled by AT&T? "False dichotomy." It could be both, or this may not even be the most important issue. > As we get closer to final approval of the Posix standard, AT&T >seems to be regretting letting the Genie out of the profitable bottle. >Each new version of System V has become more onerous, why? I don't know what you mean by this. SVR3.0 incorporated tremendous improvements that should be of great value to future UNIX users. In particular, STREAMS is an extremely important technology. The file system switch is also important, but more to implementors than directly to end users. SVR3.0 is the first AT&T UNIX system release that I would rate as technically the equal of, or superior to, 4.nBSD on all major counts. SVR3.1 appears to have continued the tradition of removing unnecessary constraints that got in the way of international use of UNIX. SVR4.0, from what I have heard, will continue the tradition of merging in those features of 4.nBSD that people find most useful. What is onerous about all this? If you refer to the requirement that VARs advertising their systems as UNIX System V conform to the SVID, why is that a problem? It's exactly what many customers want, and what has been specified in many government procurement actions. While on this topic, the NBS-proposed POSIX-based FIPS is by no means a suitable replacement for the SVID; it does not provide nearly as comprehensive and "crisp" a specification as the SVID does; therefore it does not meet end-user needs nearly so well. When asked, my recommendation is always to supplement POSIX in the specs with ANSI C and SVID requirements, in such a way that conflicts among the requirements have a well-determined resolution. >The AT&T reps to Posix have now voted against final approval, again why? Presumably, like more than a quarter of the balloting group (how many more I don't know), they found unacceptable technical errors in Draft 12 of IEEE Std 1003.1. There is going to be another recirculation round of a new draft of the proposed standard; perhaps the problems will be fixed so that AT&T representatives, the USENIX representative (who is a well-known supporter of the 4.nBSD UNIX variants), I, and others could change our negative ballots to favor adopting the new draft as the final-use standard. Please, if you're going to push the DEC "party line", don't misrepresent the actual situation (such as implying that AT&T representatives are trying to torpedo POSIX); when exposed, it unduly weakens your case.
gore@eecs.nwu.edu (Jacob Gore) (03/14/88)
/ comp.unix.wizards / lynn@engr.uky.edu (H. Lynn Tilley) / Mar 6, 1988 / >[...] let me fully acknowledge DEC's progess >in this area. Their development system is good and it is getting >better. But it is costly. I just got a package of glossy sheets, called VAXset: VAX Software Engineering Tools (by the way, DEC people: note the VAX=VMS implication). Being a person who not only uses this kind of stuff regularly, but who also has to regularly convince people who write out checks that the stuff is worth the money, I built a table of sorts in my mind that compares these tools with similar tools in the Unix world (ours is BSD-tilted), and their costs. Let me write it down: VMS world Unix world 1. VAX Language Sensitive Editor. GNU Emacs with language modes (and other Emacses -- but we use GNU). Based on TPU. Support for languages Freely distributable. Runs is distributed with each compiler. on 36 different machines. Language Users will only see it on VAXes. modes are contributed by users. 2. VAX Source Code Analyzer. No obvious equivalent. Some function- ality provided by "tags" facilities for Claimed to be most effective when Emacses (or for vi). Some functionali- used together with LSE (#1). ty provided by various "calls" facili- Users will only see it on VAXes. ties, but those are usually language- dependent. 3. VAX DEC/Code Management System. RCS. Well-connected with other VMS soft- Freely distributable. Separate soft- ware from DEC: interfaces with Ada ware, so easy interfacing with other libraries, LSE (I think), etc. programs (such as 'make') is not Users will only see it on VAXes, guaranteed. Also SCCS, which comes though they are likely to see similar bundles with Unix (generally). tools on other systems. 4. VAX DEC/Module Management System. Make. Interfaces with libraries, CMS. Some versions interface with Users will only see it on VAXes, libraries, RCS and/or SCCS. Comes though they are likely to see similar bundled with Unix, some versions tools on other systems. are freely distributable. 5. VAX Performance and Coverage Analyzer. Gprof. An execution profiler. Can handle Sometimes comes bundled with Unix. such things as Ada tasks. Users will Users are not likely to see it on only see it on VAXes, though they may systems that are not BSD-based and t worth that much money -- perhapssee similar tools on other systems. do not have a continuous-memory model. 6. VAX Notes. Notes or news/rn/vn/etc. A bulletin board system. Well-inte- Freely distributable. Several choices grated into VMS environment. Only of software. Interfaces with Usenet. works on local host or across DECNet. Very wide readership. Not interfaceable with Usenet. 7. VAX DOCUMENT. Well, it looks like you'd get this if you let troff handle a few more Appears to be a markup language for fonts, or crippled TeX or ditroff typesetting. Supports "a variety of into device dependency. My choice Digital laser printers" (haha), but is TeX, and it is freely distributable. seems to be able to generate post- script (for LPS40, at least). 8. VAX SCAN. Oh, God... awk, perl, sed, lex, ... Something like 'awk', it seems. Bundled with Unix and/or freely dis- tributable. 9. VAX DEC/Test Manager. None come to mind. A regression test manager. 10. VAX Software Project Manager. None come to mind. Not a bad collection of tools. Sticking a "CASE" label on it is an overkill. Seems like the term "CASE" is becoming as useful as the term "MIPS" -- when you see it on a sales sheet, just white it out: you'll make the page less crowded, and won't lose any useful information. BBBBBBBBBBBBUT -- what does it cost? I don't have the latest prices handy, but last I checked CMS alone (that's the RCS equivalent) cost US$8,000, and MMS (that's make) was $2,000. I doubt if any of these tools cost less than $2,000. So, I'd guesstimate that if I wanted all of these, I'd pay about $20,000 to $30,000 dollars, depending on how much cheaper it is to get them in "kits" -- and that is PER MACHINE! (I know that hypothetically, if every computer on this campus was a VAX, many in clusters, and they all ran VMS, it would be cheaper, but that is not reality.) Now, I'm not saying that these tools are not worth the money -- they probably are. But they (except DOCUMENT) support only one specialty on campus: software development. If I was making this choice for a software development company, this cost would be of low importance. But this is a university. We have so many different interests here, that we just cannot afford to purchase Caddilac-level tools for each one. Besides, tools that we get for free, or at nominal cost, are often at least as good, if not better. So, to people who are considering to go VMS-only on their campus (sorry, this discussion has been so long, that I can't trace its source anymore :-), I say: Go for it, if you have very rich and generous alumni. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,ihnp4}!nucsrl!gore
allbery@ncoast.UUCP (Brandon Allbery) (03/22/88)
As quoted from <8120009@eecs.nwu.edu> by gore@eecs.nwu.edu (Jacob Gore): +--------------- | VAX DEC/Code Management System. RCS. | | Well-connected with other VMS soft- Freely distributable. Separate soft- +---------------------------------------^^^^^^^^^^^^^^^^^^^^ ...but requires a source code license, since it includes 4.xBSD diff sources modified for RCS. This leaves binary ncoast out in the cold, with SCCS which is nowhere near as nice to use. (If this has changed, someone please tell me so I can get my hands on it!) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery