Ohio Audit Reveals More Diebold Problems
armb writes with a link to a Wired Blog entry about irregularities found in Diebold databases from the state of Ohio. The election in question here is November 2006, and the corruption of the entries may raise doubts about accurate tabulations. "Vote totals in two separate databases that should have been identical had different totals. Although Diebold explained that this was part of the system design for separate vote tables to get updated at different times during the tabulation process, the team questioned the wisdom of a design that creates non-identical vote totals. Tables in the database contained elements that were missing date and time stamps that would indicate when information was entered. Entries that did have date/time stamps showed a January 1, 1970 date. The database is built from Microsoft's Jet database engine. The engine, according to Microsoft, is vulnerable to corruption when a lot of concurrent activity is happening with the database, such as what occurs on an election night when results are uploaded and various servers are interacting with the database simultaneously."
Actually, in 2006, Ohio switched from red to blue, so by your logic, we shouldn't be hearing this...
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
I await the next problem-free election. You know, the one where no one can even insinuate anything went wrong.
- There will have to be perfect information about every tiny detail of that election, or they'll say "What are they not telling us? What are they trying to hide?"
- Everyone will have to find out absolutely everything at exactly the same time. Otherwise "Why did they wait to release that information? What were they trying to hide?"
- All of the ballots will have to be exactly the same. Otherwise "The ballots were misleading!". (Even though every locality has to have different ballots. Hmm.)
- All of the ballots will have to be in every dialect of every language, modern, extinct, or completely made up. Otherwise, it's "not fair".
- No voter can ever have ambiguous eligibility. I guess we'll all have to agree on who is a voter and who isn't before the election. This will have to include a comprehensive list of names there's unanimous agreement on.
- And voters will have to be able to "become" eligible up to the end of voting on election day. Otherwise, someone will be disenfranchised.
- And, of course, none of the thousands of election workers can even make the tiniest mistake.
Without this, the election is FIXED. (Unless my guy won. Then it was fair.)
...ANYWHERE in the system.
Surest sign of technical incompetence there is.
you had me at #!
"Jet Blue/ESE is nowhere near the design of say, Oracle or PostgreSQL, or even MSSQL for that matter. It's about on the level of version 3 or 4 of MySQL (using MyISAM, not InnoDB), or perhaps SQLite."
... You say that as if these two databases are anywhere NEAR the same level. They're not. ... You say THAT as if MSSQL is somehow a lesser DB than Postgre. It's not. In fact, it's just as capable and worthy as Oracle for many tasks
Huh?
1. "Oracle or Postgre"
2. "or even MSSQL"
3. "It's about on the level of version 3 or 4 of MySQL" OK, this is the killer sentence. MySQL 4 doesn't allow nested select statements ANYWHERE (Not in SELECT, FROM or WHERE clauses), it doesn't support HAVING it's prone to full table scans when they're not really needed. I'm a HUGE MySQL supporter--look at my recent comments, I've been defending MySQL--but, frankly, Jet is a better database than MySQL 4. Hands down. Now, MySQL 5 beats its pants off, but c'mon, the query optimizer in 4.x alone is enough to give Jet the win.