1 billion seconds

... turns out to be slightly over 31 and a half years.

According to the text of my birth certificate, I was born at 13:20. So, with that, we can make the following calculation:

wouter@celtic:~$ date -d '1978-05-06 + 13 hours + 20 minutes + 1000000000 seconds'
Tue Jan 12 15:06:40 CET 2010

Since I missed my 10000 days, and I was sortof unhappy about that, I guess this one is a good substitute.

Unfortunately the 12th of January is a tuesday, but I guess I can throw a party during the weekend...

Not voted

So apparently Steve got re-elected this year. Congrats, also to Luk; and to Zack, who didn't do too bad.

Careful readers may notice that, for the first time since early 2001 when I achieved Debian Developer status, I did not exercise my right to vote. This was not because I didn't care about the vote, but because if I were to vote honestly, I would've done something like '11-', which has mostly the same effect as not voting. The candidates this year were both equal in my opinion, so I just didn't bother.

Ugly fonts

This week seems like ugly fonts week.

First, KDE4 was uploaded to unstable. Now I'm not a KDE user, but I do cherry-pick a few KDE applications which I find useful or interesting, and use them in my IceWM environment; these are mainly korganizer (with konsolekalendar in my .bashrc), kdebluetooth, and digikam.

First thing I noticed is that something went horribly bad with the fonts -- see this screenshot for an example of what the problem is; the korganizer window in the background has ugly artifacts, while the kbluetooth menu in the foreground is still a KDE3 window which does what I was expecting.

Second, someone thought it good to add console-setup as a dependency of Xorg 7.4. Now by itself, there's nothing wrong with that, except for the fact that console-setup by default changes the console font to something else. I had, in fact, tried out this setup a while back, but eventually (after a few weeks), decided that I did not like this font, because it's a) ugly and b) unreadable on a high-resolution 12" display.

So I changed /etc/default/console-setup to get the VGA font back, ran the console-setup initscript, and all was well.

Until my laptop was resumed from suspend-to-RAM. Apparently the console font is changed at that point in time, too, with some other configuration, and I'm not sure how to fix it.

Oh well.

Using NBD to get rid of an LVM installation.

LVM can be a virtue. However, it can also be a pain at times; for instance, there's loss of diskspace due to LVM's metadata that needs to be stored as well. This amounts to approximately 5% of the diskspace (if I'm not mistaken), which can be quite a bit. Also, this is an extra abstraction layer, which requires memory and CPU time to be processed. This will be negligable on most modern computers, but sometimes it isn't.

I had a system that had quite a few things on LVM, and wanted to get rid of them. Unfortunately, to remove the LVM physical volumes would mean that I'd have to get rid of the data, which would mean storing it somewhere else, which in turn would probably mean that I wouldn't be able to use the system for quite a long time. That wasn't acceptable.

So, instead, what I did was to export a whole hard disk (one with enough space to hold the logical volumes on that machine) using NBD, and migrate stuff that way:

• First, set up the NBD export. The config file should look something like this:

[generic]
	user = nbd
	group = disk
[export]
	exportname = /dev/hde
	port = 1234

This will export all of /dev/hde on port 1234. Obviously you wouldn't want to do this on an untrusted network, but that's always true with NBD (in my case, the link was a 1M crossed cable -- quite safe).

• Next, we'll connect the client:

nbd-client <server> 1234 /dev/nbd0

... assuming /dev/nbd0 is not in use yet. Provided the client machine is running kernel 2.6.26 or newer and nbd-client 2.9.10 or later (e.g., Debian Lenny or later), and you're running udev, this will create a number of /dev/nbd0pX device nodes, with X starting at 1, one for each partition on the disk. Of course, one can also export a specific partition rather than the whole disk, or just one file on a filesystem, or create a physical volume of the entire disk rather than just a partition -- your choice.

• Now we need to add the networked block device to the LVM volume group. Assuming the second partition is the one we want to use:

pvcreate /dev/nbd0p2
vgextend /dev/<vg> /dev/nbd0p2

If you now run 'vgdisplay', you'll see that the size of the LVM volume has increased considerably.

• Next, we'll want to move data over the network. Assuming the 'local' LVM volume is on /dev/sda7:

pvmove -v /dev/sda7

This will show progress information every 15 seconds while the data is being moved from the local hard disk to the NBD device. You'll be able to continue using the system as usual--although of course the system will gradually get slower and slower as more and more data is only available through a comparatively slow network connection.

• Once everything's moved to the other sytem, you're all set to change stuff locally:

vgreduce -a /dev/<vg>
cfdisk /dev/sda
...

• Finally, you'll need to move the data from the NBD device back to the local hard disk. If you're still using LVM, that can be done using another pvmove operation. If not, you'll have to do something else, like cp -a. Obviously in that case, there will be some time in which you won't be able to use the system properly.

This final step might not be as simple as it sounds; e.g., if your /home filesystem is on LVM currently and you want to move that out of LVM, you'll have to make sure only root is logged on; If /var is on LVM, too, you may have to go to single-user; etc. Figuring out the details for this one is left as an exercise to the reader.

However, I will note that since somewhere between etch and lenny, doing root-on-NBD is possible; and if you're running unstable, then doing root-on-LVM-on-NBD should be possible, too, although I would suggest a little caution before trying that.

In any case, using NBD in this way just saved me a whole lot of no-computer-time here. Which is great.

On Xorg and HAL

Recently there's been a bit of a fuzz about the fact that the xorg folks have introduced HAL as a requirement for X. I understand this is to make things easier.

So instead of configuring stuff through /etc/X11/xorg.conf, you now have to configure things through /etc/X11/xorg.conf, /etc/hal/whatever, and /etc/default/console-setup. In three completely and utterly different syntaxes, no less (xorg.conf format, XML, and shell script). How exactly this is 'easier' escapes me.

I presume this makes life easier for those multiseatcomputer folks; but for those of us with a normal computer, it doesn't, really.

Oh well.

Planet Grep: Survey

Planet Grep has been running for quite a while now. What started out as 'me playing with some random software' is now a rather popular website, read daily by many, many people, generating somewhere between 5 and 7 gigabytes of data each month. For a website that consists of a single page of (on average) less than half a meg, that's quite some traffic.

Originally, I just threw a bunch of blogs written by people whom I knew as being part of the Belgian FLOSS community in the config, and we kindof grew from there. That worked, but as Planet Grep grew, there have been a few times when I felt bad about some of the choices I'd made in the past.

Since I feel that a website whose content is written by a large community should not be in the hands of just one man (me), I already added Kris to the subversion ACL, so that he'd be able to add or remove people too.

But there's more that can be done, so today I wrote a little survey about Planet Grep. Its aim is to help me understand what people would like to see in Planet Grep, and perhaps tune the subscriber list based on that a bit. The results will be used to update the about pages.

As such, I'd appreciate it if people would fill out this survey. It's not going to take more than a few minutes (there's, like, only two pages).

Thanks!