-=> Quoting Lewin Edwards to Rick Collins <=-
-=> FidoMail to 1:163/215, please.-=<
le> LE>> Look, a return to base is a return to base is a return to
le> base. LE>> Shipping costs, labor costs, downtime. SAME economic
le> cost. The LE>> difference between a physically destroyed
le> component and an erased LE>> EEPROM is nothing but a semantic
le> argument to Joe(oan) Q. Average.
RC> So, your position is "hardware damage" occurs when the customer
RC> _thinks_ the hardware is damaged?
RC> Naw.  Hardware damage occurs when the hardware _is_ damaged -
RC> regardless of what the customer thinks.
le> I presume you saw the start of this thread? This started out as a
le> borderline semantic argument and it's now waaaaaaaaaay into pure
le> philosophical gray areas. 
I was here at the beginning of the thread, yes.
le> So I will give my definition of hardware damage : compromising
le> the functionality of a device or component of a device in such a
le> way that it cannot be restored to normal functionality by
le> operating the user-accessible controls on the device. 
That's fine.  You didn't give a definition before, though, did you? 
You essentially claimed that if a EEPROM was overwritten or otherwise
changed, then the "hardware" has been damaged by the virus.  Others
(I among them) maintain that "no, the EEPROM is fully functional.  It
can be reprogrammed.  It isn't damaged".
You went on to state (above) that was a "semantic argument" as far as
Joe or Joan Public was concerned.
That led to my comment.
You have now "moved the yardsticks" and re-defined what you mean by
"hardware damage".  Under your definition, viruses can damage
hardware.  However, under your definition, if a virus trashes my copy
of Wizard.exe (which I wrote), the hardware will be damaged.  'Cause
the source was lost many years ago, I don't have a copy of the
executable, and therefore can't restore it through "user-accessible"
controls.
:-)
TTFN. Rick.
Ottawa, ON 25 Dec 9:54 
--- Blue Wave/DOS v2.20
---------------