Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!KEN%ORION.BITNET@cunyvm.cuny.edu From: KEN%ORION.BITNET@cunyvm.cuny.edu (Kenneth Ng) Newsgroups: comp.unix.wizards Subject: Help us defend against VMS! Message-ID: <12149@brl-adm.ARPA> Date: 5 Mar 88 22:23:47 GMT Sender: news@brl-adm.ARPA Lines: 56 >From: Dave Sill >Hah. The only thing the VMS manuals have over the man pages is bulk. >I find them exceedingly verbose. If I want to read a novel, by golly >I'll read a novel, but when I want to use a command, I want the facts. Unfortunately I am not yet fluent enough in VMS to comment on their manuals. Personally I'd rather have to wade through a lot of verbose junk to find the information I need, presuming of course that I do indeed find what I need. What I detest is documentation that lacks something that I need. What I find lack in the Unix manuals is a complete listing of the error messages and what they mean. Also lacking are all the variations. If I had the source code, I could use that, unfortunately I do not have such access. Examples are: what does error code 12 in make mean? I can't find any such mention in the man page. Also, the man page for read on timed reads do not indicate that the timed read will only work after the first character is typed. Yes I know that it is on the System 5 interface specs, but it should also be duplicated on the man page. Or at least a footnote suggesting looking into the Sys 5 interface specs. >But really, there is one difference between VMS and Unix that is so >overwhelmingly important that it just can't be overemphasized, so >I'll repeat it: VMS is proprietary, Unix is not. At any time, DEC can >make any arbitrary decisions it wants to about the future of VMS. >They could decide tomorrow to stop supporting it (of course they may >have support contracts that they have to honor). What would happen if >DEC went bankrupt? Or was bought out (however unlikely)? > >But nothing like this could happen to Unix. Unix is far bigger than >any of the vendors supporting it. Yes even AT&T has limited power to >change UNIX's destiny. A several years ago, Telenet and Uninet were two seperate companies offering x.25 packet service. We had them both here to access a computer conferencing system called EIES. Back then it was great because when one network went down, we could still be accessed through the other. We could also talk the reps into adding features and fixing bugs. Especially when we told them that the competition had those features or lacked those bugs. Now what does this have to do with Unix? A couple of years ago Telenet and Uninet merged, or one bought the other, I forgot. Since then, service has been gone downhill, since when one network went down the other went with it. And the new changes we suggested I believe have all been ignored. Therefore when I hear that Sun and AT&T are getting together, on one hand I say "It's about time", but I still remember what happened with the other merger. And reading that Apollo and other companies are worried about lockouts causes me even more concern. >So why put all your eggs in one basket and let somebody else hold it? Your eggs may be in many baskets, but is one hand picking up all the baskets? -- Kenneth Ng: ken@orion.bitnet ken@argus.uucp ken@mars.uucp ken@orion.njit.edu on bitnet, but not on arpanet.