In article <1726621.QYBZDup5ya@xxxxxxxxxxxxxxx>,
Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> wrote:
> You only validate my point. If an /application/ lockup is resolved by
> changing underlying hardware, then it's most likely the 'bridge' that's to
> blame -- the O/S. It is nothing unprecedented. Windows has a tendency to
Changing the hardware also can change the application, since the
application resides in flash on the hardware. There have been serious
questions raised over the security of the field update mechanism for
these machines (the machine does not validate update code), so it is
quite possible that they did not want to (or were not allowed to by
election officials) issue an application fix as an update, as that would
have required 4700 applications of the flawed update procedure, and
instead did it as a board swap. A board swap is a lot better in this
situation as they can then account for the returned boards, and verify
that they are the old boards, and so deduce that the new boards are all
installed (and depending on how good their part tracking is, if a
machine doesn't get updated, they might be able to identify it by the
serial numbers on the returned boards, and deal with it).
(Well, a competent company could account for the returned boards...I
have no idea if Diebold can).
Without information that we don't have from the story, it is simply not
possible to say where the fault was, and so trying to blame it on
Microsoft is at best premature, and at worst harmful, as it might shift
blame away from Diebold.
--
--Tim Smith
|
|
