Given the fact that patients have been shamelessly and copiously sharing information on the web since, well, it first sprung up, it is nice to see that the medical establishment has gotten on board with the idea of collaboration. Medpedia is firmly an expert project (though it looks like anyone can provide suggestions) and I am not bothered by this limitation. What I do hope to see is a recognition of the controversies that abound in the realm of medicine (Lyme disease, fibromylagia, and a real hot rod issue = autism). There is much about diagnosis and therapy in medicine that exists in the I am not sure (how to diagnose/treat category and I wonder if this will be reflected in this new project. I certainly hope so.

Yesterday, I posted part 1 of how to think about compression. If you haven t read it already, take a look now, so this post makes sense. Introduction In the part 1 test, I compressed a 6GB tar file with various tools. This is a good test if you are writing an entire tar file to disk, or if you are writing to tape. For part 2, I will be compressing each individual file contained in that tarball individually. This is a good test if you back up to hard disk and want quick access to your files. Quite a few tools take this approach rdiff-backup, rdup, and backuppc are among them. We can expect performance to be worse both in terms of size and speed for this test. The compressor tool will be executed once per file, instead of once for the entire group of files. This will magnify any startup costs in the tool. It will also reduce compression ratios, because the tools won t have as large a data set to draw on to look for redundancy. To add to that, we have the block size of the filesystem 4K on most Linux systems. Any file s actual disk consumption is always rounded up to the next multiple of 4K. So a 5-byte file takes up the same amount of space as a 3000-byte file. (This behavior is not unique to Linux.) If a compressor can t shrink enough space out of a file to cross at least one 4K barrier, it effectively doesn t save any disk space. On the other hand, in certain situations, saving one byte of data could free 4K of disk space. So, for the results below, I use du to calculate disk usage, which reflects the actual amount of space consumed by files on disk. The Tools Based on comments in part 1, I added tests for lzop and xz to this iteration. I attempted to test pbzip2, but it would have taken 3 days to complete, so it is not included here more on that issue below. The Numbers Let s start with the table, using the same metrics as with part 1:

Tool	MB saved	Space vs. gzip	Time vs. gzip	Cost
gzip	3081	100.00%	100.00%	0.41
gzip -1	2908	104.84%	82.34%	0.36
gzip -9	3091	99.72%	141.60%	0.58
bzip2	3173	97.44%	201.87%	0.81
bzip2 -1	3126	98.75%	182.22%	0.74
lzma -1	3280	94.44%	163.31%	0.63
lzma -2	3320	93.33%	217.94%	0.83
xz -1	3270	94.73%	176.52%	0.68
xz -2	3309	93.63%	200.05%	0.76
lzop -1	2508	116.01%	77.49%	0.39
lzop -2	2498	116.30%	76.59%	0.39

As before, in the MB saved column, higher numbers are better; in all other columns, lower numbers are better. I m using clock seconds here on a dual-core machine. The cost column is clock seconds per MB saved. Let s draw some initial conclusions:

• lzma -1 continues to be both faster and smaller than bzip2. lzma -2 is still smaller than bzip2, but unlike the test in part 1, is now a bit slower.
• As you ll see below, lzop ran as fast as cat. Strangely, lzop -3 produced larger output than lzop -1.
• gzip -9 is probably not worth it it saved less than 1% more space and took 42% longer.
• xz -1 is not as good as lzma -1 in either way, though xz -2 is faster than lzma -2, at the cost of some storage space.
• Among the tools also considered for part 1, the difference in space and time were both smaller. Across all tools, the difference in time is still far more significant than the difference in space.

The Pretty Charts Now, let s look at an illustration of this. As before, the sweet spot is the lower left, and the worst spot is the upper right. First, let s look at the compression tools themselves: At the extremely fast, but not as good compression, end is lzop. gzip is still the balanced performer, bzip2 still looks really bad, and lzma -1 is still the best high-compression performer. Now, let s throw cat into the mix: Here s something notable, that this graph makes crystal clear: lzop was just as fast as cat. In other words, it is likely that lzop was faster than the disk, and using lzop compression would be essentially free in terms of time consumed. And finally, look at the cost: What happened to pbzip2? I tried the parallel bzip2 implementation just like last time, but it ran extremely slow. Interestingly, pbzip2 < notes.txt > notes.txt.bz2 took 1.002 wall seconds, but pbzip2 notes.txt finished almost instantaneously. This 1-second startup time for pbzip2 was a killer, and the test would have taken more than 3 days to complete. I killed it early and omitted it from my results. Hopefully this bug can be fixed. I didn t expect pbzip2 to help much in this test, and perhaps even to see a slight degradation, but not like THAT. Conclusions As before, the difference in time was far more significant than the difference in space. By compressing files individually, we lost about 400MB (about 7%) space compared to making a tar file and then combining that. My test set contained 270,101 files. gzip continues to be a strong all-purpose contender, posting fast compression time and respectable compression ratios. lzop is a very interesting tool, running as fast as cat and yet turning in reasonable compression though 25% worse than gzip on its default settings. gzip -1 was almost as fast, though, and compressed better. If gzip weren t fast enough with -6, I d be likely to try gzip -1 before using lzop, since the gzip format is far more widely supported, and that s important to me for backups. These results still look troubling for bzip2. lzma -1 continued to turn in far better times and compression ratios that bzip2. Even bzip2 -1 couldn t match the speed of lzma -1, and compressed barely better than gzip. I think bzip2 would be hard-pressed to find a comfortable niche anywhere by now. As before, you can download my spreadsheet with all the numbers behind these charts and the table.

If you re reading this post via the website rather than a feed/planet then you will notice that the site has gone completely black in support of the Creative Freedom Foundation s campaign against S92A of the NZ Copyright Amendment Act which is due to come into effect on 28th February 2009. I ve also joined the wave of people blacking out their avatar on Facebook/Jabber/MSN, etc. S92A introduces Guilt Upon Accusation whereby if you are accused of copyright infringement (downloading music and movies, etc) repeatedly (likely 3 or more times) you are at risk of being disconnected from the Internet by your ISP. The law does not require any proof or substantiation of the accusations and the entire process would occur outside of the courts and the established legal system. Not only does it place every user at risk, the wording is very unclear on exactly what type of organisation is considered an ISP and there is significant concern that schools, businesses, libraries and hospitals will be placed in the difficult position of determining whether their users have broken the law and require disconnection. Opposition to the law is not an attack on copyright, or a statement that we should be free to download all the movies and music that we desire. Those sorts of activities are clearly wrong, and I don t have any issue with copyright holders wanting to enforce their rights when their content is illegally copied. However, disconnecting people upon accusation, with no proof or formal legal process to prove guilt is not the right way to go about it. The fact that the law does not require proof of guilt is only the tip of the iceberg in terms of problems with it. For further background on the problems it causes for ISPs by placing them as the middle-man in copyright disputes you should refer to the following posts:

• Russel Brown of Public Address, points out that among other faults the law stipulates a penalty that no court would impose in adjudicating a copyright complaint
• David Farrar of Kiwiblog, has a guest post at the NZ Center for Political Research explaining how the law affects businesses
• Creative Freedom Foundation Background on S92

Finally, I think it is worth pointing out that S92A was removed from the proposed Amendment at the select committee stage, but was later reintroduced by Judith Tizard during the final reading of the bill. Mark Harris has an excellent post on the history of the amendment which includes facts such as the official report on the amendment also recommended removing S92A as it was unecessary given existing ISP terms and conditions which forbid illegal activity. The fact that the select committee (based on public submissions) recognised the problems with S92A and removed it, only to have it added back in again at the last stage when we no longer had any say on it really hacks me off and I cant help but feel the influence of the big money American media companies pressuring our politicians to pass a law that they don t really understand the full consequences of. So what is to be done? The Blacked Out campaign, being run by the Creative Freedom Foundation is gathering steam and international attention. Peter Dunne of United Future (who originally voted for the amendment) has declared that the amendment is wrong, and doesn t do what they thought they were voting to do, we need to convince National and the rest of the house of the same. Time is running out for this to happen before the amendment comes into effect on Feb 28th, but there is still time to write to your local MP and sign the petition against S92A Guilt Upon Accusation . The Creative Freedom Foundation site has a nice easy list of what you can do to register your protest.

It's time to drive some buzz this way ;-) Although this post will only be a pointer towards the Spanish post I made on Planeta EDUSOL, for reasons soon to become obvious. In any case, the information I'm posting here is not exactly the same. Can you read Spanish? Please go on to the invitation for the first videoconference for the EDUSOL Seminar. This year, we the organizers of the On-line Encounter of Education and Free Software (EDUSOL) are aiming higher - we are not "just" having a two-week encounter at the end of the year - We are having an all-year-long Seminar, focusing on the collaborative construction of knowledge. People from quite distinct backgrounds will be part of this project, and we aim to drive it towards the publication of a book. We (mainly, Alejandro Miranda and me) have been quite busy bootstrapping this seminar, getting the proposed authors, thinking over the intended communication channels and ways, and setting up the needed infrastructure) and are ready to start the public-facing activities. We will be having monthly videoconferencing sessions, the last Thursday each month, 16:00-18:00 Mexico Central time (currently GMT-6; GMT-5 after the beginning of April). The VC sessions will be also relayed through Ogg streams, and we will have an IRC channel available to offer full interactivity for those who do not have access to a H.323 VC setup. This first session will be moderated by Victor Manuel Mart nez; the speakers will be Alejandro Miranda and myself - The topics we will present are:

