[Tfug] Hardware reliability

[Bexley Hall]

--- On Mon, 4/20/09, Zack Williams <zdwzdw at gmail.com> wrote:

> > 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.

Yes.  The difference (vs. my environment) is that the website
is far more fluid in its design and (eventual) deployment.
I.e., even production versions are likely to change over time.

In my case, I'm developing "products" (physical items) so there
is far less change; you can't release code with bugs (because
a recall is incredibly expensive!) and there is very little
incentive to releasing different versions of the same item
(as that makes it hard for consumers to differentiate between
"Model X Version 2.3" and "Model X Version 2.4").

OTOH, during development, its not uncommon to start a new branch
to get a snapshot of a prototype release, "dog and pony", etc.
Or, to record state prior to some formal testing (e.g., just
prior to shake-n-bake)

> As it sounds like your development process is pretty insular,
> that probably wouldn't be of much use to you.

I have to interface with others.  But, usually from significant
milestones -- not small incremental changes.  So, if a particular
characteristic of the hardware/software needs to be evaluated
(or, manufacturing jigs developed), there needs to be a way
for us all to get on the same  page.  And, to be able to *return*
to that page if need be.

> 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.

I don't think speed would be a factor.  Again, it's a different
sort of development than what you're used to.  One or two files
may be "in flux" at a given time.  E.g., an implementation
file and an interface file (.c and .h, etc.).  And, it might be 
days before a file needs to be checked back in  :-/

I haven't (yet) figured out how to put the database(s) on this
project under version control.   :-(  I'm still trying to
develop a good mental model of the role they play so I can
draw parallels to how that role would *normally* be handled
(in a more conventional implementation)

> >> 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,

I'd go further than that:  not just "cheaper" but, rather, "they
don't KNOW any better".  :-/

> 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.

Exactly.