hueni@.iam.unibe.ch (Hermann Hueni) (02/08/91)
I'm very unhappy with the philosophy DEC takes with their ULTRIX line of UNIX. It takes me always a long time to find out how to make work something on the ULTRIX machine as I expect it to work. The problem with DEC seems to be their willingness to create propriatary variants of otherwise established defacto standards. * when I expect to get a bourne shell like I get it on any of the other machines that I'm working on (HP,SUN,IX,NCR,...), I only get a partial solution and I have to figure out myself, that there is in fact a beast called 'sh5' that would be more standard. * When preparing a small curses demonstration program for my students, I run it successfully on 5 different machines in sysV & BSD derived environments with no problems at all. When I finally took it onto the Decstation (where the students have to work), it ran out of control or dumped core after some reproducible input sequences. Then, after a too long period of testing, I discovered that there was a library called "cursesX", supposed to be X-Open compatible. This library is basically sysV-curses but instead of performing correctly, I got another misbehaviour. There is no man page for "cursesX" as there is for "curses". But whoever searches long enough, discovers in section "3cur" a man page "intro". NOBODY ELSE HAS THIS SECTION! The specific problem with cursesX seems to be in the routine "overwrite". hermann _____________ Hermann Hueni Physiological Institute Seidenweg 40 University of Berne CH-3012 Bern CH-3012 Bern - Switzerland phone : +(41 31) [p:] 234-607 [b:] 658-726 e-mail: hueni@iam.unibe.ch fax : +(41 31) 654-611
hubcap@hubcap.clemson.edu (System Janitor) (02/08/91)
* I'm very unhappy with the philosophy DEC takes with their ULTRIX line of * UNIX... The problem with DEC seems to be their willingness to create * propriatary variants of otherwise established defacto standards. I feel this way too sometimes (mail11's SMTP ``enhancements'', arrrgggghhhh), but... * * when I expect to get a bourne shell like I get it on any of the * other machines that I'm working on (HP,SUN,IX,NCR,...), I only get * a partial solution and I have to figure out myself, that there is * in fact a beast called 'sh5' that would be more standard. ... the comments in the source to /bin/sh indicate that it is indeed Steven Bourne's. So while it may be fair to say that /bin/sh is not as up-to-date as some other sh's you are used to, it doesn't look to me as if DEC has spooged on it much. -Mike
treese@crl.dec.com (Win Treese) (02/09/91)
This isn't an official Digital statement, and I'm not out to defend all of Digital's decisions -- just to point out a couple of things. - /bin/sh is essentially the Bourne shell from BSD. ULTRIX grew out of BSD 4.2 and has a lot of System V-isms now. One of the decisions was to stay with the BSD /bin/sh and add the System V one as /bin/sh5. The same is true with make and a few other utilities as well. - there are at least 3 varieties of curses now -- BSD, System V, and X/Open. While it's unfortunate that there is some difficulty in understanding how ULTRIX tries to deal with these, especially given unclear documentation, it is also hard to engineer a system where they coexist to everyone's satisfaction, just as it is with /bin/sh. I don't really think that Digital is trying to make them "propietary." The market is an interesting place right now -- customers want the "best" version of something, yet it must be compatible with everyone else's versions. New features (and sometimes bug fixes!) are often viewed as attempts to make something "proprietary." I am sometimes astonished at reactions of the form "Company A is a leader in innovating in open systems" versus "Company B is trying to sucker us into a proprietary system" versus "Why doesn't company C do something better?" I'd be interested in discussion on what an "open system" really is -- and whether or not you'd buy one. Of course, I don't make any marketing decions; I'm in research. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp.