forked-daapd v0.14 is available. This release includes a number of improvements to the sort headers/sort fields handling by Kai that got entangled into a larger database revamp at the end of last year. That will be the subject of the next release. Also in this release:

• better handling of tags for TV shows
• better handling of DRM-afflicted files
• configurable IPv6 support
• fixes to the URL file scanner
• misc fixes

This release performs a heavy database upgrade process that dumps and reloads the files table; this can take some time on big libraries, so please be patient while this process takes place. You should backup your database file before upgrading, just in case. See you in about two weeks for 0.15 with some database speedups that will finally see the light :-) Tarballs available at http://alioth.debian.org/~jblache/forked-daapd/ ; GPG signatures made with my Debian key F5D65169.

I finally found some time to convert my backport script to support squeeze (mostly because I finally did my first backport to squeeze). The script now treats squeeze as the default target and knows that it's the current stable, treats lenny as oldstable, and knows the correct version suffix to use for squeeze backports. It also now uses regular expressions to try to determine what code name a backport is targetted at, which should work better for more non-Debian internal distribution cases. You can get the latest version from my scripts distribution page.

In case you are using HP ProLiant G6-series or G7-series with Intel-based hardware and you are thinking about virtualistion (e.g. booting the hypervisor), you should have a look into this customer advisory. To make it short, the following should work:

# grep GRUB_CMDLINE_XEN /etc/default/grub
GRUB_CMDLINE_XEN= pci=use_crs
# update-grub It took me two workdays to discover this solution for a DL180G6. Anyways I m still having trouble on a DL160G6 when booting the hypervisor, suggestions are welcome.

I have been reading Linux Shell Scripting Cookbook by Sarath Lakshman, published by Packt, for a while. While most people I know learn shell scripts themselves, I was looking to refresh my concepts a little as well as have a reference lying around on the table for fast access. Since I was asked to review it for someone else, I thought I might as well post the review here.First of all, let me remark by saying that shell scripting is something learned more on a need basis than as a tool to solve the main problem. People would seldom write shell scripts as standalone programs (exceptions exist). However, what makes shell scripting invaluable to know is the fact that knowing some tricks can save several minutes, or hours, of work by automating and simplifying certain tasks, generally (but not restricted to) file management and data processing. Linux Shell Scripting Cookbook does go quite far in pursuing this goal, and is appropriate for both beginners who are looking to gain dexterity in shell scripting, as well as intermediate users who wish to polish their skills. The book also can double up as a quick reference, though I would argue that the "Advanced Bash Scripting Guide" would suit that more.At the outset, the author clarifies that the focus will be on Bash. This, people may or may not like, but the fact that bash has become ubiquitous in terms of the available shells on Unix-like systems today, starting out with bash is not a bad thing to do. Besides, learning other shell scripting languages while knowing bash isn't too hard, since the paradigm remains the same.Let's go through the books from the aspects I found most relevant.OrganizationThe book is organized into chapters based more on utility than scripting concepts themselves, although the language aspects are brought onto the reader gradually. For instance, the examples in the first chapter focus more on the basic data elements (variables, arrays, functions etc.) as well as operators (for numbers, files etc.), and all the examples demonstrate simple usage of these concepts, and he further chapters build upon these in a gradual manner.At the same time, if the reader has some familiarity with shell scripting and needs to only refresh or learn a certain concept, he/she needs to just read the relevant chapter. It is not too difficult to grasp the examples of the later chapters, provided some basic shell knowledge is assumed.Content and PresentationA positive trait in the presentation of this book is that it is all based on practical everyday examples which, with minor adaptation, can be used by many for their own daily tasks. For instance, there are several examples which describe searching for and processing files, which, I'd imagine, many users would want to do on a regular basis. Thus, providing realistic examples allows the book to double its utility. The language and approach used is simple and conversational, and the presentation is very clear, with each idea being described as a problem statement followed by a "How to do it" section with the actual code, and ending with a discussion of the nitty-gritties of the code. It is easy to go for a quick scan for those in a hurry, while those who with to read in more detail will not be disappointed either.The book also covers a wide array of applications. For instance, there are examples on automating fetching web pages and processing them, demonstrations of parsing and simplifying and even some queries around databases wrapped around in shell. It also spans to utilities and tasks connected to statistics, backups, compression, version control and many more.Breadth and DepthThe book goes into a fair amount of detail in terms of describing the shell scripting concept under consideration. The examples used go into a fair amount of detail in order to describe to the user all the aspects involved in the method or command being used. The concepts described are fairly complete, and would be sufficient for the reader to use immediately or with just a little bit of fine tuning. In terms of breadth, the book covers most of the features of shell scripting while also describing the various facilities the shell provides access to in a Unix-like environment. Thus, the book does not disappoint in this front either.In summary...In summary, probably the only thing I'd have liked to see more of is some emphasis on how to write more efficient shell scripts. Granted, most of the shell scripts described in the book are very simple and succinct, but a some words on how loops can be made better, or how to spot situations where pipes are not needed to solve a problem etc. might have been a nice addition. Some explanation of differences with dash, tcsh, zsh etc. might also have been nice, since a lot of users have different default shells. But all this isn't going to prevent me from giving this book a high rating, since it delivers quite well on the promises it makes at the beginning.This is definitely a good book to have near your desk, and kudos to the author for having taken the effort to put it together. I would highly recommend it to the beginner and occasional shell user for a thorough read, and to an intermediate to have on his/her desk for borrowing the cool scripting ideas and applications the author has written in this book.

