[Tfug] Hardware reliability

[Zack Williams]

> In my case, I am only working/developing on a single machine
> (well, maybe writing code on one machine, designing hardware
> on another and working on mechanical packaging on a third;
> but, each task really only exists in one place).  So, CVS
> works fine if I want/need to figure out how I got to where
> I am currently.

I often assist in website development, and keeping a site in a
network-enabled version control system for development and deployment
makes things really easy - no more messing with ftp or scp, missing
files, etc.    If what worked on the dev machine doesn't work in
production, you can just roll back to the previous version.    As it
sounds like your development process is pretty insular, that probably
wouldn't be of much use to you.

If you're still using CVS, I'd recommend checking out git.   Git is
much faster than any other version control system I've used, and
doesn't litter tracking directories (.cvs or .svn) around the
filesystem structure.

>> At Macworld last January, I talked to the guys at DriveSavers, and
>> they said the order of failure on non-physically damaged
>> drives was pretty much:
>
> Note the conditional there ------ ^^^^^^^^^^^^^^^^^^^^^^^^
> I saw some proprietary documentation from a (unnamed) disk
> manufacturer that documented some *huge* percentage of the
> drives returned to them as "defective" were actually *not*
> defective (something like 60% or more!).  Rather, the
> "problems" were OS bugs or folks not knowing what to expect
> when "drive errors" crept in.

I'd also write that up to not knowing what to do when a drive is
having issues - bad cabling, bad OS drivers, etc. could all lead to
the product being shipped back.   For many, it's cheaper to just
return the drive, or if it's been used for a while RMA it or buy a
replacement and then restore the data. That's probably what the
manufacturers are dealing with, as opposed to a data recovery company.

- Zack