Welcome to Whipper

It seems that we have a new member of the family. Whipper joined us today. Our new car! We have finally mini-sized our car portfolio, two for one. I hope she will enjoy playing with us :)

Karmic Kernel jumps to 2.6.31

So the 2.6.31 merge window has slammed shut, 2.6.31-rc1 has been tagged and released, and now the fun begins. I have just finished the job of rolling the Ubuntu kernel delta forward to the new kernel. So far my testing has been pretty positive for an -rc1 release:

$ cat /proc/version_signature
Ubuntu 2.6.31-1.13-generic

Now all I have to do is get the thing into the archive, expect this kernel shortly on a Karmic install near you. Be warned that KMS is enabled for both Intel and ATI radeon so if you have issues with X you might want to turn it off with i195.modeset=0 or radeon.modeset=0 as appropriate.

Meet your Upstream

Our desire to work with our upstream counterparts to bring new goodness to Ubuntu is often tempered by the sheer volume of change we are trying to bring to Ubuntu in a particular cycle. It is easy to focus on that work and forget that upstream is out there, and often better equiped to solve issues or provide advice. I have recently managed, indeed in places been forced by circumstance, to interact with upstream very directly on a couple of projects close to my heart, Kernel Mode Setting (KMS) and VFS union-mount.

At the recent UDS we had the opportunity to mix with a number of upstream developers, some involved in Ubuntu others simply invited for their insight into various subsystems. For me this was particularly relevant as the nominated KMS 'expert' on the Ubuntu kernel team! I was able to spend a number of hours discussing plans with these guys and getting to know them. Out of those discussions came plans to produce bleeding edge kernels containing updated Intel, ATI Radeon, and even Nouveau drivers for those brave enough to give them a spin. This has been hugly beneficial for us, getting testing on these code bases and allowing the userspace guys to get work out the kinks before we release KMS enabled kernels, so that when we do the general experience should be much better much earlier in the cycle. Win all round.

Elsewhere I have been involved in investigations into what we are planning to use as our union mount solution for Karmic. Upstream seems to be leaning towards a VFS based approach, VFS union-mount. We have been trialing these patches putting together test kernels to allow stress testing. Again providing vital early testing feedback to the maintainers and helping to improve the quality and increase confidence in the code. Again win.

Moving my work closer to the developers, often into their lap, is working well for me at least. No I am more involved with them I find them in their turn easier to deal with and generally more friendly. My advice, get out there and meet your upstream find out where their lap is and make yourself comfy.

Karmic Kernel Version

At the Ubuntu Developer Summit we had a session on the likely kernel version for the Ubuntu Karmic release. The decision at the session was that we would be aiming for a v2.6.31 based kernel for Karmic. This was based in large part on release timing, we are expecting this kernel to be released around three weeks before our beta freeze which gives us a fair amount of time to stabalise the kernel before the final release.

What goodness can we expect from the Karmic kernel. We are obviously expecting Intel support for Kernel Mode Setting (KMS) to be stable and enabled. We have some hope of seeing ATI Radeon KMS for at least some cards, indeed the first cut of this support has just been merged. We can expect some good improvements in the Intel graphics drivers as a whole. We also get some new in kernel compression LZMA which might allow smaller kernels and initramfs files saving a bit of space on the CDs. There is a pile of DVB updates merged already . Overall there is nearly 20k changes in already and the merge window is still open. Even staging drivers are getting some love.

Series specific mainline builds

I have been having requests to enable Kernel Mode Setting (KMS) in the latest mainline kernel builds so they can be used for testing on Karmic. The problem is that the primary consumer for these mainline builds is for testing on older series, mainly Jaunty, and that does not want KMS to be enabled. While the official kernel for Karmic should be very close to the mainline builds, kept up to date approximately weekly, it certainly is not a crack-of-the-day kernel for the development release.

It seems likely we need to be building these kernels both against the current stable kernel, and against the kernel configurations for the current development release. Likely that means we should be naming all the builds by the release for which they are targeted. More upheaval.

Hamster Wheels

Ever wondered just how much time you are spending on things at work? Constantly forgetting what you are working on, finishing the week with no idea what you contributed? Certainly that is my experience. I have been looking for some tool which would quietly remind me to record what I was doing. I think I might just have found it. Hamster.


The hamster applet sits quietly on my gnome menubar, showing what I am working on and how long I have been at it. A quick click and I can change activity. Once you have your tasks recorded you can then categorise them. For example I am interested in how much of my time is spent on Development tasks and how much on Maintenance. Needless to say it produces pretty bar charts for review. Overall an interesting app.

LZMA Compression for the Linux Kernel

With the release of the 2.6.30 kernel we now have native support for Lempel-Ziv-Markov chain algorithm (LZMA) compression. This offers something like a 30% improvement in compressed size over GZIP compression (used for kernel image and initramfs compression). The downside is that decompressing LZMA data uses around twice as much CPU as compared to GZIP. Also compression is much slower than GZIP.

What does this mean for the kernel? Well for one it means it is not in the least bit obvious whether switching compression of the kernel and initramfs to this new compression format is going to be beneficial on average. Yes they would be smaller, but they would also take more time to extract especially on slow hardware. The key metric is the overall time taken to load and extract this pair and that is not easy to measure. Obviously we want to enable support for this new compression format, but making a change to that format will take more research and quantative comparisons.