The Abel prize for 2011 has been awarded to John Willard Milnor.[1] In response to a query from Dr. R. Ramachandran who writes about Science and Science Policy for The Hindu'' newspaper group, I wrote the following short piece which others may find interesting as well. Milnor is well-known for his work on topology and geometry. He has also made significant contributions to algebra and even number theory. In addition, he has written a number of books which are loved by graduate students in Mathematics all over the world. One of the striking early results of Milnor was the example he gave of a seven dimensional space which is topologically a sphere but its geometric (differentiable) structure is different. This was the first example of an "exotic sphere". A nice way to state his main result (due to Ajit Sanzgiri) is that "Groups of homotopy spheres are homotopy groups of spheres". Milnor received the Fields' Medal in 1962. In addition, the work of a number of later Fields' medallists such as Donaldson, Thurston, Mori and Voevodsky can be seen as having roots in the work of Milnor.

---

[1]The last time I wrote about the Abel Prize was to contribute to a guest post to Rahul Basu's science blog: The Far Side. Unfortunately, Rahul is no longer among us. This post is dedicated to the memory of Rahul Basu.

Yesterday I was hinted towards lxc when I wondered what happened to openvz in unstable (which unfortunately isn't documented at all in the kernel changelogs, but that's a different story). So I started off taking a look. From a bit of experimenting around with it I consider it something that I want to play more with, and I want to share the problems I stumbled upon with you so that you don't have to figure them out on your own. First of all, LXC uses the cgroup kernel facility for resource management. The according file system isn't mounted by default, and LXC doesn't care for where it is mounted, it just needs to be. It seems like /sys/fs/cgroup seems to be the proper place (see 601757), so add the line cgroup /sys/fs/cgroup cgroup defaults 0 0 to your /etc/fstab file and sudo mount cgroup it. Next, it seems like bridging is the defacto standard for networking with lxc, but given that I want to use it on my notebook while being mobile I can't bind the bridge to any specific interface. To make this happen, one needs the bridge-utils package installed, and secondly, this is the path that I chose. I've added to /etc/network/interfaces this snippet:

auto br0
iface br0 inet static
    bridge_maxwait 0
    bridge_ports dummy0
    address 10.80.80.1
    netmask 255.255.255.0

This will bring up the bridge and act as gateway. For the running system, call sudo ifup br0. To make the host universally being able to work as gateway, of course ip_forward needs to be enabled. For this I added the line net.ipv4.ip_forward=1 to /etc/sysctl.d/local.conf (and for the running system, echo 1 into /proc/sys/net/ipv4/ip_forward). As I am using ferm for configuring the firewall on my notebook I have to add some parts into its configuration. This is the raw part that needs to get added, mix it into your existing configuration:

table filter  
    chain INPUT  
        # allow DNS queries from LXContainers
        proto (udp tcp) dport domain source 10.80.80.0/24 ACCEPT;
     
    chain FORWARD  
        # allow LXContainers into the net
        source 10.80.80.0/24 ACCEPT;
     
 
table nat  
    chain POSTROUTING  
        # NAT LXContainers
        source 10.80.80.0/24 MASQUERADE;
     
 

