End this flaming nonsense (was: Re: Test SCO Xenix IPC reliability)

[Greg Woods]

In article <380 at pigs.UUCP> haugj at pigs.UUCP (Joe Bob Willie) writes:
>when the load average on my systems here at work get up over 15 or 20,
>we start counting the minutes until the machine crashes.  if i was planning
>on running the mix you suggest, i would get a bigger machine.  we
>manage to find all manner of race conditions in the kernel running that
>heavy of a load.  go get some hardware that can handle the load without
>thrashing.

I agree.  Unfortunately, you often can't tell a user (ie: client) that.
They just won't believe you, (and if you think I hate Xenix :-( ...).
Also, unfortunately, except for the interrupts from the "tons of I/O",
which weren't there after we got smart I/O cards (from Consensys), the
load I described doesn't really require that much CPU.  In fact, the
load average on a machine running as our "network" server was lower than
when I ran simultaneous compiles.  The compiler didn't seem to cause any
crashes.  The machine certianly wasn't thrashing, either when compiling,
nor testing.  [BTW: let's not argue about "load averages", and yes, they
were seperate machines for testing and development.]

>better still, go read the source code and look at all those wonderful
>comments about where and what races exist.  unix from anyone is far
>from 100% bug free.  no fair dumping a load suitable for a vax 8850 on
>an intel 8088.

I never said it was bug free.  What I was trying to get across was the
fact that the implementation of Xenix (in general) is considerably
buggier than lots of other "versions" of Unix.

I've had lots of reports of known and sometimes fixed bugs in the AT&T
code.  Even (especially) in the IPC stuff.  However, let's not give the
impression that Unix is a buggy, old, monster.  It is probably better
than many other "systems" of similar size and complexity.  It certianly
has enjoyed the time and usage to give it a great deal of maturity.  One
of the problems (and benifits) of a system supplied with optional
source is that those with source can fix problems on the spot.  The rest
of us have to wait for AT&T, or our vendors, to discover the same
problems, and make the same fixes, or hope that fixes filter their way
back to AT&T and eventually are released to us.

At the same time, I still believe that a lot of the extra bugs come from
the compiler that SCO uses (ie: MS-C).  They will be in a much better
position now that they are beginning to use the latest version, and if
it is as good as it is cracked up to be, Xenix may get considerably
better "overnight".

I also believe that a large number of bugs stem from the heritage of
Xenix (ie:  it's "still" basically an "enhanced" 7th Edition Unix).  A
lot of the so-called Xenix "features" are really just backwards
compatibility for things that have, for the most part, disappeared
"eons" ago!  (Now we're talkin' MONSTER.  Imagine if there was support
for V7 tty, SysIII tty, BSD newtty, termio, AND streamio?)

BTW:  Those SCO guy's got a bad reputation (at least with the people
I've talked to) when they delivered the 386 OS with utilities compiled
by the 286 compiler.  I think they did this because of a then VERY buggy
386 compiler.  (it was either that, or the fact that they were so
over-worked doing support, they didn't have time to re-compile
everything :-).  The latest version of 386/ix [1.0.6] includes a new
compiler, and EVERYTHING has been re-compiled.  In fact, it is rumored
that the "upgrade" consists of an entire set of floppies.  (The
current version [1.0.5] runs quite well as is!)  The question is:
should I re-compile all my software too? :-)

[ We agree on one thing:  ANSI C may not be what it's cracked up to be
:-).  However, if you're using the Xenix compiler, you have do deal with
a considerably more "ANSI'fied" compiler than I!]
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada