Currently showing posts in category: hidden

Email inboxes and the GTD 2-minute rule

By , March 20, 2014 12:46 am

Today’s dose of structured procrastination resulted in something I’ve been meaning to build for quite a while: a timer to help apply the two minute rule from David Allen’s famous GTD (Getting Things Done) system to the processing of a maildir-format email inbox.

Briefly, the idea is that when processing your inbox, for each email you have a maximum of two minutes to either:

  • perform any actions required by that email, or
  • add any such actions to your TODO list, and move the email out of the inbox. (IMHO, best practice is to move it to an archive folder and have a system for rapid retrieval of the email via the TODO list item, e.g. via a hyperlink which will retrieve the email based on its Message-Id: header, using an indexing mail search engine.)

However, I find that I frequently exhibit the bad habit of fidgeting with my inbox – in other words, checking it frequently to satisfy my curiosity about what new mail is there, without actually taking any useful action according to the processing (a.k.a. clarification) step. This isn’t just a waste of time; it also increases my stress levels by making me aware of things I need to do whilst miserably failing to help get them done.

Another bad habit I have is mixing up the processing/clarification phase with the organizing and doing phases – in other words, I look at an email in my inbox, realise that it requires me to perform some actions, and then I immediately launch right into the actions without any thought as to how urgent they are or how long they will take. This is another great way of increasing stress levels when they are not urgent and could take a long time, because at least subconsciously I’m usually aware that this is just another form of procrastination.

So today I wrote this simple Ruby timer program which constantly monitors the number of emails in the given maildir-formatted folder, and shows you how much of the two minutes you have left to process the item you are currently looking at. Here’s a snippet of the output:

1:23    24 mails
1:22    24 mails
1:21    24 mails
1:20    24 mails
Processed 1 mail in 41s!
Average velocity now 57s per mail
At this rate you will hit your target of 0 mails in 21m 55s, at 2014-03-19 23:18:59 +0000
2:00    23 mails
1:59    23 mails
1:58    23 mails
1:57    23 mails

You can see that each time you process mail and remove it from the email folder, it resets the counter back to two minutes. If you exceed the two minute budget, it will start beeping annoyingly, to prod you back into adherence to the rule.

So for example if you have 30 mails in your inbox, using this timer it should take you an absolute maximum of one hour to process them all (“process” in the sense defined within David Allen’s GTD system, not to complete all associated tasks).

Since gamification seems to be the new hip buzzword on the block, I should mention I’m already enjoying the fact that this turns the mundane chore of churning through an inbox into something of a fun game – seeing how quickly I can get through everything. And I already have an item on the TODO list for collecting statistics about each “run”, so that I can see stuff like:

  • on avarege how many emails I process daily
  • how often I process email
  • on average how many emails I process during each “sitting”
  • how much time I spend processing email
  • whether I’m getting faster over time

I also really like being able to see an estimate of the remaining time – I expect this will really help me decide whether I should be processing or doing. E.g. if I have deadlines looming and I know it’s going to take two hours to process my inbox, I’m more likely to consciously decide to ignore it until the work for my deadline is complete.

Other TODO items include improving the interface to give a nice big timer and/or progress bar, and the option of a GTK interface or similar. Pull requests are of course very welcome ;-)

For mutt users, this approach can work nicely in conjunction with a trick which helps focus on a single mail thread at a time.

Hope that was useful or at least interesting. If you end up using this hack, I’d love to hear about it!


7 principles for contributing patches to software projects

By , November 10, 2012 3:28 pm

In the Free and Open Source software worlds, it seems that a lot of people with good intentions don’t understand how to contribute efficiently and effectively to upstream software projects. I say this based on personal experience: I sometimes receive patches to projects I maintain, where despite good intentions and a perfectly valid goal (e.g. a bug-fix or feature implementation), the patches are fundamentally flawed in a variety of ways. So unfortunately I cannot accept them without negatively impacting the quality or maintainability of the project.  And I don’t even maintain any wildly popular projects.

It is possible to spend a lot of money on training to learn how to avoid these mistakes, and also many well-organized projects already provide good documentation on how to contribute, such as the Linux kernel and git. However, these documents typically mix up generic advice with project-specific advice. In this post I would like to present a list of generic advice on how to write patches which have the maximum chance of being accepted quickly and with gratitude rather than resentment!

Continue reading '7 principles for contributing patches to software projects'»


Upgrading to openSUSE 12.2

By , September 25, 2012 12:15 pm

Yesterday I did an online upgrade of my laptop from openSUSE 12.1 to 12.2, using this procedure. It was almost a painless process; however unfortunately something crashed the whole X session part-way through the upgrade so I had to manually re-run zypper dup from a virtual console to complete it. The procedure should probably warn about that scenario in some way, although there is no obvious clean solution, e.g. switching to runlevel 3 before starting the upgrade would probably kill the network when NetworkManager is in use. I also had some weirdness related to my encrypted /home partition (despite the advice in the release notes).

The final issue was Google Chrome failing to start with the following error:

/usr/bin/google-chrome: error while loading shared libraries: cannot open shared object file: No such file or directory

It seems that this is at least in part due to a disagreement between Google engineers and Linux distros on what symlinks ldconfig should generate. If you look in the %post section of the google-chrome-stable rpm, you’ll see

# Most RPM distros do not provide, i.e.
# so we create a symlink and point it to
# This is technically wrong, but it'll work since we do
# not anticipate a new version of bzip2 with a different
# minor version number anytime soon.