For DNS I installed dnsmasq so that I won't have to touch the /etc/resolv.conf inside the containers whenever I switch networks. So far for the host part, now to the actual containers. There is the /usr/lib/lxc/templates/lxc-debian helper script which uses debootstrap to create you a lenny chroot at least in the squeeze package this is hardwired, likewise with using cdn.debian.net. Copy the script and edit it to your likes if you feel like it. From what I understood it expects you to store the containers below /var/lib/lxc, I haven't yet tested for different places. So this was my commandline for that:
sudo /usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/vm0 A while later you'll end up below that directory with two entries: The config file and the rootfs subdirectory which is actually the bootstrapped distribution part. Now comes the configuration of the container. Open the config file with your favorite editor and add the following lines to the end:

lxc.utsname = vm0
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
# lxc.network.name = eth0
lxc.network.hwaddr = 00:FF:80:80:80:80
lxc.network.ipv4 = 10.80.80.80/24

The network.name part is commented out, it defaults to that name internally; you though can change it to whatever you prefer. Caution, even though this is the documented approach, it does not work for Debian containers. It will always try to get its IP address through dhcp, lxc.network.ipv4 has no meaning for us. We need to change inside the rootfs the file etc/network/interfaces to read like this instead:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
   address 10.80.80.80
   netmask 255.255.255.0
   gateway 10.80.80.1

I suggest to keep the config and the interfaces file aligned with respect to the ipv4 setting so if this gets fixed upstream you won't stumble into any surprises. Also like mentioned before, we need to change the nameserver entries inside the rootfs file etc/resolv.conf to read nameserver 10.80.80.1. Now it's time to start it up and log in! sudo lxc-start -n vm0 -d will start the container in the background, and sudo lxc-console -n vm0 will give you the login to the container. The default password for the root user is root, obviously you want to change that before you install any networking services into the container like ssh-server. In case you want to quit from that console notice the message upon starting it, it's bound to <Ctrl+a q>. One more issue that I had: The default route wasn't set. I had to manually call ip r a default via 10.80.80.1 dev eth0 to be able to use the network inside the container. It seems to be related to that netbase isn't installed by default. If you install it the default route will be set upon starting the container automatically. This should get you started, there is of course more to explore and experiment with. Actually it is also suggested to create a tarball from your vm0 after you did the basic setup and installed the basic components you want to have around so you won't have to bootstrap over and over again. Do this after you have shut down the container, either through a halt from a container shell or through sudo lxc-stop -n vm0. The tarball can then get extracted to a different directory and just needs minor tweaks in the config and rootfs/etc/network/interfaces file to not create any clash with other containers (lxc.rootfs, lxc.mount.entry, lxc.utsname, lxc.network.hwaddr and ipv4 address). About limiting the containers, you can do it dynamically through the cgroup file system, and set it permanently through the config file. See man lxc.conf about these settings, amongst others. Enjoy, use, experiment. With sudo lxc-checkconfig you will see what your kernel actually supports for your LXCs. You will most probably notice the missing for the memory controller, this is tracked in the Debian bug report 534964.

/debian permanent link Comments: 6 Flattr this

...and me. I turned 40 today and on such a momentous occasion I should pause
to take stock of my life. Executive summary: it's not bad at all. Last week I completed 13 years of marriage to Jyoti who loves me and always
looks out for my best interest even during the times when I do not. I have two lovely children who are kind, intelligent, Dharmic, and (mostly :-)
well behaved. Of course I can't forget all my dear friends and family who gave me their
blessings and good wishes today and indeed every day. My health is better now than it was in my twenties. Since last year I've been
exercising on the treadmill regularly and taken a lot of junk out of my diet.
I've lost about two stones and while I won't be joining the Debian marathon
runners just yet, I can at least jog briskly without collapsing in a puddle of
sweat, heart palpitations and shame. Mentally, I've been taking college level courses in Maths in an effort to
relearn the things I didn't pay proper attention to the first time I was in
college. I completed National Novel Writing Month for the first time with a
60,000 word philosophical science fiction blockbuster that other people might
actually consider readable once I finish revising it. And I am still training
for the day when I shall be granted the spot on Jeopardy which is rightfully
mine. Financially, the last few years have not been good for many people but we are
holding our heads above water and even slowly moving forwards. This is the
year Consolidated Braincells Inc. my little corporate empire will take off I
hope. As I begin preparing for Chaitra Navaratri I feel it will be extra special
this year because all these good things that are happening to me are solely
due to Her grace and krpa. Last thing I wanted to mention is that a present I gave myself today was to
make a donation to the Red Cross to help the victims of the tsunami in Japan.
If you have had good fortune in your life and have not already done so won't
you consider doing the same? (or to any of the other reputable charities
engaged in disaster relief.) Our shastras say that dana is the best insurance
against accidental sins and the guarantor of good luck.

