Minority Opinions

Not everyone can be mainstream, after all.

Archive for January 2013

Voting System Iceberg

with 3 comments

The more I learn about something, the more I become aware that I’ve just scratched the surface.  This week, it’s voting systems again, courtesy of Henrik Ingo’s blog.  He also writes about MySQL, which is how I discovered his writings, but what really intrigues me is his work on a secure online voting system, and his attempts to make it ideal.  Sadly, just as Arrow shot down the idea of a perfect ranked vote aggregation system, Ingo has produced a list of incompatible requirements for voting securely.  How can I verify that my vote was processed accurately, without being able to prove how I voted?

Math may come to the rescue here, in the form of encryption algorithms that allow certain mathematical operations to be performed on a set of encrypted ballots.  The explanations get a little more technical than I’m comfortable with, but if such a scheme is practical, then I can see how being able to verifiably add ballots would suffice for plurality, approval, or range voting.  What I don’t see is how you can properly format the ballot, prove that it’s properly formatted, verify that your ballot is among the ones in the final tally, and still be unable to prove to another person that you voted in a certain way.  There may well be ways to do that, particularly with certain constraints, but I’m not going to be the one designing them.

After all, I still have to convince myself that range voting is better than a Condorcet method.  I may yet get there, and I certainly buy the argument that approval voting is a perfect first step for a political body seeking improvement, but something still feels off.  Maybe it’s the way it feels too similar to plurality or a Borda count, with their obvious flaws.

Written by eswald

29 Jan 2013 at 9:51 pm

Posted in Politics, Technology

The Right Extraction

leave a comment »

At one point, I got annoyed with the sheer number of compression methods used to distribute source code and other packages, so I wrote a simple bash function to collapse the various incantations into a single word:

extract () {
  if [ -f $1 ] ; then
    case $1 in
      *.tar.bz2) tar xvjf $1 ;;
      *.tar.gz) tar xvzf $1 ;;
      *.bz2) bunzip2 $1 ;;
      *.rar) rar x $1 ;;
      *.gz) gunzip $1 ;;
      *.tar) tar xvf $1 ;;
      *.tbz2) tar xvjf $1 ;;
      *.tgz) tar xvzf $1 ;;
      *.zip) unzip $1 ;;
      *.Z) uncompress $1 ;;
      *.7z) 7z x $1 ;;
      *) echo "Don't know how to extract '$1'" ;;
    echo "'$1' is not a valid file!"

For nearly three years, this simple recipe sufficed.  I added lines for .jar and .tar.xz files, and wrapped the logic in a loop over each parameter, but that was it.  I intended to write bash completion for it, and perhaps honor a -q flag to decrease the verbosity, but it worked well enough.

Recently, however, I discovered dtrx, and it’s even better.  It handles even more compression types, it ensures that everything extracts to a single directory, it has a parameter to list the archive contents instead of extracting them, and it’s easier to type.  Most surprisingly, it handles the kind of .zip files that 7-zip creates, with a compression method that the standard unzip command can’t extract.  It requires Python, but that was barely an inconvenience even in a new Linux From Scratch environment.

It could still use a better bash completion method, though.  Maybe I’ll get around to that sometime.

Written by eswald

22 Jan 2013 at 7:00 pm

Posted in Linux, Python, Technology

Glacial Swiftness

leave a comment »

I spend most of my time on one of two speeds: lazy or thorough.  My co-workers frequently compliment me on how fast I get things done.  Reconciling these facts takes a bit of mental gymnastics.

When I’m assigned a task, I usually figure out how to do it with the least amount of tedious busy-work on my part.  That can involve writing a program to do the busy-work for me; it may use less of my time, and will often be more accurate.  As an example, I once had a co-worker who was assigned to port a set of quizzes from MS Access to MySQL.  There were tricks involved, of course; the MySQL schema had separate tables for courses, activities, questions, and answers, where the Access database had a separate table for each course, with each question’s answers lumped into a single field.  He convinced Access to export the tables as CSV files, and wrote a PHP script to import each row into MySQL, but had trouble convincing PHP to parse the rows.  Question text frequently had quotation marks and commas, and the answer field separated answers by newlines.  He spent two weeks manually unquoting fields, replacing field separators with pipe characters, removing newlines, and placing carriage returns between rows.  (No, he didn’t use a Mac.  I’m still uncertain why he thought carriage returns were the Unix convention.)  When he left, I was asked to finish the job, and to clean up the incorrectly imported answers, so I wiped out his pipe/CR files, re-exported the Access tables, and read them with fgetcsv().  I hadn’t even been aware of the function, but it was in the top page of search results.  The entire process took less than a day.