• Short project presentation, delineating the list of invited authors and tematic lines we will pursue
• Description of the collaboration scheme we expect to hold, including how everybody (not just invited authors) can participate
• Presentation of one of the topics we will work into in the Seminar: Free Software and the Democratic Construction of the Society

If you have access to videoconferencing facilities, please get in touch with Carlos Cruz, the Videoconferences Coordinator at the Economic Research Institute, as soon as possible for all the needed coordination.

Neil McGovern noticed me using drivel for my blog entries at the recent Debian UK BSP for Lenny and as he isn't using it anymore, suggested that I might want to take over maintenance. It's always better to have a package maintained by a regular user of the program.

So, this is the blog post prior to the upload of the blog client, drivel.

I have a feeling that I may be taking on another upstream project into the bargain - I'm interested but not sure how much time it should consume. Upstream is not exactly active but that isn't a huge problem for me. There is a new unreleased version that needs a few fixes but the hardest part is the external bells and whistles, not the core of the program.

The initial upload fixes all the lintian stuff in the current package but drivel is a bit different to other packages, fixing bugs in drivel means having a way to test drivel with a variety of blogs, not just my own and that means setting up admin access to a variety of blog engines. Not sure I really want to be setting aside that much time.

Once the new version is in Squeeze, I'd welcome any ideas about extra functionality, provided all such ideas come with either patches or a willingness to test the upstream code against your own blog.