Ok, so finally it is official! We just had the DebConf 12 decision meeting. We saw two great proposals, from the cities of Belo Horizonte, Brazil and Managua, Nicaragua. If you are curious on the decision process: We held it over two IRC channels The moderated #debconf-team channel, where only the five members of the decision committee (Marga Manterola, Andrew McMillan, Jeremiah Foster, Holger Levsen, Moray Allan) and two members from each of the bids (Marco T lio Gontijo e Silva and Rafael Cunha de Almeida from Brazil; Leonardo G mez and Eduardo Rosales from Nicaragua) had voices, and the open #dc12-discuss channel where we had an open discussion. Of course, you can get the full conversation logs in those links. I have to thank and congratulate the Brazilian team as they did a great work... The decision was very tight. It was so tight, in fact, that towards the end of the winning all of the committee members were too shy to state the results - so I kidnapped the process by announcing the winner ;-) (I hope that does not cast a shadow of illegitimacy over it) And, very much worth noting, both teams were also very professional: In previous years, we have seen such decisions degenerate into personal attacks and very ugly situations. That has always been painful and unfortunate. And although the Brazilians will not be able to go celebrate tonight, the decision was received with civility, knowing it was a decision among equals, and a decision well carried out. Well, that's it I am very much looking forward for that peculiar two weeks when the whole Debian family meets, this year to be held in Banja Luka, Bosnia-Herzegovina, and I am very eager towards meeting in 2012 in Managua, Nicaragua! Yay!

A while ago I received a new desktop machine (8 cores, 8Gb of memory ...) at work. Since for the moment I kinda happy to work on my laptop using an external screen, I decided to put the hw to a good use and to explore a bit more some more exotic (at least for me) xen features. In particular I spend half a day playing with different xen network settings. The bridge model, that should work out of the shelf, is the easiest one. To setup this up, you basically need to specify a couple of options in the xend-config file and you're done. This is the "default" network configuration and is should work out of the box in most situations. Using this method, since all VMs' interfaces are bridged together (surprise !) with the public interface, your network card is left in promiscuous mode (not a big problem if you ask me...). Once your VMs are up, you can then decided to use your default dhcp server, autoconf your VMs with ipv6 only, or do nothing as you please. An other popular method, albeit a bit more complex, is to setup a natted network using the script network-nat (this one is an evolution of the third method that is 'network-routed') . I played with it, but since I wanted to have all my DomU on the same subnet, this setup wasn't satisfying for me. In particular, by default, 'network-nat' assigns a different subnet to each DomU. Using the natted set up you can also configure a local dhcp server to give private IPs to your VMs all done transparently by the xen network scripts. I've noticed that there is a bug in the xen script that does not make it very squeeze friendly. Since the default dhcp server in squeeze is isc-dhcp and few configuration files got shuffled in the process (notably /etc/dhcp3.conf is not /etc/dhcp/dhcp.conf) , the script needs a little fix to work properly. I'll report this bug sometimes soon... Goggling around I found a different setup that is called brouter, that is a hybrid between a bridge configuration and a routed configuration. This is the original (??) article well hidden in an old suse wiki.

I've done few modifications here to add natting. So basically, all virtual interfaces connected each to one DomU are linked together by a bridge (xenbr0). The bridge with address 10.0.0.1 is also the router of the subnet. All DomU are configured to used dhcp that assigns a new ip and specifies the router of the subnet. The dhcp server is configured to answer requests only on the xenb0 interface avoiding problems on the public network... routing is configured using iptables : Note that since the dhcp server is configured to give addresses only on the virtual network, we need to restart it after creating the bridge interface, otherwise isc-dhcp-server will refuse to run. Mum says that I should configure the bridge in /etc/network/interfaces to make the dhcp server happy at startup, but I felt a bit lazy, so I let to task to xen... In the next episode, I'll add ipv6 connectivity to the virtual subnet and then start playing with puppet... ipv6 is almost done, puppet... I started with the doc... The complete script from the suse wiki and with my modifications is below (only lightly tested):

