[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-dev
Subject:    [Gpsd-users] Re: [Gpsd-dev] Considering a 2.27 point release
From:       hamish_nospam () yahoo ! com (Hamish)
Date:       2005-06-28 0:44:13
Message-ID: 20050628124413.263696fb.hamish_nospam () yahoo ! com
[Download RAW message or body]

> > > Question: Do we care if it takes 10 minutes to reflash the
> > > firmware or do we want something fast? I ask because there appears
> > > to be an alternate method I can use that's slow but easy... it
> > > looks like such a method might be possible. I have no proof of
> > > this yet.
..
> > The longer it takes to do the reflash, the more chance that the
> > cat/child/S.O./ConEd has to disrupt the process and leave you with a
> > fancy paper-weight. Having said that, if "slow but easy" means less
> > bug prone, then perhaps it is better than "fast but complicated".
..
> I guess the feeling I'm getting is "faster is better, but safety and
> reliability are paramount." Which means no dawdling loading up code,
> but no hackish shortcuts to unnecessarily save a millisecond. Gotcha.

The problem is that in this case "safety and reliability" are partially
a function of "faster", as an interrupted flash means borking. (and I've
"interrupted" enough wires on my bench over the years to know that even
when you are careful cables do get yanked)

Catch-22 but I think your summary above is the best course. No dawdling
but no tricks either. Burning EEPROM will take the time it needs...


> Plenty of other things (your dsl router, bios, raid card, etc.) can
> take quite a while to flash.

Plenty of other things suck. Doesn't mean we should too.


Hamish

[prev in list] [next in list] [prev in thread] [next in thread]