Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!nsc!pyramid!infmx!aland
From: aland@informix.com (Colonel Panic)
Newsgroups: comp.unix.sysv386
Subject: Re: Does ESIX still not support RLL?
Summary: the compatibility myth
Message-ID: <1991Apr23.193727.12155@informix.com>
Date: 23 Apr 91 19:37:27 GMT
References: <1991Apr21.155642.1586@shambala.uucp> <1991Apr22.210543.27730@thyme.jpl.nasa.gov> <512@pyrite.nj.pyramid.com>
Sender: news@informix.com (Usenet News)
Organization: Alferd Packer's Legendary Coronary Fast Food Cannibal Bar & Buffet
Lines: 52

In article <512@pyrite.nj.pyramid.com> bill@pyrite.UUCP (Bill Pechter) writes:
>In article <1991Apr22.210543.27730@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes:
>>The myth that ESIX doesn't support RLL controllers is a bit of marketing
>>hype.  ESIX documentation states unequivocally that ESIX does support
>>RLL, and I can unequivocally state that both 5.3.2.C and 5.3.2.D both
>>support RLL very nicely.
>
>But when I call them and ask if it'll run with my Perstor controller they
>refuse to say it will.  I can't see laying out the money for a copy of
>Unix that may not work on my machine.  If they could tell me that it works
>the check would be in the mail today.
>
>Bill Pechter 

This isn't a fair criticism.  What ESIX is really saying by "refusing
to say that (insert nonstandard controller name here) will" work is
that they don't include that particular hardware as part of their
test procedure, so they don't want to make any claim about the
compatibility of any vendor whose hardware they have not tested for
compatibility.

I can't remember if Perstor is a caching controller or a 
compressing/reconfiguring one, but the similar principle applies 
regardless.  If the *hardware* vendor claims that they are "100% 
compatible with X", that doesn't necessarily mean that the software 
vendor can take that at face value.  (Boy, could I tell you some horror
stories...  BIG NAME companies don't even get this right always.)

The way I'd look at it is this: if the *hardware* vendor is making
compatibility claims, and they are willing to back such claims
with a no-fault return policy, fine.  But if you encounter problems
with hardware that the o/s vendor doesn't claim to support (and lacks
the means to test in-house), it's hardly fair to blame the o/s vendor.
If the problem doesn't reproduce in a supported configuration, there's
not a whole lot that they can do.

For example: let's say somebody's using a DPT caching controller
without a UPS and the power goes out.  The resulting corruption is
severe enough to thoroughly trash your database (on a raw partition)
and a couple of file systems beyond easy repair.  Now, in their ads,
DPT claims "100% compatibility" with WD1003 interfaces, and the WD1003
is a supported controller.  Is it ESIX's fault that your data is
trashed?

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland
I says, "Earl, this hill can spill us 
         you better slow down or you're gonna kill us
         just make one mistake, and it's the Pearly Gates 
         for them 85 crates of U.S.D.A.-approved cluckers.
         You wanna hit second gear, please?"
                                  -- 'C. W. McCall', "Wolf Creek Pass"