On Sunday the annual March Madness Half Marathon in Cary took place, which (at least informally) opens the running season in greater Chicago. Following my participation in 2005. 2006, 2007, 2008, 2009). and 2010, I kept that streak going. Weather was pretty bad: A forecast of rain materialized with a shower at the start, another at about the halfway mark and a more solid downpour at the end, while temperature where in the lower 40s. And as I train less than I used to, I was also few just a few second slower than last year at 1:39:55 (hand-stopped) but managed to sneak in just under 100 minutes (and having taken six seconds to the starting lime, the official non-chip time has me just over that mark). All-in-all another nice half-marathon and I was appropriately sore yesterday.

Debian CD/DVD ISO images are huge files (4.7 GB for a DVD). It can take a long time to download if your connection with the server is not very fast. Jigdo can help you download them much more quickly if you have a high-speed connection to a normal Debian mirror. If your download rate from your usual Debian mirror is not better than the download rate from the closest Debian CD mirror, then you should download your images straight from the Debian CD mirror. Otherwise read on and learn how you can save lots of time. Jigdo is based on a simple idea: the CD images contain mainly thousands of .deb files (and source files too) that are already available on all Debian mirrors. So instead of downloading the ISO image in its entirety, you could reconstruct it with all the files that it contains, that you would download from your usual Debian mirror. Thus when you download a .jigdo file, you only download a little text file (compressed with gzip) that contains enough information to reconstruct the complete image:

• it contains a list of the individual files that are needed to rebuild the image;
• it indicates a mirror where those files can be downloaded (it s mainly a fallback URL in case our preferred mirror doesn t have them anymore);
• it contains an URL to a .template file which describes the layout of all files within the ISO image. It also contains the data which can t be downloaded from the mirror.

The tool that we will use to regenerate the ISO images is called jigdo-lite, it s available on Windows if you don t have any Debian system yet. Otherwise just install the jigdo-file Debian package. We just need the URL of a .jigdo file (get one from the Debian CD page) and we pass it to jidgo-lite on the command line. It asks for a path of Files to scan : if we have an older version of the same CD image, we can indicate a path where it is mounted and it will avoid redownloading the files that we already have, otherwise just press Enter. Then it asks for the Debian mirror to use and by default suggests the one used in /etc/apt/sources.list. Again pressing Enter is usually enough. You can even use --noask to avoid the prompts.

$ jigdo-lite http://cdimage.debian.org/cdimage/release/6.0.1/multi-arch/jigdo-dvd/debian-6.0.1-i386-amd64-source-DVD-1.jigdo
Jigsaw Download "lite"
Copyright (C) 2001-2005     jigdo@
Richard Atterer             atterer.net
Getting mirror information from /etc/apt/sources.list
Downloading .jigdo file
--2011-03-22 09:08:11--  http://[2001:6b0:e:2018::163]/cdimage/release/6.0.1/multi-arch/jigdo-dvd/debian-6.0.1-i386-amd64-source-DVD-1.jigdo
[...]
-----------------------------------------------------------------
Images offered by  http://cdimage.debian.org/cdimage/release/6.0.1/multi-arch/jigdo-dvd/debian-6.0.1-i386-amd64-source-DVD-1.jigdo':
  1: 'Debian GNU/Linux 6.0.1 "Squeeze" - Official Multi-architecture i386/amd64/source DVD #1 20110319-14:55 (20110319)' (debian-6.0.1-i386-amd64-source-DVD-1.iso)