More often, it’s the second speed that facilitates my laziness.  I have now been working on a single program for over six years, and have written, modified, or at least checked in about 85% of the code.  I’ve written all of the test cases.  I understand it thoroughly, from the interface to the database.  That makes me uniquely qualified to determine the easiest way to perform a given task.  Sometimes it’s a database query.  Sometimes it’s a code change.  Sometimes it’s handing a set of links and instructions to someone with more time for busywork.  Sometimes it’s just too complicated for the allotted budget.

That program isn’t the only thing I understand thoroughly, of course.  I enjoy figuring out the inner workings of complicated systems.  I once counted seventeen different levels to my understanding of computers, including software, hardware, and fundamental physics.  I’ve learned more games than most people are aware exist, and frequently win on my first time playing.  I’ve read about linguistics, traffic, geology, astronomy, and history simply because they were fascinating.  In fact, my laziness usually manifests itself in reading or learning something, quite possibly something tangentially related to whatever I’m supposed to be doing next.

The main areas I don’t yet understand are psychology and literature.  Those are the domain of my spouse, so I’m gradually picking up a few things; for example, I finally learned what my high school English teachers were trying to teach.  Perhaps that’s why I write: this blog was started as an attempt to communicate or at least understand my companion’s rants.  Granted, I haven’t followed through very well, probably because they’re not my own ideas; fortunately, it’s now possible to find some of them elsewhere.

In any case, that need for thoroughness might explain why I feel uncomfortable satisfying my weekly post obligation with something short.

Written by eswald

15 Jan 2013 at 6:18 pm

Breaking Spacing

leave a comment »

I’m not a typographer.  I barely notice Comic Sans, and my interaction with ligatures is mostly limited to decomposing them into their component letters.  I put two spaces between sentences simply because that’s how I was taught.  I’m aware of arguments for single-spacing sentences, but it still feels wrong to me.

HTML, as a subset of SGML, collapses all whitespace into a single space, so blogs like this need a bit of trickery to faithfully represent the spaces as I type them.  WordPress handles this by switching one space out of each pair to a non-breaking space, Unicode code point U+00A0.  Unfortunately, its current implementation changes the second space of each pair.  Most of the time, that works well, but when a paragraph just happens to be wide enough to create a line break between sentences, and those sentences are separated by a space/nbsp sequence, then the browser puts the non-breaking space at the beginning of the next line, shifting the first character of the new sentence just enough to notice.

Read the rest of this entry »

Written by eswald

8 Jan 2013 at 6:33 pm

Posted in Technology

Happy New Year!

leave a comment »

1 Sunday, 3 Monday, 46 Tuesday, 2 Wednesday, 1 SaturdayIn last year’s first post, I committed to post at least once per week, in terms compatible with a Beeminder graph that had stopped working.  Over that year, I published 53 posts, 46 of them on Tuesdays.

Technically, I maintained a rate of 7 days or less between posts, finishing at a rate of 6.865 days per post.  The saving grace here was Bouncing Back, which really should be considered an extension of the previous post.  Taking that out, my election day post could be considered late; I published it before going to bed on Tuesday night, but it was after midnight.  The longest time between posts was ten days, because my Cheese Soufflé post was three days early.

postrate-2012Overall, I feel like I fulfilled my commitment, but it was close enough that I still feel an obligation to renew it, in some fashion.  This time, Beeminder’s exponential pricing schedule sounds attractive.  First, though, I need to find my account password and wire a WordPress webhook to its API.  I’m also tempted to set up my own blog site, simply to fix a few annoyances; in particular, it would be nice to have better code listings, access to the Google graph API, and non-breaking spaces as the first of a pair instead of the last.

Meanwhile, I’ll keep publishing on Tuesdays, probably even more regularly now that I’ve started to schedule posts for later.  You didn’t think my last post was actually written on Christmas day, did you?

Written by eswald

1 Jan 2013 at 3:34 pm

Posted in Lifestyle