In my previous blog post I explained the concept of delegated voting and how to make it work together with cryptographically secure e-voting algorithms. In this post I want to describe actual data flows of Liquid Feedback, and how a secure e-voting system like Solon could be hooked into it. For those of you potentially interested in contributing to Solon, I hope this gives a high level idea of the design.
Everything explained here already exists. The
liquid_feedback_patch/ creates these hooks into Liquid Feedback Core and alters the calculation procedure so that it counts the externally provided results. The 0.1 version of Solon is able to support this data flow and gives you a simple UI to cast votes via Solon. The small detail missing is the actual "secure" part, the current version is just a mockup demonstrating the idea. After this post I intend to write more about the Acquisti e-voting algorithm that I intend to implement as part of Solon.
How delegated voting works in Liquid Feedback
To create a cryptographic algorithm for Liquid Feedback, we must start with understanding how the current (plaintext) voting works in Liquid Feedback. The concept is known as delegated voting.
Those who know me know how excited I am about open source as a phenomenon. I contribute to open source projects myself, but I'm just as excited about non-software incarnations about the same phenomenon. Wikipedia, Project Gutenberg or Open Clipart are obvious projects to mention. "Life in a day is an awesome movie that was mass-produced by thousands of Youtube users all around the world - things like this are only possible through the open source method. It's a bit embarrassing but I even get excited about viral videos and flashmobs.
One area that has not been discussed a lot - nor has there been much to discuss - is government. What would it mean to open source government? Yes, I'm aware of the so called Open Government and Open Data movements. This is mostly about publishing government owned data for public analysis. Social networking has also brought politicians closer to their constituents and thanks to this politicians seem to be more likely to be affected by public opinion (or outrage, as it sometimes happens) than before. All of this is great, and more transparency usually does good for the democratic process. But ultimately I don't see it as a revolutionary new way of government: the same old politicians from the same old parties remain in power while you play with their data.
Attached are the slides for my MySQL Connect talk Evaluating MySQL High-availability alternatives, which I will present today at 14:30 at the MySQL Connect conference.
A bit unusually I'm posting the material ahead of the talk. The point of the talk is about evaluating each alternative from your own perspective. With that in mind, if you're at the talk with your own laptop, feel free to browse the slides at your own pace from here.
Simon Phipps, who's Computer World UK blog isn't aggregated on Planet MySQL, has a blog post which reveals the truth behind the missing MySQL test cases that many of us commented on some time ago (including myself). You can read Simon's blog post here.
As you remember, there were various things that happened (or rather ceased to happen) during the Summer which led to people complaining that Oracle's MySQL is closing down. As a result of the uproar, source code trees at Launchpad were immediately refreshed. Otoh, there was never any public explanation why test cases for new bug fixes are withheld.
In the Matrix movie there is a scene where the heroes visit a spiritual councelor, and amongst the people in her waiting room they see a little boy, dressed like a buddhist monk, who can bend a spoon just by looking at it. When they ask him what he does to bend the spoon, the boy's answer is: "There is no spoon". And if you watch the movie to the end, you will see that he is right. (In that spirit, if this post is too long to read for you, just skip to the last paragraph for the answer.)
The title for this blog post is of course inspired by Baron's "Is automated failover the root of all evil?", which is a commentary on GitHub's detailed explanation of their recent Pacemaker-induced downtime. Baron makes a good question, but the answer is deeper than suggested by the question. The problem is not the automation, the problem is the failover.
Last week both Sheeri and Mark Callaghan pointed my attention to the fact that if they comment on articles on this blog, they end up getting lot of email spam that is sent via OpenLife.cc. Thank you for informing me, I was completely unaware that this was still happening. The problem should now be fixed - you should not get any more spam mail, whether related to your old comments on this site or any new ones I hope you will still make.
When spam bots figured out how to spam Drupal based blogs - including working around the Captcha - I enabled the Drupal Antispam module which uses the Akismet service to check all incoming comments for spam. It has worked very well. On average AntiSpam blocks 40 spam comments a day, and the accuracy is very good (see stats below).
With MySQL it was for a long time the case that a lot of sub queries would actually perform poorly, because of poor execution plans. (This is no longer the case in MariaDB 5.5 or the upcoming MySQL 5.6.) Because of this, any MySQL DBA knows the rule of thumb that sub-queries should basically be avoided and you can usually get the same result by using JOINs instead.
I've now learned why PostgreSQL DBAs like sub queries so much. PostgreSQL - being the most advanced open source database - apparently does the exact opposite optimizations as MySQL: it requires you to rewrite simple queries into complex subqueries to get what you want. (Update: Mark Callaghan points out that MySQL - while it does create indexes automatically for foreign keys - actually has the same problems with the query plan as Postgres has in this post. See comments for details.)