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

[Joe Bob Willie]

In article <1988Aug26.235151.18037 at gpu.utcs.toronto.edu> woods at gpu.utcs.Toronto.EDU (Greg Woods) writes:
>How about running it for a couple of weeks, with no nice factor, along
>with a shm and a sem tester, in multiple incarnations.  Meanwhile, do
>a WHOLE lot of disk and tty I/O.  In other words, push it to the limit.
>Make the machine so slow as to be un-usable for anything else.

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.

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.

any consultant or system builder or whatever who actually believes you
can run 32 users on an AT/286 running xenix is brain-dead.  i don't
even know if i'd put 24 users on anything smaller than a 20MHz compaq.
if you are stupid enough to overload a machine from a design perspective,
and still expect it to work, you get what you deserve.

ANY system if suitably overloaded will degrade.  with races present,
ANY suitably overloaded system will FAIL.  last time i checked there
were quite a few race conditions remaining in the at&t code.  i am
certain some were in the ipc code.

but most of all, if all you can do is bash SCO.  don't bother.  we all
know how much you hate xenix.
-- 
=-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-=
               Very Long Address: John.F.Haugh at rpp386.dallas.tx.us
                         Very Short Address: jfh at rpp386
                           "ANSI C: Just say no" -- Me