World IPv6 day is over

What a great day it was. World IPv6 day happened on 8th of June 2011 and I was able to reach a lot of websites with IPv6 without any troubles. That made this day also a going test run for my own IPv6 deployment. Native IPv6 at home and a HE tunnel at work allowed me to use Google & Youtube over IPv6 without tinkering with DNS resolution.

Sadly, most of the participants decided to disable their AAAA-Records in DNS after the day was over, so it's back to DNS-hacking or using IPv4 for those who do not have the balls to enable IPv6 in a dual-stack way permanently. Maybe we can have an IPv6 day soon :-)

Posted
Speeding up liferea on btrfs

A  while ago I migrated my /home LVM volume to the new (experimental) btrfs in order to take advantage of snapshots for backup. Despite my overall satisfaction with btrfs in terms of usability and features, it turned out that there is one major issue with applications making excessive use of fsync(3). The symptom of this issue is a high latency to user-actions while data is being written to disk. The impact on my system was especially high with liferea, my news feed reader. It was completely unusable while fetching data or marking a batch of items as read.

After some investigation I found eatmydata, which basically replaces all calls to fsync(3) with it's own implementation, which just returns without doing anything. On Debian, it can be installed directly from the archives:

aptitude install eatmydata

It offers a small binary which can be used to bootstrap other applications to use the variant of fsync(3) provided by eatmydata instead of glibc. This is how I use it right now to start liferea:

eatmydata -- liferea

There are of course drawbacks and risks of using eatmydata. The purpose of fsync(3) is to ensure that data is safley written to a disk before going on with the work-flow inside an application. Effectively discarding those calls to fsync(3) exposes an application to potential data-loss! As liferea does not handle data for which I depend on integrity, I can cope with the risk of losing it but I would never ever use it on critical applications!

Posted
Mercurial Redirector for Debian uscan

While working on Debian packages for the Mozilla Sync Server, I came across the task to provide a URL for uscan to identify new releases. Mozilla does only provide Mercurial tags for each new release in their repository. To be able to use those tags as pointers to the tarballs of the new releases I set up a simple redirector for sites like hg.mozilla.org.

It can be found at http://debian.fladi.at/hgredir and should be used like in this example for the repository at http://hg.mozilla.org/services/server-reg/:

http://debian.fladi.at/hgredir/hg.mozilla.org/services/server-reg/

The accompanying debian/watch file would look like this:

version=3
opts=filenamemangle=s/.*\/rpm-([\d\.]+)-\d+\.tar\.bz2/mozilla-syncreg-$1\.tar\.bz2/ \
http://debian.fladi.at/hgredir/hg.mozilla.org/services/server-reg/ \
http://hg.mozilla.org/services/server-reg/archive/rpm-([\d\.]+)-\d+\.tar\.bz2

Maybe this redirector could be useful to others so I will maintain it as an freely available service.

Posted