To continue in photography blog posts, let's document part of our last week trip around Slovakia. We've visited many nice places, starting at Mura sk planina, going trhough Slovensk r j and ending in Nizke Tatry. All pictures are taken in Slovensk r j (Slovakian paradise), where I've really enjoyed taking photos of waterfalls and wonderful streams:

Filed under: English Photography Travelling 2 comments Flattr this!

I am trying to get used to fish as a default shell. I like some things in it, but can not quite get used to other things, so I wonder maybe I am cooking it wrong? So here are things that I could not find a solution for, while switching from bash.

• bash$ DISPLAY=:1 gedit very simple thing, how do I set and environment variable for just one command execution in the most simple possible way.
• bash$ scp hostname:somedir/*.jpg . when I try to run this in fish, for some reason I get fish: Warning: No match for wildcard hostname:somedir/*.jpg . The command will not be executed. and I could not figure out how to actually run the command in a quick Googling.
• I have (almost) come to terms that while and for syntax is different, but I still wonder maybe there is some bash compatibility mode that I missed that would allow me to use my old ways?

I do like the colors, the shortened cwd in the prompt, the univeral history and univeral variables, lower memory usage and funkier completions. Any other fish features people like? Especially I am interested in features that are not enabled by default.

Two years ago, Jacob (then 3) and I built his first computer together. I installed Debian on it, but never put a GUI on the thing. It s command-line, and has provided lots of enjoyment off and on over the last couple of years. I ve written extensively about what our boys like to do, and the delight they have at learning things on the command line. The looks of shock I get from people when I explain, as if it s perfectly natural, that my child has been able to log in by himself to a Linux shell since age 3, are amusing and astounding. Especially considering that it is really not that hard. Instead of learning how to run an Xbox, he s learned how to run bash. I like that. Lately, Jacob (now 5) hasn t been spending much time with it. He isn t really at a stage where he wants to push his limits too far, I think, but yet also gets bored with the familiar. So I thought it was time to introduce a GUI in a limited fashion, perhaps to let him download photos and video from his Vtech toy camera (that takes real low-res photos and videos which can be downloaded over a USB1 link). He s familiar with the concept, at least somewhat, having seen GUIs on Terah s computer (Gnome 2) and mine (xfce4 + xmonad). So last night, Oliver (age 2) and I went down to the basement on a mouse-finding expedition. Sure enough, I had an old PS/2 mouse down there that would work fine. The boys both helped string it through the desk up on our play room, and were tremendously excited to see the red light underneath it when the computer came on. Barely able to contain the excitement, really. A bit like I remember being when I got my first mouse (at a bit of an older age, I suppose.) I helped him them in as root for the very first time. (Jacob typed root , and I typed the password, and provided the explanation for why we were telling the computer we were root .) Jacob and Oliver alternated typing bits of some apt-get command lines. Then while we waited for software to download, I had to answer repeated questions of how soon will the mouse work? and what does install mean? Finally it was there, and I told Jacob to type startx. I intentionally did not install a display manager; more on that later. He pressed Enter, the screen went blank for about 5 seconds, and then X appeared. Excited can t begin to describe how they acted. They took turns playing with the mouse. They loved how the trash can icon (I started with XFCE) showed trash IN the trash can. But they are just learning the mouse, and there s a lot about a typical GUI that is unfriendly to someone that isn t yet proficient with a mouse. The close buttons are disappointingly small, things can be too easily dragged on and off the panel and menus. When I sat down to think about it, the typical GUI design does not present a very good it always works the same interface that would be good for a child. And then it occurred to me: the perfect GUI for a child would be simply xmonad (a tiling window manager that can be controlled almost entirely by keyboard and has no need for mouse movements in most cases.) No desktop environment, no file manager in the root window. Just a window manager in the classic X way. Of course! So after the boys were in bed, I installed xmonad. I gave Jacob s account a simple .xsession that starts a terminal and xmonad. Today, Jacob informed me that he wanted his computer to look just like yours. Playing right into my hands, that was! But when he excitedly typed startx, he said it wasn t just like mine. Uh oh. Turns out he wanted the same wallpaper as my computer uses. Whew. We found it, I figured out that xli(1) loads it in the root window, and so I added a third line to .xsession. More delight unlocked! Jacob mastered the basics of xmonad really quickly. Alt-Shift-C to close a window. Alt-Shift-Q to quit back to the big black screen . Alt-Shift-Enter to get a terminal window. We launched thunar (the XFCE file manager) and plugged in his camera. He had a good deal of fun looking at photos and videos from it. But then I dropped the true highlight of the day for him: I offered to install Tuxpaint for him. That s probably his favorite program of all time. He watched impatiently as apt-get counted down 1m30s for tuxpaint and its libraries. Then we launched it, and he wanted to skip supper so he could keep playing Tuxpaint on my VERY OWN COMPUTER! I d been debating how to introduce GUIs for a very long time. It has not escaped my attention that children that used Commodores or TRS-80s or DOS knew a lot more about how their computers worked, on average, than those of the same age that use Windows or MacOS. I didn t want our boys to skip an entire phase of learning how their technology works. I am pleased with this solution; they still run commands to launch things, yet get to play with more than text-based programs. At bedtime, Jacob asked me, very seriously: Dad, how do I start tuxpaint again? First you log in and type startx. Then you can use the mouse. Jacob nods, a contemplative look on his face.. Then, I continue, you type tuxpaint in the terminal, and it comes right up. Jacob nodded very seriously a second time, as if committing this very important information to long-term memory. Then gave a single excited clap, yelled Great! , and dashed off.

2000, Bordeaux, France. 2001, Bordeaux, France. 2002, Ottawa, Canada. 2003, Oslo, Norway. 2004, Porto Alegre, Brazil. 2005, Helsinki, Finland. 2006, Oaxtepec, Mexico. 2007, Edinburgh, United Kingdom. 2008, Mar del Plata, Argentina. 2009, C ceres, Spain. 2010, New York, United States. 2011, Banja Luka, Bosnia and Herzegovina. 2012, Managua, Nicaragua. 2013, Vaumarcus, Switzerland. We have gone to all different latitudes (although not yet longitudes!). We have had very hot and very cold weather. Great cities and small villages have hosted us. What will be the next addition to this great list? As we approach DebConf12 (10 days to DebCamp and counting, yay!), we should keep the future in mind. So, as every year in recent history, we will once again have a DebConf session presenting possible venues for the next year. Organizing DebConf in your city means a lot of hard work. It also means one of the greatest personal experiences you can imagine. And it is a great way to contribute to Debian. The decision process for every DebConf venue starts two years before, with presentations during DebConf(n-2). That means, if you consider presenting a bid for DebConf14, now is the moment to act! Do you have to be present at Managua to propose your bid? No. You can proxy via somebody I d suggest to do it via somebody who knows the location you are suggesting, but basically, choose a friend that you trust that trusts you. Of course, you can participate in the presentation session via IRC. Do you have to be a Debian Developer to propose a bid? No. For DebConf9, none of the C ceres guys was a DD; for DebConf10, some of the people most involved from the local New Yorkers were not DDs. For DC11, none of our hosts in Bosnia are DDs. And for DC12, the dear and overworked Nicaraguan crew is also made from people interested in getting closer to the Debian project, but not DDs. Do you have to decide now? No. This is just a call for a first presentation, but the decision regarding DC14 will be taken probably around March 2013. However, giving a nice presentation at DebConf helps a lot, gives you visibility, and will get the ball rolling. Is there a geographical bias? Slight. So far, and since the second DebConf, we have kept the tradition not to repeat continents on two successive DebConfs. This is not a hard condition, however! While there is some probability that DebConf14 will be somewhere in America (the continent, of course), it depends on the proposals more than on any pseudo-rule. What do you need to start thinking about? Go visit our prospective location checklist. You can also look at what other teams have historically presented. And of course, go to the DebConf14 wiki planning page Register there, even if you are just in the early phases of finding data.

Sarah and I are running in the 5K Packard Summer Scamper on Saturday. Sarah's been working on her fitness for a few months now, and I belatedly started working on mine about a 6 weeks ago. (Sarah's fund raising, so if you'd like to sponsor her, her page is here) I've been using the Couch to 5K program to get my fitness up, but I haven't managed to stick to it exactly, due to a combination of injury and wet weather. I have still managed to get myself to the point where I can run for 28 minutes solidly, which is close to 5K (I'm doing my last training run tomorrow, so I'll see what the distance comes out to). I've been doing up to three runs a week at lunchtime around the Shoreline Amphitheatre area, using my Galaxy Nexus and some Bluetooth headphones, and I've got a pretty nice little setup. I'm using Pandora for some music to listen to, C25K Pro for the actual running intervals. It has voice prompts that tell me when to run, or to start a walk interval. Finally, I'm using Strava Run for recording the run and getting some additional statistics during the run (kilometre markers, split times and time elapsed). These also come through as voice prompts. I'm not currently wearing a watch, and I want to keep track of the wall time, so I've also found Audio Clock, which verbally announces the time (I've set it to do it every 15 minutes that a Bluetooth headset is connected). What I really like about all of this is that I get spoken voice prompts and information, seamlessly mixed in with the music from Pandora, all while I'm running. I've got my phone strapped to my arm, and I don't have to look at it during the run, and there's no wires. I'm a huge personal metrics junkie, and that was why I previously eschewed running outdoors. I wanted that information on the treadmill display so I could push myself that little bit further. Sure, I'm not getting the constant information as much as if I had a treadmill display in front of me the whole time, but I'll settle for running in the great outdoors and getting some feedback every kilometre (if I get really desperate, Strava will do it every half kilometre). Not to diss optical augmented reality efforts too much, but I'd rather go for a combination of discreet audio announcements through a Bluetooth earpiece, perhaps complemented with something I choose to look at like a Pebble watch, than an in-your-face pair of glasses. My Bluetooth headphones are the around the back of the head variety that aren't going to bounce off during a run. I've really enjoyed doing the runs during the week, and when I was doing the full 3 runs a week of a given week of the Couch to 5K program, I'd really notice a difference by run number 3. I'm currently planning on sticking with doing a 5K run hopefully at least twice a week after this weekend. It's certainly done wonders for my waistline.

Gnarf. Someone happen to need a new Sysadmin - working from home?

Finally I've found time to look back at vacation in Rome and post some pictures. It has been great time there and I've really enjoyed that. I would like to thank to Luigi Gangitano for showing us some interesting places in the city. And now back to pictures:

Filed under: English Photography Travelling 0 comments Flattr this!

I've recently book my places at a few conferences, so just to confirm: I hope to see a few people there!

Thanks to Google, for some years now there has been the so-called Google Summer of Code programme. Quite an interesting project it is.

However, how many of the slots assigned to Debian have resulted in successful projects? how many of them were actually completed by the student and not by the mentor or somebody else? are those projects in fact used or useful at all?

All these questions occurred to me while wondering what would have happened if Joey Hess' git-annex-related kickstarter project had instead been a GSOC project. His kickstart was very successful by the way. Joey: many congratulations!

Not trying to point my finger to the (IMHO many) failed or unsuccessful Debian-related gsoc projects, but I wonder how many successful projects are developed outside the get-paid-in-exchange model. I suspect most, at least in Debian.

What's done for those who actually "deliver" while working on projects as a hobby? is it really worth having GSOC slots for Debian?

After upgrading a mail server to Debian/Unstable (which will soon be released as Wheezy) I started getting SASL errors. 535 5.7.8 Error: authentication failed: no mechanism available The SMTP protocol gave the above error for both LOGIN and PLAIN methods. SASL LOGIN authentication failed: no mechanism available The postfix/smtpd process logged messages like the above in syslog. It turned out that the auxprop_plugin: mysql line had to be removed and replaced with the following two lines due to a change in the way SQL plugins are managed: auxprop_plugin: sql
sql_engine: mysql Also the SQL query needed to have %u replaced with %u@%r because we now have user and realm provided separately. Related posts:

1. MySQL security in Debian Currently there is a problem with the MySQL default install...
2. Kernel issues with Debian Xen and CentOS Kernels Last time I tried using a Debian 64bit Xen kernel...
3. new release of postal Today I have released a significant new version of my...

Upgrading the local version of subversion against a large subversion repository has so far taken three DAYS. It goes through this multi-gigabyte repository in no perceivable order, it goes through every single directory in every single tag and every single branch and refuses to run in any sub-directory. (Even after clearing out some older tags, the tags/ directory is still nearly 8Gb and that doesn't include any binary files.) Each tag within tags/ is 500Mb and contains nearly 6000 sub-directories. Yes, it's large but svn upgrade should still be able to handle it without crippling every machine.

I can't image how svn is going to manage when the server finally gets upgraded. Probably be quicker to dump the entire repo and reimport it.

When I finally give up the will to proceed or simply need to use this LAPTOP for something else, I have to interrupt it with Ctrl-C at which point is starts all over again!

This isn't a slow machine, it's a i5 quad-core T410 with 8Gb of RAM and 1Tb of storage - and svn has made it crawl for days. The only way to pair down the working copy is to delete every tag and branch which means losing data like old build logs and old packages. The repository is this large because it's tracking the development of multiple commercial products which share common code but which also have numerous releases and release updates.

I can't even use svn st on this repo without this completing - I haven't been able to work on this repo since this started. Absolutely insane.

Pondering filing an RC bug on the basis of unjustifiable data loss. We have many machines at work with this repository checked out and if we ever migrate to Wheezy, it's going to mean a WEEK of lost work!!

subversion                    1.7.5-1

So, a warning for anyone else using subversion 1.7.5 with a very large repository: DELETE ALL TAGS and BRANCHES and any other directory anywhere in every single working copy tree on every machine which ever wants to use that copy again before even thinking about upgrading to 1.7.5.

The tags directories don't even need to be upgraded because we only use those to rebuild the code as it was in chroots.

Unspeakably furious about such a completely dumb tool being thrown into the mix DAYS before the Wheezy freeze. Now I have to kill it AGAIN just so that I can suspend the laptop. IDIOTS.

More than once, I have found myself running a program that calls a given script multiple times, and sometimes, way too many times. In some cases, for instance, it was only necessary to run the script once in one minute, instead of hundreds of times.
Sounds like I want something like dpkg's deferred triggers, right? pretty much so.

With this need, deferred-run was born. Example:

$ deferred-run -l lock -- echo hello world
$ deferred-run -l lock -- echo hello world
$ sleep 3
$ deferred-run -l lock -- echo hello world
[some seconds later...]
hello world

In spite of multiple calls, echo was only called once.
Best part, it only requires sh and flock.

If you are interested in shell trickery, you should take a look at its code.

So status displays are cool. Seeing what is happening in real time is cool. As a proof of concept I put together a trivial load-graph:

• http://static.steve.org.uk/load/

This is broken down into three parts:

Load Client

The load client is a trivial script which reads /proc/loadavg, and sends the 1-minute entry to a remote server, via a single UDP packet.

Load Server

The load-server is a service which listens for UDP traffic, and when it receives a new integer records that in a redis data-store.

Load Display

This is a HTML page which has the values from the store in it, which is then plotted using javscript.

So the UDP-server which receives load will receive two things:

• load:N - The load figure. The text "load:" is literal, and present in case I decide to extend the stats..
• x.x.x.x - The IP address from which it received the message.

This is inserted into a Redis database as an array. This array could then be fetched via an AJAX script to update the HTML display in real-time, but at the moment I just have a shell script which updates it in near-real time. The idea of having a UDP-server receive values from remote clients is interesting. We just need to define a mapping to redis. For me I've just done this:

receive a UDP packet with value "load:1.2" from source 1.2.3.4
append "1.2" to key "1.2.3.4-load".
append the value "1.2.3.4" to the global "known_hosts"

The values received can be truncated (i.e. keep only the most recent 60 entries) with ease, due to the available Redis primitives, and we can easily graph these using the qjplot library. Adding more metrics just means updating the clients to send "memfree:400m", "disk-free:50%", "users:2", "uptime:12345s", or similar. The storage is wonderfully abstract - all you need to do is get the graph-drawing code to a) Know which source to display, and b) which metric. For example, if we did extend the client to send that data I could draw a graph of the memory on host foo.example.com just by selecting "memfree" against the origin "1.2.3.4". ObQuote: "Come here, damn you, I want to touch you. " - Hellraiser

Just a quick reminder: if you haven t reconfirmed in our beloved pentabarf system, that you ll be attending DebConf12 in Managua in just a bit more then 2 weeks, then do so now! The reconfirmation deadline is tomorrow!

Updated 22/06/2012: Reference to Canonical's response

A couple of people have asked me about the Ubuntu ODM UEFI requirements, specifically the secure boot section. This is aimed at hardware vendors who explicitly want to support Ubuntu, so it's not necessarily the approach Canonical will be taking for installing Ubuntu on average consumer hardware. But it's still worth looking at.

In a nutshell, the requirements for secure boot are:

• The system must have an Ubuntu key preinstalled in each of KEK and db
• It must be possible to disable secure boot
• It must be possible for the end user to reconfigure keys

It's basically the same set of requirements as Microsoft have, except with an Ubuntu key instead of a Microsoft one.

The significant difference between the Ubuntu approach and the Microsoft approach is that there's no indication that Canonical will be offering any kind of signing service. A system carrying only the Ubuntu signing key will conform to these requirements and may be certified by Canonical, but will not boot any OS other than Ubuntu unless the user disables secure boot or imports their own key database. That is, a certified Ubuntu system may be more locked down than a certified Windows 8 system.

(Practically speaking this probably isn't an issue for desktops, because you'll need to carry the Microsoft key in order to validate drivers on any PCI cards. But laptops are unlikely to run external option ROMs, so mobile hardware would be viable with only the Ubuntu key)

There's two obvious solutions for this:

1. Canonical could offer a signing service. Expensive and awkward, but obviously achievable. However, this isn't a great solution. The Authenticode format used for secure boot signing only permits a single signature. Anything signed with the Ubuntu key cannot also be signed with any other key. So if, say, Fedora wanted to install on these systems without disabling secure boot first, you'd need to have two sets of install media - one signed with the Ubuntu key for Ubuntu hardware, one signed with the Microsoft key for Windows hardware.
2. Require that ODMs include the Microsoft key as well as the Ubuntu key. This maintains compatibility with other operating systems.

This kind of problem is why we didn't argue for a Fedora-specific signing key. While it would have avoided a dependence on Microsoft, it would have created an entirely different kind of vendor lock-in.

Update: Canonical have now provided their full plans. They won't be providing a signing service, but will be requiring that all Ubuntu-certified hardware ship with the Microsoft key

comments

I have an interesting problem: How do I shoehorn "hired by The Internet for a full year to work on Free Software" into my resume? Yes, the git-annex Kickstarter went well. :) I had asked for enough to get by for three months. Multiple people thought I should instead work on it for a full year and really do the idea justice. Jason Scott was especially enthusiastic about this idea. So I added new goals and eventually it got there. Don Marti thinks the success of my Kickstarter validates crowdfunding for Free Software. Hard to say; this is not the first Free Software to be funded on Kickstarter. Remember Diaspora? Here's what I think worked to make this a success:

• I have a pretty good reach with this blog. I reached my original goal in the first 24 hours, and during that time, probably 75% of contributions were from people I know, people who use git-annex already, or people who probably read this blog. Oh, and these contributors were amazingly generous.
• I had a small, realistic, easily acheivable goal. This ensured my project was quickly visible in "successful projects" on Kickstarter, and stayed visible. If I had asked for a year up front, I might not have fared as well. It also led to my project being a "Staff Pick" for a week on Kickstarter, which exposed it to a much wider audience. In the end, nearly half my funding came from people who stumbled over the project on Kickstarter.
• The git-annex assistant is an easy idea to grasp, at varying levels of technical expertise. It can be explained by analogy to DropBox, or as something on top of git, or as an approach to avoid to cloud vendor lockin. Most of my previous work would be much harder to explain to a broad audience in a Kickstarter. But this still appeals to very technical audiences too. I hit a sweet spot here.
• I'm enhancing software I've already written. This made my Kickstarter a lot less vaporware than some other software projects on Kickstarter. I even had a branch in git where I'd made sure I could pull off the basic idea of tying git-annex and inotify together.
• I put in a lot of time on the Kickstarter side. My 3 minute video, amuaturish as it is, took 3 solid days work to put together. (And 14 thousand people watched it... eep!) I added new and better rewards, posted fairly frequent updates, answered numerous questions, etc.
• I managed to have at least some Kickstarter rewards that are connected to the project is relevant ways. This is a hard part of Kickstarter for Free Software; just giving backers a copy of the software is not an incentive for most of them. A credits file mention pulled in a massive 50% of all backers, but they were mostly causual backers. On the other end, 30% of funds came from USB keychains, which will be a high-quality reward and has a real use case with git-annex. The surprising, but gratifying part of the rewards was that 30% of funds came from rewards that were essentially "participate in this free software project" -- ie, "help set my goals" and "beta tester". It's cool to see people see real value in participating in Free Software.
• I was flexible when users asked for more. I only hope I can deliver on the Android port. Its gonna be a real challange. I even eventually agreed to spend a month trying to port it to Windows. (I refused to develop an IOS port even though it could have probably increased my funding; Steve's controlling ghost and I don't get along.)
• It seemed to help the slope of the graph when I started actually working on the project, while the Kickstarter was still ongoing. I'd reached my original goal, so why not?

I've already put two weeks work into developing the git-annex assistant. I'm blogging about my progress every day on its development blog. The first new feature, a git annex watch command that automatically commits changes to git, will be in the next release of git-annex. I can already tell this is going to be a year of hard work, difficult problems, and great results. Thank you for helping make it happen.

One alternative explanation that I have received for this, apart from working on unstable, is that... women are generally unstable :P

(This blog post is a more firm version of a series of tweets and forum posts I made a few weeks ago. This should also be considered a refresh of this post by Mirco Bauer a few years ago) It has been said that Mono is bloated, and that people should use lighter frameworks that don t pull in hundreds of meg . How much basis in reality is there for those comments? Well, let s do a little thought exercise. How much space is the minimum space needed for several languages to work? For this experiment, we will be looking at the required installation size on disk of several language frameworks, each time installing the bare minimum for a command-line hello world app in that language to run. For example, the Ruby result is the minimum install required to run:

puts 'Hello world'

and the Mono result is the minimum install required to run the following code, which has been compiled on a different machine using dmcs :

public class Hello1
 
   public static void Main()
    
      System.Console.WriteLine("Hello, World!");
    
 

Obviously, for dynamic languages like Ruby and Python, there is no compiler step needed. For languages like C# and Java, it is fair to compile these on a different machine as end-users of packages running these frameworks receive binaries, not source they do not need a development environment. So, on to the test environment. This is a bare bootstrapped AMD64 Debian Unstable system, as of today (i.e. debootstrap sid /tmp/badger ). Its install size is 275MB. So how much space? Ruby 1.9 Test code is as follows:

puts 'Hello world'

Install requirements are as follows:

root@dream:/# aptitude install ruby1.9.1
The following NEW packages will be installed:
  libffi5 a  libruby1.9.1 a  libyaml-0-2 a  ruby1.9.1 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 4703 kB of archives. After unpacking 13.1 MB will be used.

OpenJDK 7 Test code is as follows:

class HelloWorldApp  
    public static void main(String[] args)  
        System.out.println("Hello world");
     
 

Install requirements are as follows:

root@dream:/# aptitude install openjdk-7-jre-headless
The following NEW packages will be installed:
  ca-certificates a  ca-certificates-java a  dbus a  fontconfig-config a  
  icedtea-7-jre-cacao a  icedtea-7-jre-jamvm a  java-common a  
  krb5-locales a  libavahi-client3 a  libavahi-common-data a  
  libavahi-common3 a  libcap2 a  libcups2 a  libdbus-1-3 a  libexpat1 a  
  libffi5 a  libfontconfig1 a  libfreetype6 a  libglib2.0-0 a  
  libglib2.0-data a  libgssapi-krb5-2 a  libjpeg8 a  libk5crypto3 a  
  libkeyutils1 a  libkrb5-3 a  libkrb5support0 a  liblcms2-2 a  libnspr4 a  
  libnss3 libnss3-1d a  libpcre3 a  libpcsclite1 a  libsystemd-login0 a  
  libxml2 a  openjdk-7-jre-headless openjdk-7-jre-lib a  openssl a  
  sgml-base a  shared-mime-info a  ttf-dejavu-core a  tzdata-java a  ucf a  
  xml-core a  
0 packages upgraded, 43 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.5 MB of archives. After unpacking 137 MB will be used.

Python 3.2 Test code is as follows:

print ("Hello world")

Install requirements are as follows:

root@dream:/# aptitude install python3.2-minimal
The following NEW packages will be installed:
  file a  libexpat1 a  libffi5 a  libmagic1 a  mime-support a  python3.2 a  python3.2-minimal 
0 packages upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 4853 kB of archives. After unpacking 17.7 MB will be used.

Mono 2.10 (C#) Test code is as follows:

public class Hello
 
   public static void Main()
    
      System.Console.WriteLine("Hello world");
    
 

Install requirements are as follows:

root@dream:/# aptitude install mono-runtime
The following NEW packages will be installed:
  binfmt-support a  cli-common a  libmono-corlib4.0-cil a  libmono-i18n-west4.0-cil a  libmono-i18n4.0-cil a  
  libmono-security4.0-cil a  libmono-system-configuration4.0-cil a  libmono-system-security4.0-cil a  
  libmono-system-xml4.0-cil a  libmono-system4.0-cil a  mono-4.0-gac a  mono-gac a  mono-runtime 
0 packages upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 4383 kB of archives. After unpacking 11.5 MB will be used.

Of course, every time I try to make the argument that Mono is much leaner than what people propose as an alternative, the anti-Mono brigade go on the defensive and insist that nobody in their right minds uses Python or Ruby either everything ever should be written in Qt. So, hypothetically Qt 4.8 (C++) Test code is as follows:

#include <QTextStream>
int main(int argc, char **argv)
 
   QTextStream s(stdout);
   s << "Hello, world!\n";
   return 0;
 

Install requirements are as follows:

root@dream:/# aptitude install libqtcore4
The following NEW packages will be installed:
  libffi5 a  libglib2.0-0 a  libglib2.0-data a  libpcre3 a  libqtcore4 
  libxml2 a  sgml-base a  shared-mime-info a  xml-core a  
0 packages upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.3 MB of archives. After unpacking 27.8 MB will be used.

Presented without comment for your consideration. Edit: There are complaints that these numbers are misleading, because they show default package manager behaviour, rather than what happens when passing extra flags or config file settings to Apt. When disabling installation of Recommends: packages, the numbers change as follows:

• openjdk-7-jre-headless 137 MB -> 116 MB
• ruby1.9.1 13.1 MB -> 13.1 MB
• python3.2-minimal 17.7 MB -> 6.1 MB
• mono-runtime 11.5 MB -> 10.9 MB
• libqtcore4 27.8 MB -> 13.7 MB

A post by Gunnar reminded me that I wanted to blog about this: e-voting in Belgium is going to change slightly. Previously, e-voting worked with a computer with a lightpen on which you would enter your vote, a magnetic card that would contain your vote in encoded form, and a magnetic card reader that would count the votes. After more than a decade when I was first eligible to vote back in 1996, it had already been implemented in the city of Antwerp, where my vote would be cast, so I've never voted on paper it had still not been rolled out everywhere, and some of the computers used for the voting were now starting to show their age. A few days ago on the news, they reported that the e-voting system was to change so that rather than magnetic cards, it would use pieces of paper. This way, voters would be able to check that the information on the piece of paper conforms with their vote. Investigating what this means, I found this website by the federal government, where they have some pictures of a test run of the new system which they ran in October last year. Rather than using magnetic cards, the new system uses paper slips with the voted information in two forms: once as a (huge) QR code, and once as a human-readable text. In theory, this is a more transparent system than using a magnetic card, and that's a good thing; additionally, it allows for a traditional recount (by people, not computers) should the need ever arise. However, I do still see some problems:

• The website says you need to first fold the slip, and then unfold it when you get at the scanner so you can scan your barcode. This risks violating the secrecy of the vote, as people will be able to glance what other people have voted as they unfold the slip. I'm not sure how this can be fixed.
• If the vote is printed on the paper slip in two forms, you need to be able to guarantee in some way that the two forms are the exact same information. People with smartphones can scan the QR code and compare it to the human-readable code, but not everyone has one of those.

Having said that, I do think the new system is an improvement over the old (in fact, it's exactly the kind of system I had thought about myself earlier when thinking about ways to improve e-voting); and if the two problems are solved in some way (it's not impossible to do that, just requires some clever thinking), I believe it has potential as a way to implement electronic voting in a good way.

I will sound monothematic, but I have been devoting quite a bit of work to this topic lately: Trying to stop the advance of e-voting in Mexico, Latin America and the world. Why trying to stop it? Isn't technology supposed to help us, to get trustable processes? Yes, it's supposed to... but it just cannot achieve it, no matter how hard it is tried I won't get into explanations in this blog post, but there is plenty of information. Feel free to ask me for further details. Anyway Yesterday (Sunday, 2012-06-17) was the fifth simulated voting that will lead to the first wide-scale deployment of electronic voting booths in my country: About 10% of the population of the state of Jalisco (that means, ~500,000 people) will cast their votes on July 1st electronically. This particular case illustrates how simulated votings can be used to forge a lie: Pounce Consulting, the company that won the e-voting project for IEPC (Jalisco's voting authority), delivered their booths over 40 days late, just before the deadline for the project to be canceled. Oh, and by the way, it's the same company that just failed to deliver on time for another planned local authority (10% of the booths in the Federal District, where I live, where fortunately 100% of the votes will be cast on traditional, auditable and cheap paper). After this delay, five voting simulations were programmed, to get the local population acquinted with them. The first ones just failed to get the population's interest and had close to 40% failure rates (mainly regarding transmission). Several other "minor details" were reported, including mechanical details that allowed subsequent voters to see the vote of who had just left. Anyway, making long story short: The fifth and last simulation was held yesterday. Officially, it was finally successful (about time). As these booths include the "facilities" to communicate the results via the cellular network, but the populations where they are to be deployed do not yet have cellular coverage, 10% of the booths will have to be carried back to the Districtal Header (that can be a ~10hr trip) to be counted. Also, in all places, traditional paper stationery and paraphernalia will be printed just in case it is needed (and when will they now? When half of the votes are cast and lost?) Anyway... e-voting is still in its first stage in Mexico. Right now, I'm sure, no attempts to rig the election will be made (centrally). But every effort will be made (as it has been made) to dismiss the obviously big and nontrivial ways it has failed and will fail, and any problems will be labeled as "minor". And probably by 2018 we will be facing many more states (even nationwide) deployments. But propaganda fails to see the obvious: E-voting is more expensive, more complicated, leads to more possible failure states. E-voting should not be deployed in large-scale (i.e. more than a couple of hundred voters) elections. Electronic voting is insecure, violates secrecy, allows for fraud. No matter how many locks are put into it.