From: blockedofcourse@foo.invalid   
      
   > I did wonder, a few days ago, how a software update could fix this problem.   
      
   If you more frequently update the item(s) that are likely being affected,   
   then the fault can be avoided or the chance of occurrence minimized.   
      
   Many procedures require "confirmation".  That extra step minimizes the   
   chance of something being done incorrectly or unintentionally.   
      
   You can also look more suspiciously at data instead of just   
   trusting it.  E.g., if my thermostat reports a temperature of   
   X degrees... and, then, shortly thereafter, reports 2*X,   
   how likely is it that BOTH of those reports are correct?   
   Yet, I'd wager any code looking at data influenced by "other   
   factors" just assumes it is being correctly reported!   
      
   What is not known is what was susceptible to the disturbance:   
   data, code or an entire subassembly.  Increasingly, hardware is   
   the cause of software "glitches" as even the chip manufacturers   
   realize the "logic" doesn't always behave as intended (hence the   
   reasons for ECC on *internal* busses -- imagine what happens   
   when you have to rely on some engineer to have sorted out the correct   
   way to connect devices together and lay them out to preserve integrity?   
      
   Look at the number of devices made with processors that don't support   
   ECC on external busses.   
      
   Look at the number of them that *do* but the software doesn't know   
   what to do about CORRECTED errors -- beyond just chugging along   
   with the corrected data!   
      
   How reliable is a chunk of memory that hasn't been accessed in "some   
   time"?  Yet, the software designer likely ASSUMES that whatever it   
   held previously should still be there -- right??  What guarantees   
   can the *hardware* designer give him?  How long is "too long"   
   (defined as a PDF)?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)