Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!rpi!sci.ccny.cuny.edu!phri!marob!daveh
From: daveh@marob.masa.com (Dave Hammond)
Newsgroups: comp.unix.xenix
Subject: Re: Problems with SCO Unix/Xenix
Message-ID: <2672BA95.6696@marob.masa.com>
Date: 10 Jun 90 21:24:37 GMT
References: <11414@yunexus.UUCP> <300007@hpspcoi.HP.COM> <4664@minyos.xx.rmit.oz> <1990Jun9.135124.16301@bbt.se>
Reply-To: daveh@marob.masa.com (Dave Hammond)
Organization: ESCC,  New York City
Lines: 33

In article <1990Jun9.135124.16301@bbt.se> pgd@bbt.se (P.Garbha) writes:
>
>And under Xenix 386 2.3.1 "ps" used to give me seek error (until i
>made a binary patch to the program), but "w" and "uptime" works
>allright. Another case is fsck, which just silently dies when trying
>to check my system disk. No error message, no nothing.
>
>This only makes me wonder what kind of programmers SCO are keeping.
>Obviosly they cannot produce working code, and in addition manages to
>screw up those programs which happend to be working before they got
>their hands on them.

Whoa there, bud.  I am not a SCO-vangelist, however I respect a
reasonably competant product.

I have made my living managing/programming Unix on Intel machines for
over 5 years.  I have run SCO on hardware ranging from Everex parts
stuffed into a no-name box to brand-name machines from Compaq, HP and
IBM.  I have also run ISC ix/386, Venturcom Venix, IBM Xenix, Altos
Xenix, Tandy Xenix and MWC Coherent, all on Intel machines.  They all
have problems, some worse than others.  For production environments I
still recommend and install SCO.

Before you go maligning the SCO staff, check out your hardware for
components which are not supported or kernel configuration limits which
are obviously exceeded.

--
Dave Hammond
daveh@marob.masa.com
uunet!masa.com!marob!daveh

Flames to me (screw /dev/null, I can take the heat :-)