I don’t have time to decipher openSUSE’s shared library packaging policy, but I assume it’s deliberate that /usr/lib64/ does not exist as a symlink even though /usr/lib64/ and /usr/lib64/ do.
It has been suggested to me that this omission could be related to Regardless, google’s hack should have compensated for this, but for some reason (presumably related to the upgrade), there was a dangling symlink in /opt/google/chrome:

lrwxrwxrwx 1 root root 18 Sep 24 10:17 -> /lib64/

This symlink is not owned by any rpm, which suggests that google’s hack might be in violation of the FHS for modifying a static and potentially read-only filesystem – although that’s moot since the modification would only happen at install-time at which point opt has to be mounted read-write anyway. Regardless, removing that dangling symlink and pointing it to /usr/lib64/ fixed the issue.


Tool-building hacks #1: audible pings

By , February 11, 2012 8:07 pm

I think I’m genetically a tool-builder. My dad and uncle both take great pleasure in carefully selecting and buying or building tools for their workshops, my mum’s an expert woodcarver with a fair array of sharp pointy things, and these are not the only examples in the family. For me, the habit has manifested in electronic form, and I really enjoy programming new scripts etc. to help me work more efficiently. In fact I’ve collected such a vast array of them over the years that I had to start tracking them under version control back in 1999. (CVS did me proud for many years, but it did not age well, and I finally migrated them to git a few months ago.)

I can’t claim to be remotely unusual in this respect though – there’s a whole subculture of programmers (“hackers”) who can relate to this mindset. Sometimes when I build a new tool, I get the impulse to share it with the world in case it turns out to be of use to anyone else. In the past, these hacks have ended up on my software web page, but I think this blog might be a better medium.

So, without further ado, here’s a cute hack I just built: bping, a wrapper around ping(8) which makes it do a lot of beeping ;-) – one beep per packet received, with pitch going up an octave for every doubling of the response latency. (See below for installation instructions.) Why did I want this?

I use ethernet over power to connect the machines in my bedroom to the equipment in the lounge. In a high-rise apartment block with about 100 wireless networks fighting over the same spectrum band, this is (normally) a much more reliable option. However yesterday the connections in my home network started behaving very weirdly. I tried pinging various machines on the network from each other to narrow down the problem, but it was annoying to have to keep going between rooms to visually monitor the output from the various pings when it would have been quicker to be able to hear the quality of the connections being tested. So I wrote bping, which also turns a laptop into a sort of Geiger counter for wifi.

Currently bping uses bip (here’s a suggested approach to installation) which in turns uses sox to make the beeps. This works fine on Fedora 15 but unfortunately for some reason takes longer than one second to run on Ubuntu 11.10 and openSUSE 12.1, regardless of how short the beep is. I think it’s something to do with pulseaudio, but I haven’t bothered to figure it out yet. Answers on a e-postcard please …

By the way, many of my hacks are already publically available on my github account, but most aren’t documented yet. The current exceptions are:

I’ll try to document some of the others soon. Watch this space!


port redirection from kvm host to guest

By , January 23, 2012 2:58 am

I’ve just started using kvm in earnest, and immediately ran into the challenge of how to access my guest via ssh. My first instinct was to configure the guest in bridged mode, but this doesn’t work well (or at all) with wireless interfaces.

So plan B was to set up port redirection from the host to the guest, e.g. so that ssh’ing to localhost port 2222 would redirect to the guest’s port 22.

After a quick google, some fiddling with iptables, and a glance at the libvirt Networking wiki page, I was still having no luck. Then it hit me – my guest was using user-mode networking, and rather than getting its DHCP-allocated IP from the libvirtd-launched dnsmasq instance on the host, was receiving a hardcoded allocation of from the host which is on This can be extremely puzzling at first, because no network commands run on the host (such as ifconfig, iptables, brctl, route) will reveal this magic address, yet the host is still accessible from the guest via it.

After a lot more googling, I stumbled across a technique for configuring host to guest port redirection on a running VM. This sounded very promising, but virt-manager refused to accept the magic Control-Alt-2 key combination to switch to QEMU monitor mode. It turns out that this is no accident. However, since libvirt 0.8.8, the QEMU monitor can be accessed via virsh.
Note that the --hmp option is required, otherwise the monitor expects the command in JSON format, so omitting it leads to errors like error: internal error cannot parse json ... lexical error: invalid char in json text.

The final hurdle was figuring out the correct monitor command. The host_net_redir command as mentioned in the above article is no longer recognized. Luckily the QEMU monitor interface helped me out here – I spotted an encouraging sounding command hostfwd_add:

# virsh qemu-monitor-command --hmp sles11 'help hostfwd_add'
hostfwd_add [vlan_id name] [tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport -- redirect TCP or UDP connections from host to guest (requires -net user)

and google confirmed that the latter had superceded the former.

So finally we have the complete solution:

# virsh qemu-monitor-command --hmp sles11 'hostfwd_add ::2222-:22'
# ssh -p 2222 localhost
Last login: Mon Jan 23 00:37:44 2012
linux-mnsh:~ #


UPDATE: just found another very simple solution – add a new NIC to the VM which doesn’t use user-mode networking. Then it will get a IP (on by default) which is still NAT’d but also routable via virbr0 on the host, meaning no redirection is necessary; just ssh directly to the guest’s IP from the host. A minor disadvantage of this is that the guest won’t be directly reachable from outside the host, but that’s unlikely to be an issue in most scenarios.


Panorama Theme by Themocracy