Edmund Storms wrote:

You all would fail at solving murder mysteries.  Consider the facts:

1. Diebold makes ATMs, which are secure. Therefore, they know how to
do a good job.
2. Diebold is owned by people who are strong supporters of the
Republican party. Therefore they have a self interest  in gaming the
system. . . . etc.

I doubt that's enough evidence to convict someone in court. It is highly suggestive. If I were in charge of the Justice Dept. I would have the FBI all over them.

I dunno though . . . I have been in programming for a long time, and I have seen lots of astounding screw ups, including ones that drove major corporations such as DEC out of business. As far as I know they were all caused by stupidity, not malevolence.

By the way . . . Back in the 1970s they used Data General NOVAs for voting machines. I once knew every system call (STMA and STMB) for those machines in my sleep. They were wonderful for the purposes they were intended for, but you would have to be crazy to use one as a vote tallying machine. Anyone with a system manager password could hop in with a modem and change any byte in RAM or on the disk without leaving a trace, and the owners seldom changed the password. Plus anyone with physical access to the machine could usually find the password easily enough.

The New Yorker published a description of what sounded like vote fraud to me, with one of the Novas. Someone at the election headquarters made a phone call, someone else noticed the modem was active, and Shazam! -- the numbers changed. Heck, I could have done that knowing practically nothing about the application program. Not a lot of places to hide data on a 10 MB disk. You could sweep through the whole thing in no time, with a program that would be invisible to anyone else.

I am pretty sure it was a Data General Nova or Micronova that played a prominent role in the Three Mile Island meltdown. I think I read that somewhere, and the description of the machine sounds like one. It played a most unfortunate role. It was printing out crucial data showing the reactor status, but the printer was very slow -- as I well recall. It fell behind, sometimes by hours. The only way to jump to the current data was to reset the program which deleted all pending, unprinted data. So a great deal of crucial data was lost because of a program design flaw that any Nova programmer could have corrected in 10 minutes, during the design process. (Not during the disaster!)

- Jed

Reply via email to