Scott has several posts about git (1, 2, 3), and the I worked on this locally, now I want to push this to a remote place where others will be able to fetch it . I ve been using the following snippet for that. YMMV.

REPO=reponame
ROOT=/wheremygitreposare/
SERV=remoteserver
git clone --bare . /tmp/$ REPO .git && \
rsync -avzP /tmp/$ REPO .git $ SERV :$ROOT && \
git remote add origin $ SERV :$ ROOT $ REPO .git && \
git config branch.master.remote origin && \
git config branch.master.merge refs/heads/master (Please post comments if you can improve it!)
But I totally agree that this common use case is not well addressed in git.

Yay! This blog post is not strictly speaking news anymore - But for those who don't know it yet, three days ago Debian 5.0 Lenny was released, after 22 months of work (plus fun, plus flamewars, plus everything that makes a Free Software lover tick). And, of course, that makes us all very happy and proud. As always, upgrading is a breeze. Hats off specially to Wolfgang and everybody who worked towards the great release notes - No, it is not a simple task, by far. And I _do_ feel ashamed I didn't even beep that way :-( So, many of us are in the middle of planning/executing our servers' migrations. So far, I'm amazed for good. Even hairy issues such as firmware removal are magically and beautifully taken care of - i.e. my firewall kindly informed me during update that I would need to install the non-free firmware for my BNX2 (Broadcom) network interfaces, and I was just a package away from absolute happiness. Lets see what happens next Friday, as I will be upgrading our storage+application server (which is _way_ more complex than the servers I've dealt with so far). Anyway... But what good is a blog post if you are not ranting? Many people recognize me as one of the most Debian-connected people in Mexico, and that's very good. And yes, besides being a Debian Developer, I am a co-sysadmin for the main Debian mirror in Mexico. Some people have already asked me for CD-ROMs and DVDs. Of course, if I had a BluRay drive, I'm sure I'd also get requests for it. People: Do you really want such media? Think again... Do you really want 31 CDs or five DVDs for your favorite architecture? Ok, maybe many will say "nah, just give me the first one" - Then, do you want to limit your Debian experience to just the software that lives on the first 1/31th (or 1/5th) of it all? Of course there are many situations where it is desirable. Low bandwidth users, or people with no regular connectivity, will be much better served by suitable media from which to install. However, most of us (computer geeks living in Mexico City - Yes, that's the people contacting me) have at least a 1Mbps connection at home. People, just get the Netinst or Businesscard (180 or 40MB) images and download whatever is left via the network. Debian is extremely network-friendly. And, believe me, even if packages are sorted by popularity (and that's why most people will be happy with the first DVD if needed), you never know if you will want precisely a package that sits towards the lonely tail of popularity. And, yes, I did have my CD images handy for the Potato, Woody and Sarge cycles - but increasingly, it became easier for me just to ask apt-get to fetch stuff from the web (which is done without me moving from my comfy chair while I do anything else) than asking apt-get to ask me to go search for the f.*ing CD which I left dont-remember-where. Anyway... I'm not saying I won't burn your CDs - If you want them, please tell me in advance and come to my office, I'll be glad to give you some Debian disks. But spare the environment. We don't need to burn more and more disks. Use the network, be a better human being!

I think a desireable property of the helper stuff that debian packages wrap around the underlying program (such as mailservers, webservers, etc.) is that you are still exposed to some extend to the configuration of the underlying service. The exim4 debian "value-add" layer is so thick that despite using exim4 in Debian for more than 4 years, I have been totally insulated from the configuration and have no idea how to do even the simplest tasks. Upgrading to lenny and exim4-config will not install due to DEBCONF templates in my config file. Yes, they are there, the older exim4 packages put them there. When prompted by debconf during the initial upgrade attempt, I said "do not overwrite my local exim4 configuration, it's changed a little". Reading the resulting error messages, that was the wrong answer: Now I need domain knowledge that the debian package has kept from me for all these years to proceed at all, and the tone of NEWS.gz is that it's my own damn fault. Thanks to Brett Parker for the solution: cp /var/lib/exim4/config.autogenerated /etc/exim4/exim4.conf and finally put a stop to this poisonous relationship that the exim4 packaging and I have had for all this time.

As Debian/Lenny has been released and the temperatures in my part of the world are no longer insanely hot I have put my SE Linux Play Machine [1] online again. It is running Debian/Lenny and is a Xen DomU on a Debian/Lenny Dom0. To get this working I had to make a few more fixes to the SE Linux policy and will update my Lenny repository (as mentioned in my document on installing SE Linux on Lenny [2]) in the near future. I have reformatted most of the text from the thanks.txt file on my Play Machine and put is online on my documents blog [3]. I have also graphed the logins to my Play Machine using Webalizer [4] with 1KB transfer in the graph meaning one minute of login time. Below is the Perl code I used to convert the output of last -i to what looks like an Apache log file, the program takes a single command-line parameter which indicates the year that the data is from (which is not included in last output) and takes the output of last -i on standard input and gives a web log on standard output. #!/usr/bin/perl my @output; while(<STDIN>)

if(not $_ =~ /^root.*pts/)

next;

$_ =~ s/ +/ /g;
$_ =~ s/^root pts.[0-9]+ //;
chomp $_;
my @arr = split(' ', $_);
my $url = "/";
if($arr[6] =~ /crash/)

$url = "/crash";

my $t = $arr[7];
$t =~ s/[()]//g;
my @times = split(':', $t);
if($times[0] =~ /\+/)

my @hours = split('\+', $times[0]);
$t = $hours[0] * 24 * 60 + $hours[1] * 60 + $times[1];

else

$t = $times[0] * 60 + $times[1];

$t *= 1024;
if($t == 0)

$t = 1;

if(length($arr[3]) == 1)

$arr[3] = "0" . $arr[3];

$output[$#output + 1] = "$arr[0] - - [$arr[3]/$arr[2]/$ARGV[0]:$arr[4]:00 +0000] \"GET $url HTTP/1.0\" 200 $t \"-\"\n";
my $i;
for($i = $#output; $i > -1; $i--)

print $output[$i];

• [1] http://www.coker.com.au/selinux/play.html


• [2] http://doc.coker.com.au/computers/installing-se-linux-on-lenny/


• [3] http://doc.coker.com.au/computers/thankstxt-on-my-play-machine/


• [4] http://www.coker.com.au/selinux/play-stats/index.html

Okay, again delay :-). I wanted to push this version out yesterday, but real life has caught me and I did not manage to do it. So this time Gammu is released on Tuesday, but I want to get back to Monday releases next week. If all things go without problems, this is last testing release before 1.23.0. Besides changing files structure a lot (I hope current one better matches current state of code), there are only some minor fixes and cleanups. Full list of changes follows:

• Reorganize directory structure to match current state of things.
• Completely switch DBI driver to utf-8.
• Fixed date off by 1900 error in some cases.
• Cleanup a bit phonet driver.
• Handle properly requests for network code (bug #819).
• Allow to enter more security codes through SMSD (bug #819).
• Fixed restoring to specific folder on AT (bug #815).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon, SUSE, Fedora and Mandriva users can check experimental repository in OpenSuse Build Service.

So, I've had this plan for ages to follow up with what I did with my nslu2, and hide a Debian box inside a working stereo. Finally I've started work on this little project. I bought a cheap stereo with CD/tape/radio, mostly on the criteria:

• It needed to be big enough to stand a chance of fitting my qnap board and a full size SATA drive in it. But not too big..
• It needed to have line in. Luckily, most stereos do, thanks to ipods.

I got lucky.. after removing the CD drive, ripping out the battery compartment, and making other modifications to the interior of the case, I had just enough space to fit the qnap board, with centimeters to spare in some places, and millimeters in others. It fits perfectly. The board's LEDs and reset button will be accessible via the CD slot. I was able to keep the radio and amp working. Wiring up a USB sound card to that was easy. I could have kept the cassette deck working, but since I don't have any more of that media, I stripped it, and am planning to put a USB hub in there, accessible by pressing Stop/Eject. ;-) It seems I will even have a fair bit of empty space. Pondering adding a small UPS. Or, I might toss in an access point.

As an obligatory note, Debian Lenny was released earlier today. Which means that sysadmins all over the world are starting to upgrade their servers. There is an oddly little known tool that each and every sysadmin should install on at least one server they maintain, called apt-listchanges. It lists changes made to packages since the currently installed version. Sure that information will be overwhelming on major upgrades, but what is useful even on major upgrades is the capability to parse News files in the same way. News files contain important information about the package in question. For example a maintainer could list known upgrade problems there, like is done in the lighttpd package. Or list changes in package specific default behaviour, like is done in Vim package. Sure, you will notice these in time, but it's nice to get a heads up before a problem bites you.

I've been bitten by grub upgrades and installations on Debian family domU servers. Apparently there are others out there who have been bitten too. The bug itself is caused by a missing device entry, probably because of udev. Anyway, grub-probe tries to discover the root device so that update-grub can properly generate a menu.lst. In certain scenarios the root device itself doesn't exist. Here is an example from a configuration generated with xen-tools:

Hydrogen:/etc/xen# grep phy Neon.cfg 
disk    = [ 'phy:Local1/Neon-disk,sda1,w', 'phy:Local1/Neon-swap,sda2,w' ]

While this is a valid configuration, the device sda doesn't exists within the virtual machine. As a workaround the above blog entry suggests manually adding the sda device and the device entry in device.map. This solution does work, but it will fail with the next upgrade. The proper solution is to adjust the Xen configuration so that the root device is created. And since Xen uses different naming scheme for devices we can upgrade to that too. So the above example becomes:

Hydrogen:/etc/xen# grep phy Neon.cfg 
disk    = [ 'phy:Local1/Neon-disk,xvda,w', 'phy:Local1/Neon-swap,xvdb,w' ]

You also need to adjust the existing grub configuration and fstab within the domU. It's a bit more work and requires an additional reboot, but it gives you a peace of mind that the next upgrade will work without a hitch.

and the case against bzip2 Compression is with us all the time. I want to talk about general-purpose lossless compression here. There is a lot of agonizing over compression ratios: the size of output for various sizes of input. For some situations, this is of course the single most important factor. For instance, if you re Linus Torvalds putting your code out there for millions of people to download, the benefit of saving even a few percent of file size is well worth the cost of perhaps 50% worse compression performance. He compresses a source tarball once a month maybe, and we are all downloading it thousands of times a day. On the other hand, when you re doing backups, the calculation is different. Your storage media costs money, but so does your CPU. If you have a large photo collection or edit digital video, you may create 50GB of new data in a day. If you use a compression algorithm that s too slow, your backup for one day may not complete before your backup for the next day starts. This is even more significant a problem when you consider enterprises backing up terabytes of data each day. So I want to think of compression both in terms of resulting size and performance. Onward Starting Point I started by looking at the practical compression test, which has some very useful charts. He has charted savings vs. runtime for a number of different compressors, and with the range of different settings for each. If you look at his first chart, you ll notice several interesting things:

• gzip performance flattens at about -5 or -6, right where the manpage tells us it will, and in line with its defaults.
• 7za -2 (the LZMA algorithm used in 7-Zip and p7zip) is both faster and smaller than any possible bzip2 combination. 7za -3 gets much slower.
• bzip2 s performance is more tightly clustered than the others, both in terms of speed and space. bzip2 -3 is about the same speed as -1, but gains some space.

All this was very interesting, but had one limitation: it applied only to the gimp source tree, which is something of a best-case scenario for compression tools. A 6GB Test
I wanted to try something a bit more interesting. I made an uncompressed tar file of /usr on my workstation, which comes to 6GB of data. My /usr contains highly compressible data such as header files and source code, ELF binaries and libraries, already-compressed documentation files, small icons, and the like. It is a large, real-world mix of data. In fact, every compression comparison I saw was using data sets less than 1GB in size hardly representative of backup workloads. Let s start with the numbers:

Tool	MB saved	Space vs. gzip	Time vs. gzip	Cost
gzip	3398	100.00%	100.00%	0.15
bzip2	3590	92.91%	333.05%	0.48
pbzip2	3587	92.99%	183.77%	0.26
lzma -1	3641	91.01%	195.58%	0.28
lzma -2	3783	85.76%	273.83%	0.37

In the MB saved column, higher numbers are better; in all other columns, lower numbers are better. I m using clock seconds here on a dual-core machine. The cost column is clock seconds per MB saved. What does this tell us?

• bzip2 can do roughly 7% better than gzip, at a cost of a compression time more than 3 times as long.
• lzma -1 compresses better than bzip2 -9 in less than twice the time of gzip. That is, it is significantly faster and marginally smaller than bzip2.
• lzma -2 is significantly smaller and still somewhat faster than bzip2.
• pbzip2 achieves better wall clock performance, though not better CPU time performance, than bzip2 though even then, it is only marginally better than lzma -1 on a dual-core machine.

Some Pretty Charts First, let s see how the time vs. size numbers look: Like the other charts, the best area is the lower left, and worst is upper right. It s clear we have two outliers: gzip and bzip2. And a cluster of pretty similar performers. This view somewhat magnifies the differences, though. Let s add cat to the mix: And finally, look at the cost: Conclusions First off, the difference in time is far larger than the difference in space. We re talking a difference of 15% at the most in terms of space, but orders of magnitude for time. I think this pretty definitively is a death knell for bzip2. lzma -1 can achieve better compression in significantly less time, and lzma -2 can achieve significantly better compression in a little less time. pbzip2 can help even that out in terms of clock time on multicore machines, but 7za already has a parallel LZMA implementation, and it seems only a matter of time before /usr/bin/lzma gets it too. Also, if I were to chart CPU time, the numbers would be even less kind to pbzip2 than to bzip2. bzip2 does have some interesting properties, such as resetting everything every 900K, which could provide marginally better safety than any other compressor here though I don t know if lzma provides similar properties, or could. I think a strong argument remains that gzip is most suitable for backups in the general case. lzma -1 makes a good contender when space is at more of a premium. bzip2 doesn t seem to make a good contender at all now that we have lzma. I have also made my spreadsheet (OpenOffice format) containing the raw numbers and charts available for those interested. Update Part 2 of this story is now available, which considers more compression tools, and looks at performance compressing files individually rather than the large tar file.

This is a followup to the earlier design of dh. After converting many packages to minimal rules files using dh, I find that it works very well for the 3 line rules file case, which works for 80% of packages. But getting from there to a slightly more complex rules file that 20% of packages need can be non-obvious. So, let's make it obvious. Suppose I want to run dh_compress -Xsomefile. But my rules file as it currently stands doesn't offer an easy place to run that command:

#!/usr/bin/make -f
%:
    dh $@

To use dh in this situation you had to go look up rather a lot of boilerplate, and to insert an explicit version of the right target, with the right dependencies, that called dh before and after your command:

#!/usr/bin/make -f
%:
    dh $@
binary: binary-indep
binary-indep:
    dh $@ --before dh_compress
    dh_compress -Xsomefile
    dh $@ --after dh_compress

That took me half an hour to come up with, and I wrote this stuff! Also, if I want to override a second command, I have to do it in the right order. So, the full flexability of debhelper is there, but it's too hard to get at. Here's the new new thing.

#!/usr/bin/make -f
%:
    dh $@
override_dh_compress:
        dh_compress -Xsomefile

What this does should be obvious. These override targets can be written for any debhelper command that you need to change the default behavior of, or even avoid running at all.

override_dh_auto_configure:
    ./configure --with-kitchen-sink
override_dh_auto_test:
    # The test suite for this package is busted on s390.
    if [ $DEB_BUILD_ARCH != s390 ]; then dh_auto_test; fi

The overrides can also be used to run additional stuff before, or after any debhelper command:

override_dh_clean:
    dh_clean
    rm -rf build_dir

So, I think that's beautiful. Simple, clean, no boilerplate, and intuitively obvious if you are familiar with debhelper.

---

FWIW, the implementation, which will be in the next debhelper release unless someone screams loudly, is not beautiful. Mostly because I sorta shot myself in the foot with the cute implicit "%:" rules. But, I got around it. :-)

"Hard SF" is a sub-genre of Science Fiction where "Science" is key. It's very hard to draw solid lines around stories that are examples of Hard SF, but it's easier to provide examples of things which are not: "Star Wars", for example, where space ships, travel and light sabres are window-dressing around a fantasy story. If you look at the Wikipedia article on Hard SF, in particular it's edit history, you will see people continually argue back and forth. Editor Jonathan Strahan recently asked for some recommendations of Hard SF authors to be included in a new Hard SF anthology. I stumbled across this via sfsignal. There are some good comments at both sites, and a fair amount of disagreement over whether certain authors should be considered Hard SF authors or not. Alastair Reynolds was cited by people several times. I really enjoy much of Reynold's writing, but I wouldn't consider it Hard SF. I argued this point and Reynolds himself joined the discussion.

I have attended FOSDEM again this year. Most of all, it was nice to see everyone again, especially the Collabora crew. Besides having fun while hanging out with them again, I must say FOSDEM was quite a motivation boost too! I feel motivated again to work on Ruby packaging. The whole RubyGem mess and other less-specific Ruby-related messes keep draining my motivation. This feels very conflicting, since I like the language very much. The upcoming transition to Ruby 1.9.1 will be quite a challenge and I hope that we can finally work out a nice, actual Ruby policy for Squeeze. A few days ago I have also joined the pkg-gstreamer team, mainly to work on Elisa packaging. Elisa is a nice-looking media center application that I am using on my HTPC(Home Theater PC). Debian s experimental suite now contains an up-to-date version of Elisa, try it out if you want. Elisa 0.5.27 So, why is Elisa not in unstable yet. Well, Elisa has a plugin system which also features auto-updates. While this is very nice on platforms such as Windows, it is not really nice for Debian. I have been working to get this updating disabled by default. Once I am sure (hopefully by the time 0.5.28 gets released) that it is in order, I wil upload it to unstable. Meanwhile I am planning to work on some Elisa plugins to add some features that I feel are missing. First of all I need webradio a la Rhythmbox in there. Then something to watch TV: a MythTV frontend-plugin, via UPnp, or whatever works. Finally it might be nice to have to have a plugin to setup video-conferencing using Telepathy. I m quite sure some of these things are lying around somewhere, more about that later.

It's been a little wet around here recently. Enough so that I bought an umbrella yesterday. Unfortunately, I didn't take it out on my walk today. So on my way back from Golden Gate Heights, I felt more soaked than when I went out to walk all of Broderick in the pouring rain.

On the getting things done front, I have finally put up my disco ball. It's been 9 hours and it is still up so I think it will hold over night.

Lenny got released yesterday and after having to push another update to Etch through volatile to fix an annoying warning when Lenny is in the sources.list, my work is now almost done too. (Yes, the autobuilding infrastructure is still offline, but we will get that reactivated shortly.) Anyway: if you live in or around Karlsruhe and did not get a mail by nomeata and me and if you would enjoy meeting tomorrow (Monday) evening, please speak up by mailing us. Let us celebrate the latest and greatest release. ;-) The plan is to meet up at the Vogelbr u at 19:30.

In a nice coincedence with the release of Lenny (cheers!!1), the low-quality versions of the videos from the Debian DevRoom at FOSDEM 2009 are available now!

Better quality versions will be encoded and uploaded by Ben over the next days. I'd also like to collect the slides from the talks there, so if you had a talk there, please send them to Wouter and/or me, and Wouter, please send me the slides you collected on the presetation computer ;-)

Basically I'm very happy with our results, excpet for two things: sadly the computer running dvswitch wasn't powerful enough to do picture in picture (and due to time constraints we weren't able to switch to a more powerful one), so we'll have to plan this better next year. And second, I have no real clue how useful our streaming efforts are, I believe the recordings are useful, but in both cases feedback from people who find them useful is appreciated! Covering FOSDEM is certainly a lot of fun, but it's also a lot of work and leaves not much room for seeing other parts of the conference. So a short reply (I'll post this to d-d-a with reply-to set to -project) will be very much appreciated! :)

Big thanks go to Womble2, edrz, xerrako, Q_, danielsan, DaCa, tokkee, luca, Yoe, Ganneff, franklin, huhn, luk, CarlFK, daven and some more volunteers I cannot remember right now! Also not to be forgotten the FOSDEM crew & volunteers for an awesome event and the people from CCC Hamburg who came by car and took a lot of audio/video/computer equipment for us (and left 90min later than planned! Thanks again!)! And also Debian (via the DPL) for some 120 Euros to rent equiqment and for buying batteries and the always needed duct-tape!