Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!cpsc.ucalgary.ca!ctycal!ingoldsb
From: ingoldsb@ctycal.UUCP (Terry Ingoldsby)
Newsgroups: comp.sys.intel
Subject: Re: Intel bugs / bugged by Intel :-(
Summary: Life support equipment
Message-ID: <505@ctycal.UUCP>
Date: 30 Oct 90 19:27:30 GMT
References: <JSP.90Oct25155458@glia.u.washington.edu> <13056@encore.Encore.COM>
Organization: The City of Calgary, Ab
Lines: 50

In article <13056@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes:
> In article <JSP.90Oct25155458@glia.u.washington.edu> jsp@glia.u.washington.edu (Jeff Prothero) writes:
...
> >There
> >are a *lot* of '386s out there, some of them in embedded systems
> >performing life-critical tasks.  It doesn't take much imagination to
> >construct a scenario leading from a deliberately suppressed bug report
> >to bodybag(s) to a massive lawsuit.
...
> "Motorola, Inc. General policy does not recommend the use of its components
> in life support applications wherein a failure or malfunction of the component
> may directly threaten life or injury. Per Motorola Terms and Conditions of
> Sale, the user of Motorola components in life support applications assumes all
> risk of such use and indemnifies Motorola against all damages."
> 
> and...
> 
> "NATIONAL PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE
> SUPPOERT DEVICES OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE 
> PRESIDENT OF NATIONAL SEMICONDUCTOR CORPORATION. As used herein:
> 

I sympathize completely with Jerry (who complains that Intel won't publish
a bug list).  I use software from a vendor who has much the same attitude.
It is *infuriating* to twiddle with something for days, only to conclude
that the fault lies in someone else's product, log the complaint, and hear
that it is a known bug.  No excuse for it.  Why do we tolerate it?

There is a difference between the refusal to publish a bug list and the
disclaimer for using a product in a life support application.  In fairness
to the vendor, they build a product that will satisfy *most* users.  This
means that incomplete testing procedures are used, both in design and
production.  This is not sloppy workmanship, it is economics.  If you can
catch most of the flaws with a 30 second test, is it reasonable to spend
a day to certify that a chip is 100% OK?  The cost of the component
would soar.  Not only that, but you'd have to establish an insurance
fund in case some flaw did slip through (it may not be feasible to
guarantee 100% performance).  Most users would rather take the chance
that their workstation might be down 1 day a year, than pay 5 times the
price for the station.

In life critical applications, either the supplier, or the VAR can
perform the necessary tests and charge only those people that need
the high reliability.  That is probably why medical equipment costs
*so* much. 

-- 
  Terry Ingoldsby                ctycal!ingoldsb%cpsc.ucalgary.ca
  Land Information Services                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb