Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.unix.i386
Subject: Re: ESDI controller recommendations
Summary: clones != computers;  AT&T/ISC/Bell/uport/SCO != UNIX
Message-ID: <71@calcite.UUCP>
Date: 4 Sep 89 20:03:43 GMT
References: <121@mdi386.UUCP> <1474@wb3ffv.ampr.org> <4843@looking.on.ca> <1989Sep4.024559.13279@ddsw1.MCS.COM>
Organization: Rhyolite Software, Mountain View, CA
Lines: 37

In article <1989Sep4.024559.13279@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes:
> > ...[a loud rebuttal]...
> Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
> Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910]
>Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"

I got Mr. Denninger's dander up.  Be careful or thick skinned when not
complimenting what people sell.  He is obviously wrong and inconsistent on
several technical issues, but such technicalities are not germane to what
he is saying.

As I agreed in the article which got him excited, the DPT controller sounds
good for small, slow computers such as this 20MHz, 8MB clone, for those of
us without the money, time, talent, or source to fix the SV kernel.  This
part of my life qualifies, so I would happily accept one for an extended
evaulation.  However, the simple professional honesty required in another
part of my life compels me to say the DPT controller is architecturally
wrong.  That AT&T et al currently make it useful and desirable is irrelevant.
There is no reason to lie to customers and say it is more than a neat and
cheap kludge around design flaws in some versions of SVR3, or to claim
those flaws are part of "UNIX."

In 1989, "fast" uniprocessor workstations are >=20 times a VAX 780, 3-5 times
faster than 386 clones.  True, they use 88K's, SPARK's, or MIPS-R3000's
instead of 386's and cost more than $2,500 (but <$25,000).  You can buy
multiprocessor workstations well over 100 VUPS (1VUP=1VAX 780).  At least
one such SVR3 until recently mapped raw disk I/O to cooked.  (Disagreement
on that point from a PC VAR are boring to a hack paid to work in that kernel.)

That we are now stuck with no more than half-dozen VUPS is no reason to get
religous.  This is comp.unix.i386, not biz.att or biz.MacroComputerSolutions.
People here snear at the silliness of DOS extended memory.  Let's not
permanently wed an analogous kludge for what are hopefully temporary O/S bugs.


Vernon Schryver
vjs@calcite.uucp     or    ...!{sgi,pyramid}!calcite!vjs