Further information about  debian-6.0.1-i386-amd64-source-DVD-1.iso':
Generated on Sat, 19 Mar 2011 15:11:27 +0000
-----------------------------------------------------------------
If you already have a previous version of the CD you are
downloading, jigdo can re-use files on the old CD that are also
present in the new image, and you do not need to download them
again. Mount the old CD ROM and enter the path it is mounted under
(e.g.  /mnt/cdrom').
Alternatively, just press enter if you want to start downloading
the remaining files.
Files to scan: 
-----------------------------------------------------------------
The jigdo file refers to files stored on Debian mirrors. Please
choose a Debian mirror as follows: Either enter a complete URL
pointing to a mirror (in the form
 ftp://ftp.debian.org/debian/'), or enter any regular expression
for searching through the list of mirrors: Try a two-letter
country code such as  de', or a country name like  United
States', or a server name like  sunsite'.
Debian mirror [http://ftp.fr.debian.org/debian]: 
Downloading .template file
--2011-03-22 09:12:41--  http://cdimage.debian.org/cdimage/release/6.0.1/multi-arch/jigdo-dvd/debian-6.0.1-i386-amd64-source-DVD-1.template
[...]
Successfully created  debian-6.0.1-i386-amd64-source-DVD-1.iso'
-----------------------------------------------------------------
Finished!
The fact that you got this far is a strong indication that  debian-6.0.1-i386-amd64-source-DVD-1.iso'
was generated correctly. I will perform an additional, final check,
which you can interrupt safely with Ctrl-C if you do not want to wait.
OK: Checksums match, image is good!

And you re done, you have successfully downloaded an official Debian DVD with jigdo-lite. You can head over to the Debian CD page and find out the URL of the .jigdo files for the latest stable release. One last thing, Bluray images are only available with Jigdo because they are so huge that keeping complete ISO images would be a waste of disk resources of the CD images server (and its mirrors). Of course, if downloading ISO images and burning CD/DVD is not for you, you can always order some professionally printed CD/DVD. You will even help Debian by doing this.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

6 comments Liked this article? Click here. My blog is Flattr-enabled.

I, and maybe some others, wondered why people would (have to) send new lenses back claiming that they got a bad copy so often. I couldn't imagine quality control being so bad that two out of three (at least that's the impression I got from reading the occasional foto discussion forum) lenses are bad. It turns out that it is not only people needing to be pampered and having the impression that their second (identical) copy of the expensive new lens is better. Nor is it bad QA by the manufacturers alone. Fact is that todays high megapixel cameras are at the limit of the manufacturing precision that can be achieved at a reasonable price. Roger Cicala (LensRentals.com, so he occasionally does have a lens or two at his place) wrote some very interesting articles about this topic which I discovered just now as they were featured on canonrumors (In case you're wondering: No, I don't see any issues with my new 70-200mm, just coincidence that I'm reading this just after getting a new lens. When I upgrade my camera body to something like a 5D MkII I will take a very close look at my Tokina 11-16 though, where I don't trust the AF 100%. On the 10MP Canon 40D it's a great lens, so I'm quite happy for now, but it seems strange that when I release and half-press the shutter again after having focused, the focus will sometimes move a tiny bit again. Haven't noticed this behaviour on the other lenses.)

I recently deployed my node.js proxy server, removing all traces of Apache2 from my main server. During the course of this transition I discovered:

Bugs in my code

Not unexpected, in all honesty. There were two main issues; the first was relating to how I handled the 304 response, the second was relating to how I performed rewrites for my mercurial repository vhost.

Bugs in node.js

Given how new node.js is there wasn't a huge surprise here either, although I thought I'd been good testing against 0.2.x. As it turned out I needed to run the more recent 0.4.x to avoid a couple of issues:

• HTTP headers are lower-cased
• ECONNREFUSED was not being caught the way that I expected.

In short I have a backported node.js package for Squeeze which is almost worthless. I'll update it in the near future. For the moment:

cd node-v0.4.3/
./configure --without-ssl --prefix=/opt/node-0.4.3 && make && make install
ln -fs /opt/node-0.4.3  /opt/node

Oddities in thttpd

thttpd is what actually runs my websites and I discovered during some extended debugging sessions that it just does not like HTTP requests starting with a doubled "/" character. For example this works fine:

wget http://www.acme.com/software/thttpd/

But this fails:

wget http://www.acme.com//software/thttpd/

Previously it seems that Apache was (silently) fixing this up before it proxied requests. Now I have to do it myself, no big thing, but still a surprise.

All in all it was worth it to be able to run:

dpkg --purge libapache2-mod-rpaf \
             apache2.2-common \
             apache2.2-bin \
             apache2-utils \
             apache2-mpm-prefork \
             apache2 \
             libaprutil1-dbd-sqlite3 \
             libaprutil1-ldap \
             libaprutil1 \
             libapr1

ObQuote: "Bad news. The fog's getting thicker." - Airplane!

The first two months of this year have seen me quite busy preparing for my March-April peak of activity. So, most of these were spent accumulating kilometers, mostly on trail runs with mud, slope, obstacles, etc.

• January: 240km, 21h17', 3000m positive slope
• February: 170km, 15h10', 1900m positive slope

January was meant to accumulate kilometers, which succeeded quite well..:-). Not as crazy as November 2010 (close to 300km) but the point was also testing a few long runs, over 25km and up to 32. February saw my first official race, with Bullion half-marathon. This is a nice race which I already ran last year. It features small roads in the Rambouillet Forest. Not the best place to achieve a personal best because the race is not flat, with two hills in the first half. Moreover, I was just recovering from a small flu, so I wasn't really planning to achieve a PB. Still, I managed to do it in 1h39'49", two minutes more than my PB. Moreover, I managed to do it in a small negative split, with first half in 50'38" and second half in 49'11". More encouraging, I ran a 35km solo trail the next week-end after this and completed it fairly well with the pace I plan for the 50km Eco-Trail. Still, that flu introduced some minor perturbation in this preparation and, thus, I included more activity in early March. I was originally planning to run Paris half-marathon on 6th, but an invitation for a friends 50th birthday made me cancel that one. So, most of the first 3 weeks of March were spent in 15-18km style runs, plus running daily to go to and back from work. The last preparation was today with a short 12km run with all equipment needed for Eco-Trail (backpack, 2lit. waterbag) and the targeted pace (10km/h). So, on Saturday, will be the Paris Eco-trail 50km race from Versailles Castle to Eiffel Tower....through woods in the South and South-West neighbourhood, with 1000m positive slope. This will be my first ultra race, so I'm a little bit in a grey area, here. As a consequence, the only ambition is finishing. I expect it to be in aroung 5h30 or so. Most importantly, I have to keep reserves, as, two weeks later, I'll run my yearly Paris marathon. Two long distance races in two weeks...we'll see if I'm crazy or not..:-) Now, I'm heading for a quiet week: grow glucides reserves, eat pasta, do one or two footings...and wait for Saturday! You may want to watch my blog on Sunday to see whether I survived this first stage.

A bit more than a month ago, I had the random idea to try building and selling a web site, at the same time. The idea was that the more people bid, and requested features, the more I'd work on it. It didn't work out. I got a bit of money out of it, but certainly not enough to cover my time at an hourly rate. I suppose the lesson is that a month simply isn't a lot of time for something to mature: it'd probably be best to work on something on and off for a year, give it some time for traffic to build up, and so on, if the goal is to sell it. However, in any case, I think I'm pretty convinced that my next projects, like LiberWriter, will involve for-pay products. At heart, I'm not really a business guy, so picking the simplest possible business model probably makes sense: you pay me, I give you something. Hopefully, I'll be able to write about those in the "you win some column", but I thought I'd let people know how the experiment went.

Quite probably, the best thing got for myself during the last year was my Kindle. I just love it! It has changed the way I interact with knowledge, and saved me from hours of boredom. But it has also taught me the value of scribbling along the book pages and of underlining passages. Yes, I hold a deep regard for my regular (paper) books, and I never scribble on them, not even on text books. In any case, I can scribble on a post-it or something like that. Still, when you underline or comment on a passage in the Kindle, what can you do with your annotation? Well, not much. Annotations (called clippings in Kindlespeak) are stored on an easily accessible My Clippings.txt text file, very easy to parse and work with. So, I devoted yesterday evening to coming up with a first prototype of an app that I think can be very useful if you use clippings extensively: It displays each clipping with its base information separately, allows you to filter on the specific book to which each clipping is related as well as on the clipping type. So, if it interests you, clone it away from github!

git://github.com/gwolf/kindleclip.git

Written in Ruby, Gtk (Glade). No further libraries are (currently?) needed. The code is far from beautiful, but is a first stab towards functionality. Any comments welcome!

A bit of history One of the greatest criticisms of Debian is that its release cycles are too long. Debian stable release is seen as often as Ubuntu s LTS release. As a server solution this doesn t present a problem at all, it can even seen as a pro. However, for desktop use and for your average Joe who needs to have the latest software and is unable to get it, this may well present a problem. Of course he can always turn to backports to get what he needs but by the time you have finished reading this very sentence, Joe has already moved to Ubuntu. For those who are completely unaware how things work within Debian, let me try to shed some light. Debian has 3 main branches:

• stable
• testing
• unstable

Unstable , is a branch used mainly by developers, where the latest changes to the software they are working on are made. Usually, after approximately 10 days this software is pushed to testing , branch which is going to become next Debian stable release. For comparison, in the process of a new Ubuntu release at one point in this process, changes from testing/unstable are frozen where Ubuntu fixes bugs until they are ready to release new Ubuntu release. Debian s testing branch is said by some to be more stable then most of the stable distributions out there. Last but not least is stable branch, which follows the (in)famous mantra it s released when it s ready , although last two releases have been released in a more timely manner. Okay, so what is Debian CUT? The idea stretches back more then 2 years, to Joey Hess proposing the idea of Constantly Usable Testing . For users/developers who can t wait ~2 years to see new Debian release, they usually turn to Debian testing branch. To clarify, testing images are released weekly, but most of us in Debian don t recommend you jump to testing by installing it from weekly image, but rather by upgrading from stable. To make the situation even worse, these builds frequently don t work due to all the changes that have been pushed from unstable. But this is where Constantly Usable Testing idea comes in, where the installer is always installable and you re already using what s going to be next stable release. You wouldn t have to worry about whether the next update is going to break your system, but would get regular security updates, while the big updates would come in shape of new testing snapshot versions. Frequency of release of these snapshots is ought to be on monthly basis, so you can plan on seeing the next release on April 6th (exactly one month after the current release, provided of course if there are no showstopper bugs). To sum it all up, you wouldn t have to wait ~2 years before new Stable release shows up, nor (in case you have already switched to testing) would you have to worry whether your next update will break your system. You would get your updates in form of timely (ie: monthly) snapshots until it s time for major milestone which would turn out to be new Debian release. Even though this might be long term goal, in these early stages no one can guarantees this. Rolling release? The simplest way to explain this concept is that there are two types of Linux distributions: one with milestone version numbers and other where new updates keep coming through their rolling release cycles. Some of the rolling distributions are Gentoo and Arch Linux, while on the other side you have RedHat and Suse. Novell announced that OpenSuse is moving to rolling release with project codename Tumbleweed. It s also worth mentioning that Debian already has its rolling counters and perfect examples are: LMDE and aptosid. It is a way to continuously develop software, a way that best fits Debian as a platform where software is continuously developed. Especially because most of its greatest values could get lost with the release of that big stable version . Perfect case of that could be the almost drop of Chromium in Squeeze. Another great example could be Android, which is criticised most for its versioning. Companies are refusing to release new Android versions to their current phones, because they want you to buy new phone with latest Android version, even though your current one is perfectly capable of running latest Android. Personally, I m sure the future will reveal that rolling releases are the future, towards which all Linux platforms should be heading. Perhaps the definition of rolling releases I gave earlier is why I believe this project has such bright future ahead of it. Debian would be somewhat of a hybrid of this definition, it would be rolling release until it s time to mark a big milestone with a version number, and before you know it, we re rolling again. Unofficial Debian Monthly Testing Snapshot Release (version 2011.03 final) Michael Gilbert took on a big responsibility, trying experimentally to prove the feasibility of such a project. He has released a first wheezy snapshot installer (versioned 2011.03) as a test for the development community to try out and evaluate. Please read official announcement along with download links. While you can use this snapshot to have constantly working installer, after it is installed you could move to testing altogether if you wish. Conclusion As I have already mentioned, this project is still in the development/experimental stage, which makes all of this its very conception. Also, apart from rumors of Ubuntu becoming rolling release, if Ubuntu is to get its rolling release this how it s going to get it If you d like to find out more about Debian CUT, I suggest you read Raphael Hertzog s article A constantly usable testing distribution for Debian , and watch the video of Joey Hess CUT BoF on DebConf10 in NYC. Of course, if you d like to get involved into this project, please use the project s mailing list. If you have any comments, please do share, as I d be happy to answer any of your questions.

This is probably an idea obvious to everyone, and probably someone's already implemented this, but just in case they haven't, I'll throw this idea out there for someone to hack on. QR codes are two-dimensional bar codes. You can take arbitrary data and encode it into a barcode, which you can then print out. Later, you can scan it in and decode the barcode, and get the original data back. Given that printed paper is fairly durable and unlikely to go suddenly bad, like hard disks do, this can be used for backups. I did a quick experiment. I put 2000 bytes per barcode and printed it out in various sizes: 10, 20, 30, and 70 mm squares. Then I scanned them in. The 70 mm one was the only one that could be decoded, the others were too small and smudged. It should be possible to fit 12 squares of just under 70 mm on an A4 sized page. That's 24000 bytes of raw data. What could you fit in that space? Or several pages of that? It's not dense enough for storing large amounts of data (images, audio, video), but there's a number of important things that are not so large. Perhaps secret keys, or your Revelation keyring file? For ease of use, it would be good to have a tool to take arbitrary binary data, compress it if possible, divide it into chunks of suitable size, number each chunk, and output a PDF with all the QR codes laid out optimally, ready for printing.

I've just been told, that the video of the Linux New Media Award Ceremony (you might remember that Debian won in two categories) is now available online. Update: To watch that video without a proprietary plugin, you can download the video and watch with xine or some other free media player. Thanks to Rhonda for the hint! My (German) interview with RadioTux is also available online.