jsilva@cogsci.berkeley.edu (John Silva) (07/21/88)
How does Bell Technologies 386 based SysVr3 stack up to SCO? It seems to have everything, but I am really unsure as to it's reliability. Is it stable? Do all the utilities work as they should? Is it really a 'complete UNIX' as they advertise? I'd like your impressions... John P. Silva Inova Products --- UUCP: ucbvax!cogsci!jsilva DOMAIN: jsilva@cogsci.berkeley.edu
jsp@sp7040.UUCP (John Peters) (07/23/88)
In article <25145@ucbvax.BERKELEY.EDU>, jsilva@cogsci.berkeley.edu (John Silva) writes: > How does Bell Technologies 386 based SysVr3 stack up to SCO? It seems to have > everything, but I am really unsure as to it's reliability. Is it stable? > Do all the utilities work as they should? Is it really a 'complete UNIX' > as they advertise? > I am not sure as to their reliability; its probably like all software and has a few problems. There is a few things you should know though: 1. SCO may have the "look and feel" of UNIX, but it is not UNIX and is not at the level of System V Release 3. 2. System V Release 3 has major enhancements of System V Release 2 and SCO Zenix has not come up to its level of diversity of tools. I know that I am going to get flamed on all this (Hi Terry) but I do feel SCO is misleading the public with their advertisments for Zenix System V. It is not AT&T System V Compatable and I beleive SCO is trying to capitalize on the bandwagon. On the other hand, maybe we can finally cut out the System V - BSD - Zenix wars when System V Release 4 comes out. Somehow I doubt that SCO will be willing to relinquish being different.
jack@turnkey.TCC.COM (Jack F. Vogel) (07/24/88)
In article <465@sp7040.UUCP> jsp@sp7040.UUCP (John Peters) writes: >In article <25145@ucbvax.BERKELEY.EDU>, jsilva@cogsci.berkeley.edu (John Silva) writes: [...question about comparing Bell and SCO deleted...] > [..ignorant statement about Xenix not being UNIX(tm) deleted...] > >I know that I am going to get flamed on all this (Hi Terry) but I do feel >SCO is misleading the public with their advertisments for Zenix System V. ??^^^^^^?? Flames??!! You don't deserve flames, how can your posting be taken seriously when you can't even correctly identify the OS?? Especially in a news group whose every header contains the correct spelling???? Geeez, give us a break. -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...{nosc|uunet}!turnkey!jack Internet: jack@turnkey.TCC.COM
kevin@iisat.UUCP (Kevin Davies) (07/25/88)
In article <465@sp7040.UUCP>, jsp@sp7040.UUCP (John Peters) writes: > In article <25145@ucbvax.BERKELEY.EDU>, jsilva@cogsci.berkeley.edu (John Silva) writes: > > How does Bell Technologies 386 based SysVr3 stack up to SCO? It seems to have > > everything, but I am really unsure as to it's reliability. Is it stable? > > Do all the utilities work as they should? Is it really a 'complete UNIX' > > as they advertise? > > > > I know that I am going to get flamed on all this (Hi Terry) but I do feel > SCO is misleading the public with their advertisments for Zenix System V. > It is not AT&T System V Compatable and I beleive SCO is trying to > capitalize on the bandwagon. > > On the other hand, maybe we can finally cut out the System V - BSD - Zenix > wars when System V Release 4 comes out. Somehow I doubt that SCO will be > willing to relinquish being different. Well, Terry may not flame you but I think I will (well... just luke warm anyway :-) I don't believe SCO is misleading the public at all. The way I see it is that they're not saying "we ARE Sys V" but rather "almost Sys V compatible". Each release from SCO, especially SCO/386 brings them closer to true AT&T Sys V. For example, SCO/386 2.2 added the terminfo database while still retaining the older Xenix style plus the addition of the initabs file which *is* system V. They also have Sys V compat. shared memory and semaphores as well as the Xenix style ones as well. When SCO does become fully System V, they can still boast of being different due to the additions to the operating system they add (i.e., virtual logins at the console). -- Kevin Davies International Information Service (IIS) UUCP: {uunet,utai,watmath}!dalcs!iisat!kevin Bitnet/Uucp: kevin@iisat.uucp Arpanet: kevin%iisat.uucp@uunet.uu.net
rick@pcrat.UUCP (Rick Richardson) (07/25/88)
In article <87@iisat.UUCP> kevin@iisat.UUCP (Kevin Davies) writes: >When SCO does become fully System V, they can still boast of being >different due to the additions to the operating system they >add (i.e., virtual logins at the console). I don't think they'll be able to make this claim, either. ISC 386/ix is real System V and has virtual consoles. -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/26/88)
In article <465@sp7040.UUCP> jsp@sp7040.UUCP (John Peters) writes: | In article <25145@ucbvax.BERKELEY.EDU>, jsilva@cogsci.berkeley.edu (John Silva) writes: | > How does Bell Technologies 386 based SysVr3 stack up to SCO? It seems to have | > everything, but I am really unsure as to it's reliability. Is it stable? We have a few copies, and we're unsure of its reliability, too. The serial ports still seem to take a lot of CPU, and lose data at higher baud rates. | > Do all the utilities work as they should? Is it really a 'complete UNIX' | > as they advertise? | 1. SCO may have the "look and feel" of UNIX, but it is not UNIX and is not ^^^^^^^^^^^^^^ This is just blatently untrue. Xenix is based on AT&T code. It's not unmodified UNIX, however. The only vendor I know of for that is Bell Tech. MicroPort customizes theirs, as do Plexus, INter- active Systems, etc. | at the level of System V Release 3. This is true, however virtual memory has been added, which is the most visible to most users. | | 2. System V Release 3 has major enhancements of System V Release 2 and | SCO Zenix has not come up to its level of diversity of tools. | Any user who needs RFS and streams will have to buy another product or wait until November. Xenix has a lot of added stuff, and is generally quite reliable and has a number of BSD enhancements, as well as cross compile from 386 to Xenix/286, 8086 and DOS. Xenix has a lot of utilities and tools not in SVR3 and vice versa. To imply that the lacks are all in one direction is less than the whole truth. You have to consider the requirements and decide if you need unmodified V.3 and its tools, or if you want to run SysV programs. Xenix/386 passes SVID with the exception of one fairly obscure system call, and will allow you to develop programs which run portably on SVR2 and SVR3. It won't run streams and RFS yet, and the compiler produces code which is (generally) better than the pcc in untouched SsyV. The 386 SVR3 compiler would not compile about 30% of the programs I have tested, generating code which crashed the assembler a suite which runs on BSD, Ultrix, Xenix, SunOS, SVR3 on 3B2/200, etc. Being biased is fine with me, but supporting the bias with statements which are false, or only part of the truth seems to be pretty useless to the person who asked the question. I admit that I tested V/386, 386/ix and Xenix/386 and bought Xenix. I did it based on reliability of the products as of 11 months ago, and I have seen that the later versions of Xenix are still solid. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
duck@sp7040.UUCP (Duck) (07/28/88)
In article <465@sp7040.UUCP>, jsp@sp7040.UUCP (John Peters) writes: > > I know that I am going to get flamed on all this (Hi Terry) but I do feel > SCO is misleading the public with their advertisments for Zenix System V. > It is not AT&T System V Compatable and I beleive SCO is trying to > capitalize on the bandwagon. You don't have to look that far from home to get flamed on this. Exactly what is SCO saying that is "misleading the public" ? > On the other hand, maybe we can finally cut out the System V - BSD - Zenix > wars when System V Release 4 comes out. Somehow I doubt that SCO will be > willing to relinquish being different. Why should SCO relinquish being different when most of their differences represent added value? Like Multiscreens, DOS cross development, CGI, tape drivers, RAM disk, etc., etc.. Unisys sells over 600 copies of SCO Xenix each month. Compared to the number of UN*X systems we sell, I'd say the popularity of Xenix goes a long way in paying your salary. Be careful about biting the hand that really feeds you. It couldn't hurt to spell it right, either. ------- Duck Unisys Xenix development Salt Lake City { ihnp4 | hpda | utah-cs!utah-gr!uplherc }!sp7040!duck
woods@gpu.utcs.toronto.edu (Greg Woods) (07/30/88)
[ WARNING: flames follow. ] I am not familiar with Bell Tech's Sys V/386, but I am VERY familiar with ISC's 386/ix, and somewhat familiar with Microport Sys V/386. In article <11643@steinmetz.ge.com> you write: >In article <465@sp7040.UUCP> jsp@sp7040.UUCP (John Peters) writes: >| In article <25145@ucbvax.BERKELEY.EDU>, jsilva@cogsci.berkeley.edu (John Silva) writes: >| > How does Bell Technologies 386 based SysVr3 stack up to SCO? It seems to have >| > everything, but I am really unsure as to it's reliability. Is it stable? > We have a few copies, and we're unsure of its reliability, too. > The serial ports still seem to take a lot of CPU, and lose data > at higher baud rates. Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system. I worked with >10 Xenix 2.2.1 286 systems for a period 9 months. At least one of them crashed every (working) day, and often they were up and down like yo-yo's. Many of the crashes were due to kernel bugs. Only a small percentage could be attributed to hardware or local software (ie. device drivers). Many of the bugs are still un-found. I've only managed to crash 386/ix once. There's a (known) bug with shl. The Xenix serial driver cannot share interrupt vectors with more than one port. It will lose data at 1200 baud. Interrupt driven ports ALWAYS take a lot of cpu. Try a really smart board, such as Consensys PowerPorts. >| > Do all the utilities work as they should? Is it really a 'complete UNIX' >| > as they advertise? 386/ix is a superset of what AT&T ship. I wish they had ksh, and not sendmail though. >| 1. SCO may have the "look and feel" of UNIX, but it is not UNIX and is not > ^^^^^^^^^^^^^^ > This is just blatently untrue. Xenix is based on AT&T code. It's Yeah, a mess of V7, SysIII, BSD4.0, and other junk; all hooked together by a buggy, non-standard, compiler. As far as I know, they started the 2.x.x release with the AT&T 3B5 Sys V R2.1 tape. However, I would guess that only a tiny portion of the AT&T kernel was used (ie. IPC and termio). Unfortunately, not all of the utilities were taken from that tape (ie. uucp). The real problem is that SCO have built up a tremendous support reputation, and they are very wary of making any changes that may have dozens of users calling up. Take for example the choice to make the user utilities display disk blocks as 512 byte units, even though the 2.x kernel uses 1024 byte blocks. One support person hinted to me that they did not want to scare people who did a df, and found half their disk was suddenly gone! > not unmodified UNIX, however. The only vendor I know of for that > is Bell Tech. MicroPort customizes theirs, as do Plexus, INter- > active Systems, etc. Everyone customizes, but it's the porting base that counts. Even Bell Tech. try their hand at tuning and such. >| at the level of System V Release 3. > This is true, however virtual memory has been added, which is > the most visible to most users. I'd of thought it was invisible. Boy, what a can of worms it is too! Just to "advertize", 386/ix 2.0 will have direct paging. >| >| 2. System V Release 3 has major enhancements of System V Release 2 and >| SCO Zenix has not come up to its level of diversity of tools. >| > Any user who needs RFS and streams will have to buy another product or >wait until November. Xenix has a lot of added stuff, and is generally >quite reliable and has a number of BSD enhancements, as well as cross ???????? I mentioned that above. BTW: I'd rather have a superior product now, than wait for a lesser one. >compile from 386 to Xenix/286, 8086 and DOS. Xenix has a lot of This can be a very valuable selling point, but 386's (with VP/ix or Merge) make it moot. >utilities and tools not in SVR3 and vice versa. To imply that the lacks Such as? From a developer's point of view (and in my opinion), SysVR3 has more, newer, better, tools than any other version. >are all in one direction is less than the whole truth. > > You have to consider the requirements and decide if you need >unmodified V.3 and its tools, or if you want to run SysV programs. Now, that's a stupid statement! What's the difference? I want both! >Xenix/386 passes SVID with the exception of one fairly obscure system Is it binary (ie COFF) compatible yet? Will the 286 version ever be? Will there ever be a "SysVR4 compatible" Xenix 286? [ I hope not! :-) ] >call, and will allow you to develop programs which run portably on SVR2 >and SVR3. It won't run streams and RFS yet, and the compiler produces >code which is (generally) better than the pcc in untouched SsyV. The Except when it generates wrong code, or none at all. I've ported over 20 Mb of source. Microsoft have MANY problems with "register" and the 286 makes it almost impossible to get pointer expressions correct. >386 SVR3 compiler would not compile about 30% of the programs I have 386/ix has trouble with function pointers. Otherwise I've found it better by far than the Xenix 286 compiler. I wouldn't use the Xenix 386 compiler for any amount of money (given that I had to guarrantee the end result). [ I was told not to by SCO support! ] I've heard that the Microport 286 (ie pcc/286) compiler is much better, if slower. >tested, generating code which crashed the assembler a suite which runs >on BSD, Ultrix, Xenix, SunOS, SVR3 on 3B2/200, etc. I don't want to be offensive, but are you sure you know what you are doing? Most code that is that portable will compile first time. At least it does for me. Did you do the obvious things, like fix up the makefile, and any configure/tuning headers, etc.? > Being biased is fine with me, but supporting the bias with statements >which are false, or only part of the truth seems to be pretty useless to >the person who asked the question. > > I admit that I tested V/386, 386/ix and Xenix/386 and bought Xenix. I >did it based on reliability of the products as of 11 months ago, and I >have seen that the later versions of Xenix are still solid. I bought (as have my clients who could), and STRONGLY recommend, 386/ix. I STRONGLY recommend not touching Microsoft development tools with a 10 foot pole. >-- > bill davidsen (wedu@ge-crd.arpa) > {uunet | philabs | seismo}!steinmetz!crdos1!davidsen >"Stupidity, like virtue, is its own reward" -me [ I apologize for the length. I want to make it absolutely clear who said what. ] -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
jbayer@ispi.UUCP (id for use with uunet/usenet) (08/02/88)
In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > > Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system. > I worked with >10 Xenix 2.2.1 286 systems for a period 9 months. At > least one of them crashed every (working) day, and often they were up and > down like yo-yo's. Many of the crashes were due to kernel bugs. Only a > small percentage could be attributed to hardware or local software (ie. > device drivers). Many of the bugs are still un-found. I don't understand what you are referring to. We have sold, installed, and support more Xenix systems than you have. Over the past year our customers have had a grand total of 3 crashes. All of these crashes were on one computer leading us to suspect hardware. While the kernel may have bugs I have not been impacted by them to a large extent. > The Xenix serial driver cannot share interrupt vectors with more than > one port. It will lose data at 1200 baud. I normally don't tell people that they don't know what they are talking about, but you don't. I have a number of systems which are hard-wired together using the normal TD,SD, GND wires on the RS232 line. I have used uucp, cu, pcomm, a local terminal program, and the ZMODEM protocal running at 19200 baud. The wires are unshielded, about 200 feet long, running in places next to ac power lines. As you know, the RS232 spec. is valid for 50 feet. We have had NO DATA LOSS ON THESE LINES IN THE PAST 2 YEARS. This is using standard com1 and com2 ports. At times we have boosted the speed to 38400 baud, and have had very few problems. It is really nice to watch a 5 megabyte file get transferred at these speeds. Regarding the interrupt vectors, you are correct. However, I would like to know if the 386/ix product can share the interrupt vectors. You don't say. > > Interrupt driven ports ALWAYS take a lot of cpu. Try a really smart > board, such as Consensys PowerPorts. Correct, but this statement is true for ANY unix, not just Xenix. > > >| 1. SCO may have the "look and feel" of UNIX, but it is not UNIX and is not > > ^^^^^^^^^^^^^^ > > This is just blatently untrue. Xenix is based on AT&T code. It's > > Yeah, a mess of V7, SysIII, BSD4.0, and other junk; all hooked together > by a buggy, non-standard, compiler. As far as I know, they started the > 2.x.x release with the AT&T 3B5 Sys V R2.1 tape. However, I would guess > Unfortunately, not all of the utilities were taken from that tape (ie. uucp). Xenix has been available for several years now. I didn't see any other versions of unix until about a year ago. Microsoft wrote Xenix, then licensed it to manufacturers for their own systems (Altos for example), and then SCO got a deal to develope the commercial version. Xenix has been a reliable product now for a long time. It has been ungoing improvement for a long time. It has features that the standard unix does not, (I am not going to list them here). A lot of these features have been included to optimize the system for the end-user market. While some portions of Xenix are less than excellent (uucp as you mentioned), if you would read the papers you would know that version 2.3 will be released on August 15. Among other things it will have HDB uucp, and binaries which run on AT&T Unix will run on Xenix without recompiling. > > The real problem is that SCO have built up a tremendous support > reputation, and they are very wary of making any changes that may have > dozens of users calling up. Take for example the choice to make the > user utilities display disk blocks as 512 byte units, even though the > 2.x kernel uses 1024 byte blocks. One support person hinted to me that > they did not want to scare people who did a df, and found half their > disk was suddenly gone! Question for all you other unix gurus: What systems which have the df command report in 512 byte units, and what systems report is 1024 byte units? Unix has been developed over the years, and the commands are a conglomeration of many different people's ideas of what they wanted from the system. Because of this there is not a lot of sense in the way different utilities report the same information. SCO is doing the right thing in not changing the way the standard commands report information. If they did then many programs and shell scripts will not work. If you must complain about something complain about something worthwhile, not about standards and compatability. > > This is true, however virtual memory has been added, which is > > the most visible to most users. > > I'd of thought it was invisible. Boy, what a can of worms it is too! Using the virtual memory I have had programs running on ten different screens which needed a total of 6-8 meg of memory. While the system was a little slow (I only have 2 meg, with 10 meg of swap space) everything worked. > >compile from 386 to Xenix/286, 8086 and DOS. Xenix has a lot of > > This can be a very valuable selling point, but 386's (with VP/ix or > Merge) make it moot. How many one and two person shops need or can afford a good sized 386? On the other hand 286 machines are dirt cheap these days. Xenix is a good alternative to OS/2, and having the ability to develope on a 386 and then to copy a binary to a 286 (I do it all the time) is extremely valuable and is not a moot point. > > >utilities and tools not in SVR3 and vice versa. To imply that the lacks > > Such as? From a developer's point of view (and in my opinion), SysVR3 ^^^^^^^^^^^^^^^^^^ > has more, newer, better, tools than any other version. While SysVR3 has newer tools, are they really "better"? For those of us using Xenix the tools available are (in my opinion) better. > >Xenix/386 passes SVID with the exception of one fairly obscure system > > Is it binary (ie COFF) compatible yet? Will the 286 version ever be? > Will there ever be a "SysVR4 compatible" Xenix 286? [ I hope not! :-) ] As I mentioned above, version 2.3 will be binary compatible. I don't know about the 286. > > Except when it generates wrong code, or none at all. I've ported over > 20 Mb of source. Microsoft have MANY problems with "register" and the > 286 makes it almost impossible to get pointer expressions correct. I've been able to compile (after setting the correct options) almost everything that has come over the net, including (dare I say it) spacewars. It all worked. > > I admit that I tested V/386, 386/ix and Xenix/386 and bought Xenix. I > >did it based on reliability of the products as of 11 months ago, and I > >have seen that the later versions of Xenix are still solid. > > I bought (as have my clients who could), and STRONGLY recommend, 386/ix. > I STRONGLY recommend not touching Microsoft development tools with a 10 > foot pole. > Funny, Microsoft seems to be doing well selling their compilers and other system development tools. Jonathan B. Bayer Intelligent Software Products, Inc. 19 Virginia Ave. Rockville Centre, NY 11570 uunet!ispi!jbayer
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/03/88)
In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: | Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system. | I worked with >10 Xenix 2.2.1 286 systems for a period 9 months. At | least one of them crashed every (working) day, and often they were up and | down like yo-yo's. Many of the crashes were due to kernel bugs. Only a | small percentage could be attributed to hardware or local software (ie. | device drivers). Many of the bugs are still un-found. Must depend on how you use it. I've been running Xenix for 3 years on a 286 and 1+ years on a 386, and have had exactly one kernel crash. My work system is handling several uucp connections, telnet and ftp access, mail reading etc. The home system is public access UNIX, and people try to crash it all the time. | I've only managed to crash 386/ix once. There's a (known) bug with shl. | The Xenix serial driver cannot share interrupt vectors with more than | one port. It will lose data at 1200 baud. I run one 2400 baud and one 9600 baud connection at the same time as ftp, and have not seen this. I've heard of problems when someone tries to same $$ and use a dumb serial card for multiple ports. Perhaps that what you meant. | Interrupt driven ports ALWAYS take a lot of cpu. Try a really smart | board, such as Consensys PowerPorts. Amen! | The real problem is that SCO have built up a tremendous support | reputation, and they are very wary of making any changes that may have | dozens of users calling up. I agree, no one ever accused MicroPort of having a great support reputation, and if INteractive gives the same support they did four years ago, they don't have to worry either. First time I ever heard a good reputation used as a drawback. | dozens of users calling up. Take for example the choice to make the | user utilities display disk blocks as 512 byte units, even though the | 2.x kernel uses 1024 byte blocks. One support person hinted to me that | they did not want to scare people who did a df, and found half their | disk was suddenly gone! That is certainly the case with a number of companies. I could even make a case for doing it that way if I had dozens of shell scripts which expect a certain format for the file sizes and free space, etc, including using the find command with size option. I think you're correct in thinking that because Xenix has an installed base SCO doesn't have the freedom to change things, but then having an installed base is a good thing in general, isn't it? | >compile from 386 to Xenix/286, 8086 and DOS. Xenix has a lot of | This can be a very valuable selling point, but 386's (with VP/ix or | Merge) make it moot. Only if the cost of buying separate software for DOS doesn't count. By the time you buy a C compiler, editor, assembler, and some other tools you may have spent what looks like 10-20% of the cost of the hardware. Plus DOSmerge. Don't misunderstand, I have vp/ix and use it, but only to test software, not to try and duplicate my UNIX tools in DOS. | >tested, generating code which crashed the assembler a suite which runs | >on BSD, Ultrix, Xenix, SunOS, SVR3 on 3B2/200, etc. | | I don't want to be offensive, but are you sure you know what you are | doing? Most code that is that portable will compile first time. At | least it does for me. Did you do the obvious things, like fix up the | makefile, and any configure/tuning headers, etc.? Actually the first program which crashed it is about ten lines (plus comments) and doesn't have a make file, header file, etc. The second failure caused the compiler to core dump, and another to make the assembler reject the output of the compiler "error: there is no register 25" as I recall, definitely trying to find a register not in the 80386. There were others, mainly causing core dumps. I can accept a compiler which claims to find errors where no compiler has before, but I don't think generating bad code or core dumps is a useful behavior. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
wrp@biochsn.acc.virginia.edu (William R. Pearson) (08/03/88)
I would like to add that I have Xenix running on my AT for about 3 years (starting with IBM'x Xenix 1.0, and moving to SCO 1.? and 2.?). I run the machine 24 hours a day, 7 days a week. I have never had a crash due to software. I had a disk drive go, and we have a lot of power failures. Except when the power failures are so short that the AT's power supply does not reset, the machine just comes back up and goes merrily along. My Xenix machine has been just as, or more reliable than the ATT 3B2,5,15 machines I use, or the Sun's, or the VAX'es. I do not think that reliability is an issue with Xenix. What I would like is NFS capability. Bill Pearson
john@jetson.UUCP (John Owens) (08/04/88)
In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: I was tempted to attempt a point-by-point reply to the flames about Xenix, but I'll restrict myself to one or two comments. Many of your complaints are quite true, however, and I certainly wish that they'd convert all the block reporting utilities to report file system size blocks.... First, you are consistently comparing various *386* System V ports with *286* Xenix. Comparing with 386 Xenix would be a much better comparison; Xenix and other Unixes on 286 boxes are quite handicapped by the segmented architecture. > The Xenix serial driver cannot share interrupt vectors with more than > one port. True. > It will lose data at 1200 baud. Not for me. I've run UUCP connections at 9600 baud on direct serial lines on Xenix 286. > 386/ix has trouble with function pointers. Otherwise I've found it > better by far than the Xenix 286 compiler. I hope so - almost any 386 compiler is going to be better than any 286 compiler, since you don't have to worry about segmentation. I've had only one minor problem with Microsoft's 386 compiler (an infinite spill, easily worked around), and am happy with the code it produces. In general, I'm glad that there are enough choices that everyone can find a system that they like.... -- John Owens john@jetson.UPMA.MD.US SMART HOUSE L.P. uunet!jetson!john (old uucp) +1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet)
peter@ficc.UUCP (Peter da Silva) (08/04/88)
In article ... jbayer@ispi.UUCP (id for use with uunet/usenet) writes: > Xenix has been available for several years now. I didn't see any other > versions of unix until about a year ago. Gee, I must have imagined that I've been using UNIX since 1979 or so. Or do you just mean "UNIX on PCs" (remember, intel's braindamaged CPU isn't the whole world)... even then you're still wrong. Venturcom had one of the first UNIXes for the IBM-PC with Venix. I'll leave the rest of the article for others even more disenchanted with Microsoft than I. -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
woods@gpu.utcs.toronto.edu (Greg Woods) (08/04/88)
In article <152@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: >In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, I write: >> >> [ stuff about buggy kernels, etc. ] > >I don't understand what you are referring to. We have sold, installed, and >support more Xenix systems than you have. Over the past year our customers >have had a grand total of 3 crashes. All of these crashes were on one computer >leading us to suspect hardware. While the kernel may have bugs I have not >been impacted by them to a large extent. I didn't say we didn't use it to the max! >> The Xenix serial driver cannot share interrupt vectors with more than >> one port. It will lose data at 1200 baud. > >I normally don't tell people that they don't know what they are talking >about, but you don't. I have a number of systems which are hard-wired >together using the normal TD,SD, GND wires on the RS232 line. I have used >uucp, cu, pcomm, a local terminal program, and the ZMODEM protocal running >at 19200 baud. The wires are unshielded, about 200 feet long, running in >places next to ac power lines. As you know, the RS232 spec. is valid for >50 feet. We have had NO DATA LOSS ON THESE LINES IN THE PAST 2 YEARS. This -The spec and real life are different -Have you collected stats? >is using standard com1 and com2 ports. At times we have boosted the speed to >38400 baud, and have had very few problems. It is really nice to watch a >5 megabyte file get transferred at these speeds. Unfortunately I neglected to mention with strong enough voice that the I/O was through ports sharing an interrupt vector, not individual ports like COM1. I don't mind being told I don't know what I'm talking about, but I do mind when people don't listen (ie read) what I say. We tested the AMI-LAMB 8-port board which is supported by the generic serial driver, so I assume most other boards of similar design will experience the same problems. The actual configuration was worst-case -- lots of data going out the high priority port, and lots coming in the low priority port. Literally with a loop-back connector. The situation quickly degraded with any other system load. We even tried XON/XOFF. Unfortunately, this was before RTS/CTS was fixed. The Sys V 3.0 release notes list this as a problem with the 3B2 using more than 2 9600 baud lines, even with (hardware) flow control. >Regarding the interrupt vectors, you are correct. However, I would like to Like I said, read it first. (and maybe again after! :-) >know if the 386/ix product can share the interrupt vectors. You don't say. I don't know, and I won't bother finding out. With smart I/O it won't matter. I hope. (The Consensys card passed the test BTW.) >> Interrupt driven ports ALWAYS take a lot of cpu. Try a really smart >> board, such as Consensys PowerPorts. > >Correct, but this statement is true for ANY unix, not just Xenix. Ever see an original VAX 11/780 with 64 users typing away at vi? Not a pretty sight. I once though that was fast! >> >| 1. SCO may have the "look and feel" of UNIX, but it is not UNIX and is not [ I thing we're missing the original attribution. ] >> > This is just blatently untrue. Xenix is based on AT&T code. It's [ deleted mess of comments ] >> Unfortunately, not all of the utilities were taken from that tape (ie. uucp). > >Xenix has been available for several years now. I didn't see any other -that's the problem :-) >versions of unix until about a year ago. Microsoft wrote Xenix, then >licensed it to manufacturers for their own systems (Altos for example), >and then SCO got a deal to develope the commercial version. Xenix has been >a reliable product now for a long time. It has been ungoing improvement ???????? >for a long time. It has features that the standard unix does not, (I am -name one of REAL use, I dare you. >not going to list them here). A lot of these features have been included >to optimize the system for the end-user market. While some portions of -or further confuse >Xenix are less than excellent (uucp as you mentioned), if you would read the - with not even an excuse! >papers you would know that version 2.3 will be released on August 15. Among >other things it will have HDB uucp, and binaries which run on AT&T Unix will >run on Xenix without recompiling. I understand that Microsoft just bought the rights. If you're looking at Unix for the Intel junk only, you have tunnel vision. The rest of the world has been screaming ahead. Ever hear of the 68000, or NS32000, or WE32000, or AMD29000, or SPARC, or DEC, Cray, or ........ Why is Xenix, which used to be first, now last? >> The real problem is that SCO have built up a tremendous support >> reputation, and they are very wary of making any changes that may have >> dozens of users calling up. Take for example the choice to make the >> user utilities display disk blocks as 512 byte units, even though the >> 2.x kernel uses 1024 byte blocks. One support person hinted to me that >> they did not want to scare people who did a df, and found half their >> disk was suddenly gone! > >Question for all you other unix gurus: What systems which have the df command >report in 512 byte units, and what systems report is 1024 byte units? 386/ix uses 512 byte blocks. (inside and out) >Unix has been developed over the years, and the commands are a conglomeration >of many different people's ideas of what they wanted from the system. Because >of this there is not a lot of sense in the way different utilities report >the same information. SCO is doing the right thing in not changing the way >the standard commands report information. If they did then many programs >and shell scripts will not work. If you must complain about something >complain about something worthwhile, not about standards and compatability. The standard is to report blocks as they are allocated by the system, not some imaginary figure. Standard with all but Xenix, that is. As for breaking things, if you write code that bad, you deserve it. >> > This is true, however virtual memory has been added, which is >> > the most visible to most users. >> I'd of thought it was invisible. Boy, what a can of worms it is too! >Using the virtual memory I have had programs running on ten different screens >which needed a total of 6-8 meg of memory. While the system was a little >slow (I only have 2 meg, with 10 meg of swap space) everything worked. Some people don't read do they? :-) >> >compile from 386 to Xenix/286, 8086 and DOS. Xenix has a lot of >> This can be a very valuable selling point, but 386's (with VP/ix or >> Merge) make it moot. >How many one and two person shops need or can afford a good sized 386? On >the other hand 286 machines are dirt cheap these days. Xenix is a good Cost and price are two different things. >alternative to OS/2, and having the ability to develope on a 386 and then to >copy a binary to a 286 (I do it all the time) is extremely valuable and is >not a moot point. OS/2 isn't an alternative to anything but HELL. I forgot about the fact that you still might need some form of utility to convert COFF objects to Intel objects for the MS linker (it does still come with DOS?), not to mention a full suite of libraries. Oh well, one compiler and VP/ix should do it without too much expense. That is, if you HAVE to develop for MS-DOS.... The point I should have made is that now you can run your old DOS stuff (if you must :-), and Unix stuff, on the same box. (there's also XDOS) >> >utilities and tools not in SVR3 and vice versa. To imply that the lacks >> Such as? From a developer's point of view (and in my opinion), SysVR3 >> has more, newer, better, tools than any other version. > While SysVR3 has newer tools, are they really "better"? For those >of us using Xenix the tools available are (in my opinion) better. First hand use is an eye-opener. I WAS happy hidden in the Xenix world for quite some time. (I'm still a BSD'er at heart). >> >Xenix/386 passes SVID with the exception of one fairly obscure system >> Is it binary (ie COFF) compatible yet? Will the 286 version ever be? >> Will there ever be a "SysVR4 compatible" Xenix 286? [ I hope not! :-) ] > As I mentioned above, version 2.3 will be binary compatible. I >don't know about the 286. They say it will be. >> Except when it generates wrong code, or none at all. I've ported over >> 20 Mb of source. Microsoft have MANY problems with "register" and the >> 286 makes it almost impossible to get pointer expressions correct. >I've been able to compile (after setting the correct options) almost everything >that has come over the net, including (dare I say it) spacewars. It all >worked. Well, I couldn't. (Secret: try '-Dregister=' for some things.) Some things still don't work. Ever hear of a compiler that generates a binary without a peep, and a system that then thinks that binary (with the correct magic number, and a valid x-out header) is a shell script? A lot of problems are with squeezing stuff into a 286 too. >> > I admit that I tested V/386, 386/ix and Xenix/386 and bought Xenix. I >> >did it based on reliability of the products as of 11 months ago, and I >> >have seen that the later versions of Xenix are still solid. >> I bought (as have my clients who could), and STRONGLY recommend, 386/ix. >> I STRONGLY recommend not touching Microsoft development tools with a 10 >> foot pole. >Funny, Microsoft seems to be doing well selling their compilers and other >system development tools. A lot of people aren't in a position to complain, not that it does any good. If you want to write serious C code, and not worry about the compiler, you don't stand much chance with Microsoft. >Jonathan B. Bayer >Intelligent Software Products, Inc. >19 Virginia Ave. >Rockville Centre, NY 11570 >uunet!ispi!jbayer [ Sorry about the length folks. Hopefully this is the end of it. I've nothing but defensive remarks (ie flames) left anyway :-) ] -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
woods@gpu.utcs.toronto.edu (Greg Woods) (08/04/88)
In article <86@jetson.UUCP> john@jetson.UUCP (John Owens) writes: >In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, I write: >>[ nothing, it seems :-) ] >First, you are consistently comparing various *386* System V ports >with *286* Xenix. I know, and I also like to compare 3Bs, and Suns, and Vaxes, and such :-) >Not for me. I've run UUCP connections at 9600 baud on direct serial >lines on Xenix 286. [ and I've done it at 19.2 Kbps -Greg ] This is the boring part: Re-read my comments, and the other long boring version I posted today. You will lose data at 1200 baud when sharing interrupt vectors with more than one port when using the generic built-in serial driver of Xenix 2.2.x with some interface cards, even when using XON/XOFF flow control. (whew :-) Did you calculate the effective baud rates, and count the garbled packets? >I hope so - almost any 386 compiler is going to be better than any 286 >compiler, since you don't have to worry about segmentation. I've had >only one minor problem with Microsoft's 386 compiler (an infinite >spill, easily worked around), and am happy with the code it produces. Well, I wasn't really fair, but what I was thinking of were problems with pointer expressions, and with register variables, that shouldn't be related to the CPU (I don't really know, I didn't write the compiler). Again, even SCO support suggested not using the Xenix 386 for development until the "merged AT&T / SCO" release, or at least until another version of the compiler is released. Microsoft consistently refuse to fix bugs, and ignore many pleas for help. Even the DOS 5.1 version has lots of problems. I'm not sure what DOS version the Xenix 386 compiler is derived from, but the 2.2 286 version is from MS-C 3.00 according to the copyright string. >-- >John Owens john@jetson.UPMA.MD.US >SMART HOUSE L.P. uunet!jetson!john (old uucp) >+1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet) -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
how@milhow1.UUCP (Mike Howard) (08/04/88)
In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > >> The Xenix serial driver cannot share interrupt vectors with more than >> one port. ok - but why is that a problem? Seems like the serial driver is busy enough that you _wouldn't_ want it to share a vector. >> It will lose data at 1200 baud. Crap. I have a Compaq 286 (8 MHz) running SCO Xenix 2.2.1 with a Hostess 8-port board as COM2. That board simultaneously drives: 2 HP LaserJets - at 9600 baud 1 TrailBlazer - at a fixed interface speed at 9600 baud 2 hard wired lines - at 9600 baud 1 Data Device - at 9600 baud 1 seldom used 1200 baud modem - at (coincidentally) 1200 baud. All have run simultaneously w/o any character loss. The flow control ranges over hardware (the TrailBlazer), Xon/Xoff (the printers and cu communications over dedicated lines), and `random protocol' (as in uucp)). Response time is `unacceptable' while driving both printers and a tad slow when doing a large uucp file transfer (5 Meg per night), but everything works fine. In defense of your indefensible statement: I tried Compaq's Xenix (now dead) initially, and it could barely do 1200 baud w/o loosing Characters? Is that what you are talking about? Xenix is not always Xenix and performance depends on who ported it - especially the drivers. -- Mike Howard uunet!milhow1!how
dyer@spdcc.COM (Steve Dyer) (08/04/88)
Listen pal, if you think you can make your point by screaming the loudest
and the longest, you're wrong. It's surely not going to drum up any more
business for you. I think it's really too bad you've had such poor experience
with XENIX and serial boards and all the rest. I wonder exactly what is
going on, since myself and many others have reported exactly the opposite
experience with the product.
I had first run XENIX 286, releases 2.1.3, 2.2, and now XENIX 386 from
beta to the latest 2.2 release. I found the XENIX 286 compiler had problems
with some large and huge model programs, but the XENIX 386 product including
the compiler is downright bulletproof. I use a Digiboard 4-port dumb serial
board supported by the built-in serial driver connected to 1 9600-baud leased
line and 3 Trailblazers. No character loss on any of the lines, and yes,
I have stats from my UUCP log and from interactive use while all the lines
are being used. My software complement includes the MH mail handler, the
latest sendmail from Berkeley, GNU Emacs, all the news software, etc.
The stuff runs first time and every time. No observable compiler or library
problems. Excellent support from SCO. No complaints.
When someone flames so strongly about a product and company as you have,
presenting some evidence and more invective, when that is contrary to a lot
of people's reported experience, it's worth wondering what's going on.
What's your support experience been with SCO? What were the applications
you were running? Situations differ, but this is quite anomalous.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyersandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (08/05/88)
In article <1585@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > Listen pal, if you think you can make your point by screaming the loudest > and the longest, you're wrong. It's surely not going to drum up any more > business for you. I think it's really too bad you've had such poor experience > with XENIX and serial boards and all the rest. I wonder exactly what is > going on, since myself and many others have reported exactly the opposite > experience with the product. > > I had first run XENIX 286, releases 2.1.3, 2.2, and now XENIX 386 from > beta to the latest 2.2 release. I found the XENIX 286 compiler had problems > with some large and huge model programs, but the XENIX 386 product including > the compiler is downright bulletproof. I use a Digiboard 4-port dumb serial > board supported by the built-in serial driver connected to 1 9600-baud leased > line and 3 Trailblazers. No character loss on any of the lines, and yes, > I have stats from my UUCP log and from interactive use while all the lines > are being used. My software complement includes the MH mail handler, the > latest sendmail from Berkeley, GNU Emacs, all the news software, etc. > The stuff runs first time and every time. No observable compiler or library > problems. Excellent support from SCO. No complaints. > > When someone flames so strongly about a product and company as you have, > presenting some evidence and more invective, when that is contrary to a lot > of people's reported experience, it's worth wondering what's going on. > What's your support experience been with SCO? What were the applications > you were running? Situations differ, but this is quite anomalous. > -- > Steve Dyer > dyer@harvard.harvard.edu > dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer Steve, All I can add to your above comments is that I agree with your comments 100%!! Like your self, I run both Xenix286 and Xenix386 without any major problems or complaints. I couldn't ask for anything more reliable or dependable. I have also run Microport Unix 286 and 386 ( which is nothing more than the Interactive Unix with Microport enhancements ). When I originally brought up Uport, uucp and other functions didn't even work. Microport has fixed many of the problems as versions were released; however, when I brought up Xenix for the first time ( SCO Xenix and NOT IBM 1.0 Xenix ) all the functions seemed to be operational. Let's talk about apples with apples: The Intel 286 "C" compiler and the Microsoft "C" compiler ......... Intel--- No medium or huge models MS ----- They exist Intel - No apparent register usage MS ---- The register usage is well thought out. Let's talk about apples with apples: The Intel 386 "C" compiler and the Microsoft "C" compiler ......... Microport thought so much about the Intel compiler that they don't use it anymore! MS compiler -- already has the hooks in it for other models other than small. Now to brass tacks! The interactive Unix system comes with only the provision for a two getty system. If you want more, you must buy the multi-user license. SCO Xenix already gives you nearly an unlimited multi-user system. The response time of Xenix seems to me to be much faster than either the Microport enhance Interactive Unix or the "straight from the box" Unix that is offered by Bell. Please don't get me wrong, Interactive Unix is really a fine product and is much cheaper then SCO Xenix; however, I expect and demand more and that is why I strongly prefer SCO Xenix over any of the other *nix that is offered. Like yourself, I have had experiences with many different multi-port cards. Also, like yourself, I haven't had any problems with the cards except for some third part drivers that are offered with them. Present, on my 386 system in the office, I have three terminals running on the system at 19.2K baud. Also on the system is an Excelan Ethernet card running under the supplied software from Excelan. Needless to say, it runs flawlessly. One parting comment: You really get what you pay for, Sanford ( Sandy ) Zelkovitz
woods@gpu.utcs.toronto.edu (Greg Woods) (08/06/88)
In article <1585@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: > [ ... about my flames ... ] >-- >Steve Dyer >dyer@harvard.harvard.edu >dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer Unfortunately, it's not just my experiences I've drawn my fuel from. There are a lot of unhappy users out there (especially around here). Unfortunately(?) not many of them are on Usenet either. If you want to know just how bad the Microsoft compiler is, collect the bug list from the MS-DOS world too. It's the same compiler, and the MESS-DOS'ers get the newer versions first! It would be impossible (for me) to give detailed accounts of all the problems I've heard of. The not-so-short outburst I've already accounted is only a small portion. If I hadn't known Xenix had been around for so long, I'd have thought I was being used as a beta site. I wonder at the luck of some people. I suppose some combinations of hardware and software survive much better. What bothers me most is the marketing ploy the consumers of Xenix (and Intel) have fallen for. The claims these people make often border on the edge of reality. Calling Xenix "System V", and then backing it up by saying it passes the SVID is not quite fair. Calling some of the differences between Xenix and Unix "features" is not fair either. It's often said that a "bug" can be disguised, or even documented, as a "feature". One can say the same thing about Microsoft that many are saying of IBM and DEC: "Why should they go all out for an operating system that competes with their own proprietary systems?" I can also say that the general feeling in "corportate" Canada is that Xenix not a prime choice in the multi-user marketplace. -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
woods@gpu.utcs.toronto.edu (Greg Woods) (08/06/88)
In article <1090@turnkey.TCC.COM> sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) writes: >In article <1585@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: >> line and 3 Trailblazers. No character loss on any of the lines, and yes, >> I have stats from my UUCP log and from interactive use while all the lines Have you tried the worst case test? (ie: transmit from the high priority port to the low-pri one with only XON/XOFF flow control?) >> -- >> Steve Dyer >> dyer@harvard.harvard.edu >> dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer > >Steve, > >Let's talk about apples with apples: The Intel 286 "C" compiler and the >Microsoft "C" compiler ......... Intel--- No medium or huge models Huge doesn't work that well, and isn't worth the trouble. Only one of the "medium" models is missing. > MS ---- The register usage is well > thought out. But broken. I had to remove register declarations from a lot of code (with -Dregister=) before it worked. >Let's talk about apples with apples: The Intel 386 "C" compiler and the >Microsoft "C" compiler ......... Microport thought so much about the Intel > compiler that they don't use it anymore! Neither does Interactive, nor AT&T. > MS compiler -- already has the hooks in it > for other models other than small. Now, what will you do with them? Writing 64 terabyte programs these days? Like the rest of the 32-bit world, I'm happy with 4 Gb. Where will you get a 386 OS to handle such a program anyway? >Now to brass tacks! The interactive Unix system comes with only the provision >for a two getty system. If you want more, you must buy the multi-user license. >SCO Xenix already gives you nearly an unlimited multi-user system. The response You're a victim of the AT&T System V licensing policies, which I happen to like. It cut their royalties in the high end market. It's unbundling I don't like. >Sanford ( Sandy ) Zelkovitz -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
woods@gpu.utcs.toronto.edu (Greg Woods) (08/06/88)
In article <215@milhow1.UUCP> how@.UUCP (Mike Howard) writes: >In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, I write: >> >>> The Xenix serial driver cannot share interrupt vectors with more than >>> one port. >ok - but why is that a problem? Seems like the serial driver is busy >enough that you _wouldn't_ want it to share a vector. Unfortunately, it does share vectors. There are only 4 commonly available interrupts for serial ports in the first place, and often 8 ports share one vector. Unless the board has hardware to "stack" interrupts, characters will get lost. Even AT&T have had this problem (see the SVR3.0 release notes for the 3B2). >>> It will lose data at 1200 baud. >Crap. I have a Compaq 286 (8 MHz) running SCO Xenix 2.2.1 with a Hostess >8-port board as COM2. That board simultaneously drives: To be specific, it was a 16 MHz Olivetti 386 running SCO Xenix V/286 2.2.1 with an AMI-LAMB 8-port as COM2. The eight'th port was looped back into the first port. XON/XOFF was turned on, and a file was cat'ed through at various baud rates. The resulting data loss showed why our application was behaving so poorly (an RS-232 LAN). When we repeated this test in various versions of the Olivetti 286, and in a 6 MHz IBM-AT, the problem only escalated. The IBM even lost characters at 300 baud. >Xenix is not always Xenix and performance depends on who ported it - >especially the drivers. I spent a lot of time on the phone with SCO, who wrote and ported the version I was using. >-- >Mike Howard >uunet!milhow1!how -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
mike@ists (Mike Clarkson) (08/06/88)
The only problems we've ever had running Xenix has been on cheap flaky hardware. On even moderately reliable hardware base, SCO Xenix is a solid product. Use Xenix on flaky hardware and yet get what you deserve for being cheap. We had a grand total one panic in the last year on 4 AT clones (Packard-Bell, AST and Compaq). SCO Xenix is as reliable, and is easier to maintain than Unix on a Sun, Vax, or Nation Semi. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
plocher@uport.UUCP (John Plocher) (08/06/88)
In article <1090@turnkey.TCC.COM> Sanford 'Sandy' Zelkovitz writes: >Let's talk about apples with apples: The Intel 386 "C" compiler and the >Microsoft "C" compiler ......... Microport thought so much about the Intel > compiler that they don't use it anymore! Where did you hear this? Not from here, cuz we *do* use the Intel "pcc" compiler on all our source - we *do* include the GreenHills C for those who want something else. >Now to brass tacks! The interactive Unix system comes with only the provision >for a two getty system. If you want more, you must buy the multi-user license. Don't blame ISC/BT/Microport for that one; the license requirement for more $$$ when (users > 2) is direct from AT&T :-( -John Plocher
plocher@uport.UUCP (John Plocher) (08/06/88)
In article <1988Aug5.231946.17333@gpu.utcs.toronto.edu> Greg Woods writes: >In article <215@milhow1.UUCP> how@.UUCP (Mike Howard) writes: >>In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, I write: >>>> The Xenix serial driver cannot share interrupt vectors with more than Hey Guys, Did you notice the name of the group you are flaming in? I didn't think so. Try comp.unix.xenix (or even better, try email) -John Plocher former moderator for comp.unix.microport
rick@pcrat.UUCP (Rick Richardson) (08/07/88)
In article <404@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: > >Hey Guys, > > Did you notice the name of the group you are flaming in? > I didn't think so. Try comp.unix.xenix (or even better, try email) > > -John Plocher Cross posting to .xenix and .microport is needed these days, since the net Gods have seen fit to provide only these two groups for 286 and 386 UNIX'es. Where are Bell Tech, ISC, and Venturcom people to go? How can you discuss the relative merits of each companies offerings without cross posting? With the impending merge of UNIX, it makes more sense to just break the groups as "i286" and "i386". Not only does this break the audience into camps with similar needs and problems, but it also gets rid of the commercial aspects to the existing group names (something that doesn't bother me, but does bother some). -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
howardl@wb3ffv.UUCP (Howard Leadmon ) (08/08/88)
In article <550@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes: > > With the impending merge of UNIX, it makes more sense to just break > the groups as "i286" and "i386". I think this would be a GREAT IDEA, and I can't believe this is the first time I have ever seen it mentioned on the net. This would certainly allow us to read the information that pertains to our CPU... ------------------------------------------------------------------------------- UUCP/SMTP : howardl@wb3ffv | Howard D. Leadmon PACKET : WB3FFV @ W3ITM | Fast Computer Service, Inc. IP Address: 44.60.0.1 | P.O. Box 171 Telephone : (301)-335-2206 | Chase, MD 21027-0171
enped@conexch.UUCP (Eric Pederson) (08/09/88)
We haven't had as much luck with SCO Xenix. I think our troubles may be due to poor SVID IPC support in the 2.1 Xenix for the 386. Our Alcatel 386 (with 8 meg of RAM, and a 150 meg ESDI drive) crashed every day at least once under a user load of 10 or less (on intelligent serial ports). The applications used were very IPC oriented. We got page fault-type kernel panics with regularity and other bizzare panics that SCO support didn't even know existed. Now we run Bell Tech SysV/386 and have had no crashes whatsoever. I miss the splendid system admin stuff Xenix had and the nice documentation, but we needed something that worked. --- Eric Pederson 714-964-3339
wtr@moss.ATT.COM (08/09/88)
In article <722@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: >In article <550@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes: >> With the impending merge of UNIX, it makes more sense to just break >> the groups as "i286" and "i386". > I think this would be a GREAT IDEA, and I can't believe this is the first >time I have ever seen it mentioned on the net. This would certainly allow >us to read the information that pertains to our CPU... this idea has been gone over and argued multiple times, and was discussed heavily when this newsgroup was formed. it's a BAD idea for this reason: it would put the XENIX camp in with the INTERACTIVE port team (microport/bell tech/etc..). [prepare asbestos suit / install sprinklers in mailbox ] would all the would-be prophets of the XENIX world stop their **garbage** postings in comp.unix.microport! i have purchased microport and am looking for support, hints, and fixes in this newsgroup. I am *not* looking for some XENIX dweeb expounding upon the virtues of his system over microports. this is especially true when he/she/it apparently has little direct experience with microport. go home. if you have information about microport / bell tech, then feel free to post it here, it's very welcome. if you just want to throw your shoulder out of joint patting yourself on the back, do it in your own yard. [if someone wants to take this one up, email it] ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ att ulysses ucbvax allegra ]!moss!wtr ...![ att ucbvax akgua watmath ]!clyde!wtr =====================================================================
dar@belltec.UUCP (Dimitri Rotow) (08/10/88)
In article <550@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes: > In article <404@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: > > > With the impending merge of UNIX, it makes more sense to just break > the groups as "i286" and "i386". > Yes! At least the "generic" UNIX's are more alike than different on the 80386. Release 3.2 will make it even more so (and whether you get it from Interactive, Microport or anyone else, Release 3.2 is a *barnburner*!).
richard@neabbs.UUCP (RICHARD RONTELTAP) (08/11/88)
(Sorry, can't quote) [ Comparing XENIX <-> Microport <-> Bell Tech is garbage. ] I don't agree. Im using SCO XENIX (working great) and have had NO experience with other UNIX flavours. So I'm following the comparisions/flames/metaphores with great interest. Since UNIXes are (more or less) the same, I would be perfectly willing to step over to another UNIX, for speed, elegance or reliability. Of course everyone submits their own subjecttive view, (I really enjoyed the Farrari <> Cadillac article), but some information is very real. (Like filesystem speed, serial driver bugs, shared data bugs, support experiences, etc.) Aren't you only a bit upset because MicroPort is getting a lot of flag these last few days? Keep 'em coming! Richard (...!mcvax!telmail!neabbs!richard!)
woods@gpu.utcs.toronto.edu (Greg Woods) (08/11/88)
In article <6643@conexch.UUCP> enped@conexch.UUCP (Eric Pederson) writes: >We haven't had as much luck with SCO Xenix. I think our troubles may be due to >poor SVID IPC support in the 2.1 Xenix for the 386. Our Alcatel 386 (with 8 >meg of RAM, and a 150 meg ESDI drive) crashed every day at least once under >a user load of 10 or less (on intelligent serial ports). The applications >used were very IPC oriented. We got page fault-type kernel panics with >regularity and other bizzare panics that SCO support didn't even know existed. Now, that's more like it. I knew someone else must have been trying to "use" the system to the extent we did. Unfortunately, I don't think it is just the IPC stuff to be blamed. >Now we run Bell Tech SysV/386 and have had no crashes whatsoever. I miss >the splendid system admin stuff Xenix had and the nice documentation, but >we needed something that worked. I don't think you're missing much. The new AT&T documentation has MUCH improved guides, and is more "bug" free. The on-line help is a great boon, though it could be more complete. The only thing I miss is the ring-binders. Much "easier" to use than softcover books. I find the sysadm stuff better than the Xenix junk, and I even use sysadm once and a while. Most of the Xenix scripts had weird problems, especially if you tried anything that wasn't expected. (I'm not sure if Bell Tech has the same stuff as 386/ix, but I assume it does.) >--- >Eric Pederson >714-964-3339 -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
jhh@ihlpl.ATT.COM (Haller) (08/11/88)
In article <6643@conexch.UUCP>, enped@conexch.UUCP (Eric Pederson) writes: > We haven't had as much luck with SCO Xenix. I think our troubles may be due to > poor SVID IPC support in the 2.1 Xenix for the 386. There was a bug in the SVR2 IPC. I don't remember the details, but if more than 64K message queues were created and deleted, a counter overflowed, indirectly causing a reference to an invalid memory location. I saw this in a 3B-20S. After a call to AT&T Software Support (not the hotline, but the people in Lisle, IL who support people with a software support contract), they provided a fix the next day. If SCO's IPC is SVR2 based, it may have the same bug. Since the bug was found in SVR2, it was most likely fixed before SVR3 was released. John Haller
farber@linc.cis.upenn.edu (David Farber) (08/12/88)
I have had a LOT of luck with SCO 2.3 on my 386. I have had almost no problems. I run a Intel motherboard and two Priam 80 s Dave David Farber; Prof. of CS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele: 215-898-9508; FAX: 215-274-8192 "The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- R. P. Feynman
rick@pcrat.UUCP (Rick Richardson) (08/13/88)
In article <31060@clyde.ATT.COM> wtr@moss.UUCP (Bill Rankin) writes: >In article <722@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: >>In article <550@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes: > >>> With the impending merge of UNIX, it makes more sense to just break >>> the groups as "i286" and "i386". > >this idea has been gone over and argued multiple times, and was >discussed heavily when this newsgroup was formed. it's a BAD idea >for this reason: it would put the XENIX camp in with the INTERACTIVE >port team (microport/bell tech/etc..). > >would all the would-be prophets of the XENIX world stop >their **garbage** postings in comp.unix.microport! I remember the multiple times it has been discussed. But times have changed. I don't own either Microport or Xenix, for either of my 286 or 386 machines. Yet I have UNIX ports that run on both. (Well, not true, I do own a copy of Microport V/AT, I just don't use it!). You want vendor specific groups for support, which is reasonable. But you don't want the vendor bashing in your support group. Other people do want the vendor bashing, and comparisons, etc. so they can make intelligent (?) decisions. OK, so let's make these groups: comp.unix.xenix Discussions about the XENIX O.S. comp.unix.microport Discussions about Microport's UNIX comp.unix.i286 General discussions of any *NIX on the Intel 80286 comp.unix.i386 General discussions of any *NIX on the Intel 80386 With any luck, the comparisons, bashing, et all can go on in the generic groups. Leaving your sanctioned 'support' groups free from clutter. And then there is the potential for a dos_unix (DOS under UNIX) group, for VP/ix and Merge discussions. But lets get the first four groups under control once and for all, first. -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
howardl@wb3ffv.UUCP (Howard Leadmon ) (08/15/88)
In article <552@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes: > > OK, so let's make these groups: > > comp.unix.xenix Discussions about the XENIX O.S. > comp.unix.microport Discussions about Microport's UNIX > comp.unix.i286 General discussions of any *NIX on the Intel 80286 > comp.unix.i386 General discussions of any *NIX on the Intel 80386 > > Rick Richardson, PC Research, Inc. Well this may be OK, but I would rather see it broke down into the different vendor catagories under the specific processors. Here is an example of what I mean: comp.unix.i286 General 80286 UNIX discussions comp.unix.i386 General 80386 UNIX discussions comp.unix.i286.microport For System V/AT comp.unix.i386.microport For System V/386 comp.unix.i386.ix For IX from Interactive for the 80386 comp.unix.i286.xenix For 80286 Xenix comp.unix.1386.xenix For 80386 Xenix I know this idea will create a half dozen new groups, but it will certanly keep similar interests togeather. Also there should be no big deal about several subdivisions, it's only a couple extra subdirectories on our systems :-) ------------------------------------------------------------------------------- UUCP/SMTP : howardl@wb3ffv | Howard D. Leadmon PACKET : WB3FFV @ W3ITM | Fast Computer Service, Inc. IP Address: 44.60.0.1 | P.O. Box 171 Telephone : (301)-335-2206 | Chase, MD 21027-0171
john@jetson.UPMA.MD.US (John Owens) (08/16/88)
In article <728@wb3ffv.UUCP>, howardl@wb3ffv.UUCP (Howard Leadmon ) writes: > Well this may be OK, but I would rather see it broke down into the > different vendor catagories under the specific processors. > [ list of 7 newsgroups ] > I know this idea will create a half dozen new groups, but it will certanly > keep similar interests togeather. This is the opposite direction that I feel we should be going. With the 2.3 release of SCO Xenix, Xenix and the other 386 Unixes will be much more similar, so I think that either the pair comp.unix.i286 comp.unix.i386 should be created, or one group should be created, merging comp.unix.xenix, comp.unix.microport, and the info-386ix mailing list. I don't have a good name for it, but something like comp.unix.i86 or comp.unix.intel might do. (Certainly the occasional Xenix/86 question is welcome.) Comments? -- John Owens john@jetson.UPMA.MD.US SMART HOUSE L.P. uunet!jetson!john (old uucp) +1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet)
brian@umbc3.UMD.EDU (Brian Cuthie) (08/16/88)
In article <728@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: > Well this may be OK, but I would rather see it broke down into the >different vendor catagories under the specific processors. Here is an >example of what I mean: > >comp.unix.i286 General 80286 UNIX discussions >comp.unix.i386 General 80386 UNIX discussions >comp.unix.i286.microport For System V/AT >comp.unix.i386.microport For System V/386 >comp.unix.i386.ix For IX from Interactive for the 80386 >comp.unix.i286.xenix For 80286 Xenix >comp.unix.1386.xenix For 80386 Xenix > > I know this idea will create a half dozen new groups, but it will certanly >keep similar interests togeather. Also there should be no big deal about >several subdivisions, it's only a couple extra subdirectories on our systems :-) This idea sounds good on the surface, but I suggest that it would be about the worst thing that could be done. There are two main problems (as I see it, anyway): 1. It would be necessary to cross post most articles to several groups since many articles would cross group boundaries. 2. If you don't cross post, then I'm forced to read about 4 news groups to be sure that I haven't missed something. I think the *real* problem could be solved by having one additional group called "comp.unix.microport.flames" When you look at the amount of traffic in this group that actually has any content it's nil. *Most* of the articles are running debates over such technically important issues as "Bell Tech Pricing." I don't know about you, but I got the point after the first 500 postings. What is really needed is an alternate news group where the non-technical issues can be discussed without causing undue stress on my 'n' key. Of course I realize that this posting, in itself, is somewhat hypocritical :-) Maybe a 1 hour delay on the 'F' key would help. -brian
richard@neabbs.UUCP (RICHARD RONTELTAP) (08/19/88)
> different vendor catagories under the specific processors. Here is an > example of what I mean: > comp.unix.i286 General 80286 UNIX discussions > comp.unix.i386 General 80386 UNIX discussions > comp.unix.i286.microport For System V/AT > comp.unix.i386.microport For System V/386 > comp.unix.i386.ix For IX from Interactive for the 80386 > comp.unix.i286.xenix For 80286 Xenix > comp.unix.1386.xenix For 80386 Xenix > > I know this idea will create a half dozen new groups, but it > will certanly keep similar interests togeather. Also there > should be no big deal about several subdivisions, it's only a > couple extra subdirectories on our systems :-) I don't think this is a good idea. Because of ignorance or getting maximum response, people will cross post in most of these groups. This may be slightly annoying voor local terminal news readers, but some people, like me read the news via modem! Also I can't remember what the reason was for splitting into 286 and 386. For example: my 286 and 386 XENIX's are almost identical. The only obvious difference being that the 386 version can execute and generate (cc) 386 code. Richard (...!mcvax!neabbs!richard)
ronc@cerebus.UUCP (Ronald O. Christian) (08/25/88)
In article <1585@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >When someone flames so strongly about a product and company as you have, >presenting some evidence and more invective, when that is contrary to a lot >of people's reported experience, it's worth wondering what's going on. >What's your support experience been with SCO? What were the applications >you were running? Situations differ, but this is quite anomalous. It could be that you don't see a lot of traffic on problems with Xenix because a lot of people struggling with Xenix don't have access to Usenet because they can't get the gol-durned uucp to work. When you're effectively cut off from the rest of humanity, your voice is small and thin indeed. As for support, we called SCO today with a trivial question about their uucp, and they scheduled an answer for next Tuesday. The question was, how do you send a string in your chat script with a space in it? (Like "foo bar".) If you write foo\sbar it sends foo\sbar If you write foo\c "" bar it sends foo\c From the documentation it appears to be impossible to either force a whitespace (tab or space, I don't care) in a chat script string or even send a string without a trailing carrage return. This is a usable Unix? Ron -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc Calling all Fujitsu Usenet sites! Contact cerebus!ronc or ronc@fai.com to establish uucp connection.
john@jetson.UPMA.MD.US (John Owens) (08/25/88)
> As for support, we called SCO today with a trivial question about > their uucp, and they scheduled an answer for next Tuesday. The > question was, how do you send a string in your chat script with > a space in it? (Like "foo bar".) You get the Telebit utilities diskette, fix # xnx072, which includes a new uucico that supports, among other things, \s. jfh@rpp386.UUCP asks > a uucico that will run at 9600 (and 19200 ???) baud. Yes, it claims to run at 19200 baud; you can lock your telebit interface speed at 19200. (I haven't run it at 19200 myself, but I believe it, since that's a common thing to do with a telebit.) The diskettes also include a "cu" that's supposed to run at 19200. Good luck! -- John Owens john@jetson.UPMA.MD.US SMART HOUSE L.P. uunet!jetson!john (old uucp) +1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet)
jfh@rpp386.UUCP (The Beach Bum) (08/26/88)
In article <936@cerebus.UUCP> ronc@cerebus.UUCP (Ronald O. Christian) writes: >It could be that you don't see a lot of traffic on problems with Xenix >because a lot of people struggling with Xenix don't have access to >Usenet because they can't get the gol-durned uucp to work. When you're >effectively cut off from the rest of humanity, your voice is small and >thin indeed. this system didn't get the "fixed" uucp until june or july this year. prior to that i only chatted with about 200 or so different systems. yes, my voice was small and thin. ;-) >As for support, we called SCO today with a trivial question about >their uucp, and they scheduled an answer for next Tuesday. The >question was, how do you send a string in your chat script with >a space in it? [ and then explains why it is impossible ... ] that's right. without the "fixed" uucp you can't send a space in a chat script. the new method (version 2 uucp (?)) is foo\sbar to send 'foo bar'. i find the net to be much more useful for information. sco is great, i have to give them that much credit, but there aren't anywheres near as many sco employees as net users ;-) -- John F. Haugh II (jfh@rpp386.UUCP) HASA, "S" Division "If the code and the comments disagree, then both are probably wrong." -- Norm Schryer
fr@icdi10.uucp (Fred Rump from home) (08/26/88)
In article <936@cerebus.UUCP>, ronc@cerebus.UUCP (Ronald O. Christian) writes: [ In article <1585@spdcc.COM[ dyer@spdcc.COM (Steve Dyer) writes: [ >When someone flames so strongly about a product and company as you have, [ >presenting some evidence and more invective, when that is contrary to a lot [ >of people's reported experience, it's worth wondering what's going on. [ >What's your support experience been with SCO? What were the applications [ >you were running? Situations differ, but this is quite anomalous. [ [ It could be that you don't see a lot of traffic on problems with Xenix [ because a lot of people struggling with Xenix don't have access to [ Usenet because they can't get the gol-durned uucp to work. When you're [ effectively cut off from the rest of humanity, your voice is small and [ thin indeed. Ok, few Xenix users are on the net. How would you like about 300,000 new sites hang this net by the b****? I'm sure many of the voices you hear from Xenix folks are from developers and VARS who individually represent many other users of their systems. While conversly many of the 286/386 sys5 talkers bought one for themselves to play with because they use big daddy at work and it was cheap. You seem to forget entirely that SCO/Microsoft Xenix sales are substantially bigger than AT&T UNIX world out of pure love for the essence of standards? And as far as Xenix users not being on the net, maybe they're just quietly listening as nodes of somebody's feed site but have little to add to the conversation. They do have work to perform and this news business takes a little time - just a little. In our case we have users all over this land. We feed them what is meaningful. Most talk here is entirely too technical for the Xenix user. Since even the term UUCP would be a meaningless acronysm we just show them how to use it, not how it works. Hell I don't know that either. [ As for support, we called SCO today with a trivial question about [ their uucp, and they scheduled an answer for next Tuesday. The [ Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) I don't know when you called for next Tuesday, but our arrangement gives us call backs within the hour. Perhaps you bought the 'call back next Tuesday' plan for support. I would guess that Fujitsu can afford to pay for regular support or you can always get a good VAR to help you out. -- {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!cdin-1!icdi10!fr 26 Warren St. or ...{bellcore!bpa rutgers!bpa}!cdin-1!icdi10!fr Beverly, NJ 08010 or...!bikini.cis.ufl.edu!ki4pv!cdis-1!cdin-1!icdi10!fr 609-386-6846 "Freude... Alle Menschen werden Brder..." - Schiller
daveh@marob.MASA.COM (Dave Hammond) (08/27/88)
In article <936@cerebus.UUCP> ronc@cerebus.UUCP (Ronald O. Christian) writes: >It could be that you don't see a lot of traffic on problems with Xenix >because a lot of people struggling with Xenix don't have access to >Usenet because they can't get the gol-durned uucp to work. When you're >effectively cut off from the rest of humanity, your voice is small and >thin indeed. I have installed a great many Xenix 2.1.3 and 2.2.x systems, and have NEVER had a uucp problem that wasn't related to either a hardware problem (modem ctrl signals don't do what dial() wants) or a configuration problem (permissions, etc). Admittedly, most of these sites use uucp inhouse on a hardwire, but at least 1 machine at each site has an outside uucp connection. We play host to every Xenix site we manage and bounce mail amongst our customers and the outside world. The modems vary, but all are generic, cheap, internal Hayes-compatible 2400 baud units. I will state that the 2.2.x uucp is a far-sight better than 2.1.3, and the Trailblazer upgrade option (which this very same net recently apprised me of -- and I fell in LOVE with) contains all the nifty L.sys scripting features that you are in need of. >As for support, we called SCO today with a trivial question about >their uucp, and they scheduled an answer for next Tuesday. The >question was, how do you send a string in your chat script with >a space in it? (Like "foo bar".) If you write >[...examples deleted...] >From the documentation it appears to be impossible to either force >a whitespace (tab or space, I don't care) in a chat script string >or even send a string without a trailing carrage return. This is >a usable Unix? See my above comment about the Trailblazer uucp upgrade. It allows \c, \d, \nnn and all that stuff. Boy, isn't it great to ask a question [I asked the same question last week], get tons of net response, then answer the same question a week later like an *authority* :-) Dave Hammond UUCP: {uunet|...}!masa.com!{dsix2|marob}!daveh DOMAIN: dsix2!daveh@masa.com ------------------------------------------------------------------------------
pete@romed.UUCP (Pete Rourke) (08/27/88)
In article <936@cerebus.UUCP> ronc@cerebus.UUCP (Ronald O. Christian) writes: >In article <1585@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >>When someone flames so strongly about a product and company as you have, >>presenting some evidence and more invective, when that is contrary to a lot >>of people's reported experience, it's worth wondering what's going on. >>What's your support experience been with SCO? What were the applications >>you were running? Situations differ, but this is quite anomalous. > >It could be that you don't see a lot of traffic on problems with Xenix >because a lot of people struggling with Xenix don't have access to >Usenet because they can't get the gol-durned uucp to work. When you're >effectively cut off from the rest of humanity, your voice is small and >thin indeed. > >As for support, we called SCO today with a trivial question about >their uucp, and they scheduled an answer for next Tuesday. The >question was, how do you send a string in your chat script with >a space in it? (Like "foo bar".) If you write >or even send a string without a trailing carrage return. This is >a usable Unix? You bet this is a usable UNIX. Seemingly I have had no difficulty using chat scripts with a space in it since SCO had a many announced release of the Telebit uucico. (last year). Do a grep of the maps directory to find out how many XENIX sites there are STRUGGLING. I did, and found 1263 that spelled Xenix, and 2392 that spelled XENIX. Sure are lots of folks cain't get their gol-durned uucp to work, you say? Gosh, try the grep on your favorite *NIX vendor and see if the number stacks up. Some of those users didn't look like English was their native language, and they figured out how to do it. Seems hardly worth the phone call to SCO technical folks about. Trivial questions merit trivial response times. If you read much of this news group, at least once a week is a posting about chat scripts with the explanation to pursue the available Telebit uucico from SCO. I bet you'd even get it before the return phone call next Tuesday. (:-} Pete Rourke Tulsa, OK
tanner@ki4pv.uucp (Dr. T. Andrews) (08/28/88)
In article <7013@icdi10.uucp>, fr@icdi10.uucp (Fred Rump from home) writes: ) In article <936@cerebus.UUCP>, ronc@cerebus.UUCP (Ronald O. Christian) writes: ) [ In article <1585@spdcc.COM[ dyer@spdcc.COM (Steve Dyer) writes: ) [ As for support, we called SCO today with a trivial question about ) [ their uucp, and they scheduled an answer for next Tuesday. ) ) I don't know when you called for next Tuesday, but our arrangement gives us ) call backs within the hour. It should be noted that SCO has multiple levels of support. It starts with the "we can write that down, but we won't forward it to anyone to be fixed" plan (very economical plan; however, as I don't recall being pleased when they told me this in reponse to a bug report, it may not be a popular plan). The high end of SCO support costs more than the product itself. Yes, accepting bug reports counts as "support". Yes, the fast call-back is for real. No, it doesn't mean that the bugs will necessarily be understood or fixed, but someone WILL have listened. Better: in the next release, many times, the bug will be fixed. Not always, and you can be sure that you won't get useful feed-back for reporting the bug (after paying for the privilege), but they do have two things which set them ahead of one other big vendor: they do often fix the bugs, and have a better than 50% success rate on actually shipping things when they say that they will! -- ...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tanner
ronc@cerebus.UUCP (Ronald O. Christian) (08/30/88)
Sigh. And another reason you may not see too much criticisim
of Xenix in this newsgroup is that such articles draw personal
attacks from Xenix zealots. I would have expected this from
one of those pre-pubescent bulletin boards, but expected a more
civilized response from a Usenet technical newsgroup.
If the answer to my question was so trivial, why didn't SCO answer
it over the phone? A simple "you need the Telebit disk" would have
sufficed. SCO's "hotline" may be single-handedly keeping the other
Intel-based unix flavors in business.
I see I was correct in my decision to stick to big iron. Leave
PC's to the children.
Ron
--
Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.)
{amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc
Calling all Fujitsu Usenet sites! Contact cerebus!ronc or
ronc@fai.com to establish uucp connection.bill@carpet.WLK.COM (Bill Kennedy) (08/30/88)
In article <945@cerebus.UUCP> ronc@cerebus.UUCP (Ronald O. Christian) writes: >Sigh. And another reason you may not see too much criticisim >of Xenix in this newsgroup is that such articles draw personal >attacks from Xenix zealots. I would have expected this from >one of those pre-pubescent bulletin boards, but expected a more >civilized response from a Usenet technical newsgroup. I take offense at that and I most certainly do not qualify as a Xenix zealot. I have a Xenix system, a Microport V/AT, and an AT&T 386 UNIX, each for a different reason, and in no case is zeal involved at all. As a reader of each of the groups this was posted to, I think that the response was measured and appropriate. I suggest you change "Sigh" to "Yawn", the former indicates interest, the latter seems to better fit snobbery. >If the answer to my question was so trivial, why didn't SCO answer >it over the phone? A simple "you need the Telebit disk" would have >sufficed. SCO's "hotline" may be single-handedly keeping the other >Intel-based unix flavors in business. Because they don't have technical personnel answering the switchboard phones, wasn't that obvious? Didn't you gripe about that? Why should a switchboard operator know about that? Were you left in the lurch? Didn't countless people suggest "you need the Telebit disk"? Did you call back and ask for it? If my experience is any barometer you did not because I got mine by return mail. What's wrong with having non-tech's answer the phone? Call IBM at Armonk (since you said "big iron"), can the switchboard operator send you the Telebit disk? What do they say? >I see I was correct in my decision to stick to big iron. Leave >PC's to the children. Fine, stick to the big iron and quit grousing in the children's newsgroup. You were politely told what solution to pursue, you reject that, so go away. -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/30/88)
In article <7013@icdi10.uucp> fr@icdi10.uucp (Fred Rump from home) writes: | [ It could be that you don't see a lot of traffic on problems with Xenix | [ because a lot of people struggling with Xenix don't have access to | [ Usenet because they can't get the gol-durned uucp to work. When you're | [ effectively cut off from the rest of humanity, your voice is small and | [ thin indeed. I wouldn't claim that uucp on early versions (like 2.1.2) were pretty grim, but the "Telebit" uucp is solid as far as I can tell. I would be lieve that many sites can't support news due to disk space. | I'm sure many of the voices you hear from Xenix folks are from developers and | VARS who individually represent many other users of their systems. While | conversly many of the 286/386 sys5 talkers bought one for themselves to play | with because they use big daddy at work and it was cheap. Actually a 20MHz 386+387 compares favorably with a Sun 3/160, given the same memory size. It's a little faster and a lot cheaper. And there's a LOT more software available at a reasonable price. | little time - just a little. In our case we have users all over this land. | We feed them what is meaningful. Most talk here is entirely too technical for | the Xenix user. I don't see much between the average users of any system... the ones in schools and research labs tend to have the same level regardless of the machine on which they host. The types who use it as a tool are also the same anywhere. People who run spreadsheets and payrolls and stuff usually don't want to hear anything technical. In general I agree with you, but I suspect that the average Xenix user is perhaps a bit more technical than I conclude from your posting. If I misread the posting the fault is mine. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
ts@cup.portal.com (Tim W Smith) (11/06/88)
> > I don't think they'll be able to make this claim, either. > ISC 386/ix is real System V and has virtual consoles. Furthermore, the latest version of 386/ix can execute Xenix binaries ( including 286 Xenix binaries ), so you can have complete System V release 3 *and* Xenix. Tim Smith