arch linux, gnome-3.20 and xf86-input-synaptics

I am running arch linux with gnome desktop on a Lenovo Thinpad X230. Some time ago gnome 3.20 was released and apparently the synaptics driver is not supported any more.

The only reason I ran into this was because “tap to click” was turned on all of sudden and it interfered with my typing.

Initially, I heeded the advice on the synaptics wiki page: “Synaptics is no longer supported under GNOME. Migrate to libinput.” but the libinput driver was intolerably slow on my system even though I cranked the touchpad speed up to the max.

Anyway, I went back to the synaptics driver and disabled the irritating “tap to click” behaviour by setting the following values in /usr/share/X11/xorg.conf.d/50-synaptics.conf:

Section "InputClass"
Identifier "touchpad catchall"
Driver "synaptics"
MatchIsTouchpad "on"
Option "TapButton1" "0"
Option "TapButton2" "0"
Option "TapButton3" "0"

I hope this helps πŸ™‚

Software Engineer in Test (local or remote)

Monetas is looking for experienced software engineers to join the Q/A team. Responsibilities:

  • Build advanced automated test suites to exercise our digital finance platform
  • Work with the development teams to automate testing.
  • Analyze and decompose a complicated software system and design a strategy to test this system.

Desired Skills and Experience

  • BS in Computer Science or related technical field or equivalent practical experience.
  • Extensive knowledge of UNIX/Linux environments.
  • Excellent coding skills in Python (skills in C++ or Go are a bonus)
  • experience with automation in a cloud computing setting

If successful, you will be testing the software in the Open Transactions [1] and voting pools [2,3] eco-system.

NB: we are a distributed organisation and applications by remote candidates are welcome. We do not sponsor relocations to Switzerland at this time however.


To apply please send your CV to: careers AT monetas DOT net.

Looking for a senior test engineer

I am currently looking for a senior test engineer (in Zug or remotely) who is expected to lay the Q/A groundwork and establish automated software testing in our organisation.

Monetas is one of the hottest startup companies in the decentralised/crypto finance space. For more information about us please see a

To apply please send your CV to the following email: careers AT monetas DOT net. Thank you!

Looking for a seasoned computer security pro

Monetas is looking for an experienced computer security professional to

  • help secure our IT infrastructure
  • review and secure the tools and processes we use
  • provide security guidance and education to our product development team

This is a criticaly important position and hence can not be filled remotely. We are based in Zug, Switzerland and applicants need to be willing to operate from there.

Monetas is one of the hottest startup companies in the decentralised/crypto finance space. For more information about us please see a

To apply please send your CV to the following email: careers AT monetas DOT net. Thank you!

Exciting times ahead!

If you followed my tweets in the last couple of weeks you may have noticed a new interest of mine: crypto finance.

Decentralised/crypto finance facilitates fast, global and secure transactions without hold-ups at national boundaries and the need to trust third parties, governments or central banks.

This is powerful and bound to bring about change on the same scale as the internet IMHO.

I hence consider myself lucky to join the party as a director of engineering for Monetas, one of the hottest startup companies in the decentralised/crypto finance space.

Based on the open source project started by Chris Odom Monetas is building a universal transaction platform that facilitates the trading of all kinds of commodities including bitcoin or any other crypto currencies.

If you’d like to learn more, see this short video on our vision or a more detailed/longer video on the problems Monetas is looking to solve and the benefits of the Open Transactions platform.

P.S.: you have strong C++ development or testing and Q/A chops and wanna change the world with us? Please send your CV to careers at monetas dot net.

Shifting gears

After almost 2 years with the OpenQuake project I will be joining Rackspace as a technical cloud advocate on 01-Nov-2012.

This is novel and exciting in many ways as I will have the opportunity to pursue long standing interests and passions (cloud computing, scalable and robust IT architectures, open source, strategic thinking, reaching out to technical audiences etc.) as part of my *day* job.

I am looking forward to working with the good folks at Rackspace, the cloud community at large and anybody interested in putting cloud technology to good use!

See you around!

First experiments with golang

I finally found some time to look at the Go programming language (aka golang). In order to get a feeling for it I picked a random Google code jam problem and programmed it in Go.

The code used in the experiments that follow is pretty simple

first impressions

My first impressions were mostly positive: Go has

  • decent documentation covering the language proper as well as the standard library
  • a fast compiler resulting in short edit-compile-test cycles
  • a nice standard library and a wealth of packages (provided by the community)
  • a lively and friendly mailing list and irc channel

The language has quite a “direct” feel to it: I could get to work and be productive almost immediately.
This is in stark contrast to other languages I tried to learn recently e.g. Scala (back in January): it required a lot of reading and even a couple of days into it I was not really productive in Scala.

Go is quite the opposite, the barrier to entry is low, the language is clean and simple. The combined declaration and initialisation operator (':=') alone is a godsend.

