[Tfug] Quick question about Python...

[Jim March]

Replying to various things here...

----
> Question: when Python code is turned into .pyc bytecode, is there a Python
> interpreter still needed?  If so it probably can't get past the Federal
> rules as written now.

By default, yes.  But there are compilers to compile Python down to
machine code (primarily for embedded use).  But, again, if your
developer isn't aware of this, you've got bigger fish to fry.
----

Oh, I'm sure the developer IS aware, or at least can be told.

Actually, the people who assembled the LiveCD-based demo (a re-spun Ubuntu
Gutsy) aren't the ones that wrote the Python-based user interface.

But arright, that means it's possible to certify this stuff.  That's good.

----
Why is it needed? What's wrong with writing an "X" on a piece of paper?
Seems to work fine for some other countries.

Andy
----

Andy, the first problem is that the US simply votes on more stuff than most
other countries, even ones we acknowledge as "Democracies".  More
initiatives, more lower-ticket races (down to the proverbial dogcatcher...)
means more hand-counting.

And that means we'd need more warm bodies.

Various proposals have been floated on how to get said bodies...high
school/college civics classes maybe?

But the second problem is that the electronic voting industry did something
clever up front: they got in bed with the "disability lobby" and had
electronic voting systems pushed as the solution to the blind/disabled
voting without assistance from family/friends.  That really started when
Diebold paid money to the National Federation of the Blind to have them file
suit against banks whose ATMs didn't support blind use.  The lawsuits were
used to force the banks to buy, you guessed it, Diebold ATMs.  When Diebold
got into voting in 2002 they took this same con into that market.

The open-source voting system in development allows voting by the blind.

----
> If not, it'll never get past Federal certification...

Interesting idea that a voting system is safe only if
the code isn't provided as easily inspectable source code. :-)
----

Yeah, I know.

Sigh.

Look, the model they set up was like so:

1) Voting system vendors brew up stuff based on a "rulebook" published by
the Federal Election Commission.  Among the rules: no interpreted code.

2) Test labs hired by the vendors check the source code against the rulebook
and basic sanity.

3) The labs then compile the code and publish hash totals (SHA-5 mostly).

4) Customer counties who buy the crap can check hashes of what they've got
against the published hashes.

So far two of the three original test labs have been thrown out for poor
performance.  Both were based in Huntsville AL where they did a lot of
military systems testing at the Redstone National Arsenal.  The worst of
'em, Ciber, was clearly so bad that if you jammed a pocket calculator
halfway into a banana and paid them enough money, they'd have certified
it...

----
Also, wasn't the Pima County board of elections claiming that they
shouldn't have to release their database files to the local Democratic
Party because their database fields had code in them that people
could look at?

I wonder how the system they use ever got certified?
Perhaps they include only compiled code that you can see but you can't
understand? :-)

Perhaps their vendor is better at arguing or lawyering or contributing $?
----

Believe me, despite the ban on interpreted code, a LOT got used anyways.
Like I said, the labs are a joke.  We used that very argument in the Pima
lawsuit: if there's "code" in the databases, it can't be legal voting
software because it's interpreted.

That doesn't necessarily mean the ban on interpreted code was ever a good
idea...

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20080511/55a414c6/attachment-0002.html>