Coming from a Python background the main thing I was missing was the REPL. Who knows, maybe there is even one out there but I just did not find it yet..?

playing with goroutines

One of the most attractive golang features is its support for concurrent programming via goroutines and I wanted to play with these.

The programming problem chosen came with an input for 50 calculations. I used it to create inputs with 50, 100 and 200 *thousand* calculations. All calculations are independent of each other i.e. ideally parallelisable.

Being a fairly young language still Go does not parallelise code by default. If CPU parallelism is desired one must tell the run-time how many goroutines shall execute simultaneously.

The code I wrote starts each calculation in a separate goroutine and allows the user to specify the number of CPUs/cores that should be used to execute the program.

Using a bash script I ran the resulting program varying both the number of calculations and the number of CPU cores.

These experiments were conducted on a 32-core server (Quad-Core AMD Opteron Processor 8356) with 64GB of RAM running Ubuntu 11.04 server. Also, I ran each configuration for three consecutive times and used the average duration in the graph below.

Apparently the golang run-time was not able to utilise more than 8 cores when running this particular program.

50, 100 and 200 thousand calculations running on 1 through 16 CPU cores

As can be seen from the graph (full size) above, executing the program on more than 8 cores did not decrease its running time futher.

The 200K calculations input file is a bit over half a gigabyte so I suspected that the program is dominated by I/O and the goroutines cannote execute because the result channel is full.

That lead me to experiment with different result channel sizes. The resulting running times (e.g. for 200K calculations) can be seen in the graph (full size) below.

The 200K calculations running on 1 through 16 CPU cores and with varying result channel sizes

However, varying the result channel sizes did not seem to have a big effect.

Anyway, I am pretty happy with the code at this point but suggestions are always welcome, particularly those aiming at improving the degree of parallelism πŸ™‚


I am amazed how far I got by investing approx. 10 hours in learning Go and programming in it.

Having used python almost exclusively for the last 5 years I am pretty spoiled when it comes to code conciseness and productivity.
Go is not too far away though, and, programming in it was fun and enjoyable.

I will definitely continue to explore it. Maybe you should give it a whirl as well πŸ™‚

EuroPython talk info

The slides from the EuroPython talk (python & amqp) I held this morning are here. I’ll post a link to the video when it becomes available.

There are two things I wanted to mention but did not get to:

  1. python-celery: if you are looking to partition and distribute computations do take a look at it. We are using it in the OpenQuake project and are very happy with it.
  2. RabbitMQ in Action: in case you are using RabbitMQ or plan to do so get this book. I started reading it recently and derived a lot of value from it.

How to dual-boot a stable/experimental system with minimal breakage

For a couple of years now I have been using a scheme that allows me to dual-boot a stable system (for work) and an experimental system (for fun) with minimal breakage.
Recent reports of people who upgraded their linux machines and ended up with a broken system prompted me to share it.

The idea is to divide your hard disk into at least 7 partitions

    root/usr system 1            12GB
    root/usr system 2            12GB
    /var partition system 1       6GB
    /var partition system 2       6GB
    shared /tmp partition         4GB
    shared swap partition         2GB
    shared home partition       100GB

Just in case you are wondering about the small partition sizes: I am using a 160 GB SSD. It was the best hardware investment in a long time and really makes a difference.
If you are using e.g. a 320/500GB hard disk feel free to double the partition sizes (and/or triple the size of the home partition).

When installing a new linux now only two partitions dedicated to that particular installation are needed:

  • a root/usr partition
  • a /var partition

All the others (/tmp, swap, and /home) are shared. This works particularly well when the two installed systems are reasonably similar (e.g. Ubuntu 10.10 and 11.04). What you can do with the set-up described above is a full/proper installation of the desired system as opposed to an upgrade.

Please note that backing up data you cannot afford to lose is a standard procedure before you tinker with your system (e.g. prior to OS installations and/or upgrades).

Sometimes the experimental system is so unstable that I use another technique: a chroot/schroot combination.

There was e.g. a period during which an installed Ubuntu 11.04 was “unusable” (for me) but I needed to run it for a number of reasons.
I resorted to running Ubuntu 10.10 as my main work system and having an 11.04 chroot. Entering the latter via the schroot utility made for a fairly seamless experience.

I hope this helps πŸ™‚

SSDs are the way to go!

I bought an intel X25-M SSD last week and it does make a *big* difference! It is faster, develops less noise and heat and the battery lasts longer.

I am using it with a lenovo thinkpad t410 laptop running Ubuntu 10.10 and it’s just great!

For what it’s worth I am running a pretty recent kernel in conjunction with the Ubuntu maverick userland. Not sure how well the normal 2.6.35 kernel supports SSDs.

Anyway, SSDs are the way to go πŸ™‚