Gnome Desktop -- Terminal icon wars

I have recently switched my default desktop environment to Ubuntu Gnome as part of our ongoing dogfooding program.  First impressions are good.  As always different is confusing and I keep hitting buttons that used to do one thing and get another; 5 years with one desktop will do that to a man.

As a consummate command-line junkie I really use my desktop environment to hold my terminal windows, lots of them.  It is really important my desktop environment will sensibly collate them; sensibly to me.  I use a lot of command line tools for email, IRC etc.  Those are necessarily hosted in terminal windows but not semantically terminal windows.  I want them to be grouped together away from actual terminals and preferably they should have my preferred icons.

I am pleased to say I have been able to persuade Gnome of my predilections.  It has been a long and frustrating journey.  I have to thank Laney for his support in this endeavour, for answering interminable IRC questions and stopping me from sticking a fist through my screen.

Gnome Terminal

The default terminal application in Gnome is Terminal (gnome-terminal to me).  This has lots of nice sounding options which ought to let me have the control I want.  It supports the --class option to set the window manager class.  In the X11 world this is meant to tell the window manager the type of window this is and it is common to use that to group windows.  Great:

gnome-terminal --class weechat -- weechat

Of course nothing is ever simple.  gnome-terminal is now smart, starting a server which spawns new windows for you thus defeating the window manager class option.  After some playing and a lot of whining at people further down the road they pointed me to the --app-id option allowing me to separate instances by use case with a server for each.  After some work (and getting a bug fixed in the Ubuntu gnome-terminal wrapper) I was able to use those two in combination:

gnome-terminal --app-id com.example.Terminal.weechat \
    --class weechat -- weechat

Now my windows are separated and grouped in the alt-TAB popup.  Sadly they are all called gnome-terminal.

Gnome Dash

In order to distinguish the various otherwise visually identical Terminal icons with their associated terminal windows I wish to have specific icons for each group.  Icons are determined by the .desktop file for the application.  So first we have to create one for each class:

[Desktop Entry]
Encoding=UTF-8
Name=my-weechat
Comment=Chat with other people using Internet Relay Chat
Exec=gnome-terminal --app-id org.shadowen.Terminal.my-weechat --class my-weechat --hide-menubar --title Weechat
Icon=weechat
Terminal=false
Type=Application

Note that you want the Name= attribute to be unique in space and time otherwise it will associate your windows with another application (likely with the same icon) but not with your command and generally make your head hurt.  This had me going for an hour as one of my groups was fine (the name happened to be unique) and the other not.

This file tells the launcher which icon to associate with this application.  You need to drop that into your personal applications directory ($HOME/.local/share/applications) for Gnome to know about it.  Now you can start this new application from the overview search box.  You can also drag that icon from the searcher to the Gnome Dash to have it clickable.  Nice.  Now I have my windows grouped on alt-TAB with the specified name underneath and the appropriate icon.  Win!

This seemed to work for a while, until it stopped working and they all went back to being named gnome-terminal and using the original Terminal icon in alt-TAB.  Arrgggh.

Startup Notification Protocol

After much reading around the subject it seems I was hitting a race so that the Gnome Launcher was having to guess which window was associated with the applications it knew.  As these are all Terminal windows Gnome felt at liberty to associate them with that application even though it did correctly group them by class.  This happens as launching an application is a fire-and-forget process and finding the windows which were spawned by the started application rather than something that happened to start around that time is hard.  To sort this out there is a protocol which allows the newly started application to communicate with the window-manager to tell it that this window is that application.  In Gnome these are defined using the StartupNotify= and StartupWMClass= attributes:

StartupNotify=true
StartupWMClass=my-weechat

With these set to match the class used by gnome-terminal the Gnome Launcher was able to reliably associate the new windows with the appropriate icon but in the Gnome Dash and in the alt-TAB window.

Complete Example

Here is the final complete desktop entry:

[Desktop Entry]
Encoding=UTF-8
Name=my-weechat
Comment=Chat with other people using Internet Relay Chat
Exec=gnome-terminal --app-id org.shadowen.Terminal.my-weechat --class my-weechat --hide-menubar --title Weechat
Icon=weechat
Terminal=false
Type=Application
StartupNotify=true
StartupWMClass=my-weechat

Result 

Finally I have windows grouped under the appropriate icons every time.  Nice.

Living with a Ubiquiti EdgeRouter Lite-3

I have been using an old Dell Mini 9 as firewall, ipv6 tunnel, and file server for my local networks, for some years.  Fear of that just melting into a heap of slag was starting to keep me up at night, time for it to be put out to pasture.  This also seemed like a good time to spend a little money and split out the functions sanely.

After a lot of research I ended up purchasing a Ubiquiti EdgeRouter Lite-3 with a view to using it as my boundary router, and ipv6 tunnel end-point.  All the documentation implied that this little device would handle all of the pieces I need, DHCP, Hurricane Electric IPv6 tunnels, VLANs, firewalls etc. All that and it was sub 100 GBP delivered to my house.  Well worth a punt.  So I ordered one, and waited impatiently for it to arrive.  Once it arrived I put it on the shelf planning on playing with it "this" evening, needless to say the box sat on the shelf for a couple of months, ooops.

Finally, this weekend I got round to pulling it out and booting it up.  It is nice small package installed, silent of course and it seems to perform admirably.  Using the web interface I was quickly able to assign the various interfaces to the appropriate networks, add the VLAN interfaces I needed, and put down basic addresses on them.  Not bad for an hour of fiddling.

When I went to sort out my fairly complicated firewalling requirements things got a bit trickier.  After some googling I found the simplest approach was to use Zone based firewalling, but this form is not supported by the web interface.  Time to break out a bigger hammer and get to know the configuration CLI.

The configuration CLI turned out to be very simple to use, and pretty intuitive.  I am sure it is instantly recognisable to those of you who have to incant at cisco style routers.  You update the configuration in "configure" mode and you then "commit" to test the changes, and "save" to make the changes persistent across reboots.  A handy split for when you firewall yourself away from the configuration interfaces!  After another couple of hours of googling and hacking at my rules I had the IPv4 side of things setup as I wanted and working pretty well.

I still need to setup the DHCP servers, and IPv6 side of my world, but good progress and so far a pretty nice experience.

Booting ARM64 Ubuntu Core Images (on the Foundation Model)

For a while now we have been hearing about the new arm64 machines coming
from ARM licencees.  New machines are always interesting, new architectures
even more so.  For me this one is particularly interesting as is seems to
offer such a much higher bang for power consume ratio than we are used to,
and that can only bring down hosted server prices.  Cheap is something
we can all relate to.

There has been some awsome work going on in both Debian and Ubuntu to
bring up this new architecture as official ports.  In the Ubuntu Saucy
Salamander development cycle we started to see arm64 builds, and with
the release of Ubuntu 13.10 there was a new Ubuntu Core image for arm64.

This is awsome (to geeks at least), even if right now it is almost
impossible to actually get anything which can boot it.  Luckily for us ARM
offers a "Foundation Model" for this new processor.  This is essentially an
emulator akin to qemu which can run arm64 binary code on your amd64 machine,
allbeit rather slowly.

As one of the Ubuntu Kernel Engineers, the release of the Ubuntu Core image
for arm64 signalled time for there to be an official Ubuntu Kernel for
the arm64 architecture.  This would allow us to start booting and testing
these images.  Obviously as there is no actual hardware available for
the general public, it seemed appropriate that the first Ubuntu Kernel
would target the Foundation Model.  These kernel are now prototyped,
and the first image published into the archive.

As part of this work, indeed to allow validation of my new kernel, I was
forced to work out how to plumb these kernels into the Ubuntu Core image
and boot them using the Foundation Model from ARM.  Having done the work
I have documented this in the Ubuntu WIKI.

If such things exite you and you are interested in detailed instructions
check out the Ubuntu WIKI:

    http://wiki.ubuntu.com/ARM64/FoundationModel

Have fun!

BT Fail (or "I have never been so angry")

For those of you who do not have to hear me whine on a day to day basis about, well frankly, everything, you will not be aware that I have been waiting for broadband to be connected to my new house.  Today was the 5th week of waiting for this simple seeming task to be completed.  (Please don't make me even more angry by telling me how your US supplier pays you compensation every day it takes longer than ONE, I expect some level of suck from my UK service providers, else I would emigrate.)  Along the line I have had to have a huge hole made in my brand new house, and had to have countless engineers attend to try and supply my service.  Today should have been the end of this debackle, I should now have super fast Internet, I should be happy.

I am angry, so angry that it is unclear I have ever been more angry.  If my house was not so new I suspect that objects might have been thrown, hard.

Today was meant to be the third attempt to hook up my internet.  Today at 2pm I get a call:

"Hello we aren't coming today *beam*.
No sir, we don't know why, the system says 'Technical Problems'.
Someone will call you within 30 hours to tell you why, honest.
Sorry we do understand this isn't what you were hoping for."

Frankly you do not understand, you have no clue how I am feeling, so let me enlighten you.  My blood is boiling, if I had a heart condition you would likely have killed me.  I have had to go out for a walk to avoid breaking things.  I am now writing this in catharsis.

As I tried to explain to the caller, it is not so much that you are cancelling my slot, shit happens, people go sick, etc etc, it is that you have no idea why it went wrong and you won't know for 24 earth hours, that you cannot tell me why you are going to attend to actually complete the work.  This is utterly unacceptable.  Actually when I phoned your own helpdesk they seemed to be able to find out that "Your appointment was cancelled because we [BT] failed to confirm it with the suppliers".  The website says that "Your appointment was no longer needed because the engineer could enable your service from the exchange."  Who knows what is true.  Whatever is true, I do not have the promised service, I did not have an engineer attend despite confirming the appointment was scheduled on four separate occasions over four consecutive days including Monday this week, on some days by more than one person at BT actually calling the engineers to check.

BT you SUCK.  If Virgin (perhaps one day I will be calm enough to tell you how they suck) didn't suck harder you would have lost my business today.

IPv6 exceeds 1% of google search traffic (continuously)

In the ongoing march towards an IPv6 only Internet, IPv6 is not a speedy traveller but it did reach a mini-milestone this week.  Google reported that IPv6 traffic was greater than 1% of it's total traffic all week, on a regular ordinary week (well the week has the same basic shape as most non-holiday weeks).  Usage continues to edge higher and higher:

http://www.google.com/ipv6/statistics.html

Do I hear 2%?  (Probably not for a little while.)  Yes I know it is sad to be interested in this graph but hey, one has to be into something.

GPG key managment

As all good boys did, I (relatively) recently generated a nice shiny new GPG key, all 4096 bits of it.  I have switched everything over to this key and have been happy.  Today I was wondering whatever happened to the old key.  After some minutes trying to remember what the passphrase (oops) I finally managed to find and open the key.

Time it seems to revoke it so that I never have to worry about it again (and before I forget the passphrase for good).  Revoking a key essentially puts an end date on the key, it says any use of the key after this date is definitively invalid.  Luckily revoking a key (that you can remember the passphrase for) is relatively simple:

gpg --edit key
gpg> revoke
gpg> save
gpg --send-key

While I was at it I started to wonder about losing keys and how one guards against total loss of a key.  The received wisdom is to set an expiration date on your key.  These may be extended at any time, even after the key has technically expired, assuming you still have the private key.  If you do not then at least the key will automatically fall out of use when it expires.  Adding an expiry date to a key is also pretty simple:

gpg --edit-key
gpg> key 0
gpg> expire
...
Key is valid for? (0) 18m
gpg> key 1
gpg> expire
Changing expiration time for a subkey.
...
Key is valid for? (0) 12m
gpg> save
gpg --send-key

Note here I am setting the subkey (or keys, key 1 and higher) to expire in a year, and the main key to expire in 18 months.

At least now the keys I care about are protected and those I do not are put out of use.

HTML should be simple even with a javascript infection

Having been there in the simple days when a web server was a couple of hundred lines of code, and when HTML was a simple markup language pretty much only giving you hyperlinks and a bit of bold, I have always found javascript at best an abomination and certainly to be avoided in any personal project.

My hatred mostly stems from just how unclean the page source became when using lots of fancy javascript and how javascript dependant everything became as a result.  Turning javascript off just broke everything, basically meaning you had to have it enabled or not use the sites.  This is just wrong.

Recently I have been helping a friend to build their own website, a website which for reasons I find hard to understand could not be simple, with just links and bold, but really had to have popups, fading things, slides which move, all those things you really can only do easily and well in javascript.  Fooey.

Reluctantly embracing these goals I spent some time implementing various bits of javascript and ended up as predicted in some kind of maze of twisty passages all the same.  I was fulfilling my own nightmare.  Then something happened.  I accidentally discovered jquery.  Now jquery is no panacea at all, yes it does simplify the javascript you need to write so it is clearer and cleaner which is no bad thing.  The real jolt was the methodology espoused by the community there.   To write pages which work reasonably well with just HTML and CSS, and then during page load if and only if javascript is enabled rewrite the pages to add the necessary magic runes.  Now you can have nice maintainable HTML source files and still have fancy effects when available.

I have used this to great effect to do "twistable" sections.  When there is no javascript you get a plain document with all of the text displayed at page open.  If it is available then little buttons are injected into the sections to allow sections to be opened and closed on demand and the body is hidden by default.  All without any significant markup in the main HTML source, what little semantic markup there is has no effect:

<h2 class="twist-title">Section Title</h2>
<div class="twist-body">
Section Text
</div>

Now that is source you can be proud of.  Yes there is some site-wide jquery instantiations required here which I will avoid including in its full glory as it is rather messy.  But this example shows the concept:

$(function() {
        $(".twist-title").prepend("<span class=\"twist-plus\">+</span>
                <span class=\"twist-minus\">-</span> ")
        $(".twist-body").hide();
        $(".twist-title").click(function (event) {
                $(this).children('.twist-plus').toggle();
                $(this).children('.twist-minus').toggle();
                $(this).next().toggle();
        })
        $(".twist-title").css("cursor", "pointer");
});

Ok this is not so easy to understand, but the majority of the code, the HTML pages that the people who write the content have to look at is easy to understand.  I think you only agree this is a win all round.

IPv6 hits 1% of google search traffic

There has been much talk as to how IPv6 would only be credible when it reached 1% of overall traffic. Today we hit that milestone, at least for Google search traffic:

http://www.google.com/ipv6/statistics.html

Ok, it is not an overall number by any means but the upward trend is undeniable.  Awsome.

ARIN enters IPv4 exhaustion phase two

This week we saw another step towards IPv4 address exhaustion.  The American Registry for Internet Numbers (ARIN) reached 3.00 /8s of space remaining, this triggers phase two of its exhaustion planning.  This sees requests move to a first in first out model and overall criteria for allocations tightening.  Not exhaustion, but considering just how quickly addresses dissappeared this week (from 3.02 /8s to 2.89 /8s over night) we will be there soon enough.  For more details on what this really means:

https://www.arin.net/resources/request/countdown_phase2.html

RIPE IPv4 pool exhausted

September 14th 2012 was another big day for IPv6.  Today the RIPE Regional Address Registry (RAR) exhausted its IPv4 pool:

http://www.ripe.net/internet-coordination/news/ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8

This triggers section 5.6 of its IPv4 Address Allocation and Assignment Policies.  While these procedures do allow RIPE members to allocate IPv4 addresses still but only in very tiny allocations and only if they already have an IPv6 allocation.  In particular they are limited to a single allocation:

1a. LIRs may only receive one allocation from this /8.  The size of the allocation made under this policy will be exactly one /22.

With two of the five RARs now essentially out of IPv4 addresses this has to help spur on the adoption of IPv6.  One can hope.

IPv6 and dovecot

For my mail server I use dovecot.  By default this only binds its sockets in IPv4.  It is however trivial to enable binding of IPv6 as well.  Simply change the "listen = *" entry in its configuration (/etc/dovecot/dovecot.conf) as below:

listen="*, [::]" 

With that done and the service restarted my email if now available over IPv6 too.  This should become the default most likely.

IPv6 and weechat

With my bip proxy IPv6 enabled it is time to look at my IRC client.  I am a 'weechat' user so that is my target.  It seems that weechat has some support for IPv6 via its 'ipv6' option on the server configuration block.  You can set this option for connection 'freenode' as below:

/set irc.server.freenode.ipv6 yes

This certainly switches the connection over to IPv6, but it does not seem to fallback to IPv4 automatically.  Some additional support will be required to handle this, though the changes look minor.  I guess we can call this half enabled.

IPv6 dual-stack listeners?

As alluded to in my previous post "IPv6 and bip" when a service creates its network endpoint as an IPv6 socket it is actually able to  communicate with both IPv6 clients and IPv4 clients interchangeably.  But how does this work?

This compatibility mode is defined in one of the foundation Request For Comments (RFC) documents, specifically RFC3493 which defines how the socket() interfaces should behave with respect to IPv6 (see section 3.7 for the gory details).  This defines a reserved area of IPv6 address space which maps 1:1 to IPv4 addesses.  Essentially the IPv4 address may be translated into a unique reserved IPv6 address by concatenating the 0:0:0:0:0:FFFF prefix with the existing IPv4 address.  As this address is unique the underlying socket implementation can directly infer the correct physical protocol to use for this connection from the address alone, allowing connections to safely coexist.

The great thing about this compatibility mode is it works for any socket, server or client.  This allows an application to support only IPv6 and yet remain compatible with addresses of either type.  We no longer have to care which they are, nor does a service have to bind sockets to each protocol and handle the complexity that entails.  Magic.

IPv6 and bip

As a keen IPv6 advocate I have been playing around with the various applications and services I use on a regular basis and have been trying to enable IPv6 use; today it was my IRC proxy 'bip'.  bip turns out to be very simple to convert indeed.  Simply requesting bip bind on the IPv6 unspecified address (::) triggers it to switch to IPv6 and (through the magic of the Linux dual-stack IPv4 handling) this enables either IPv4 or IPv6 clients to connect to the proxy.

To change the default bind address in bip simply change the ip configuration in your .bip/.bip.conf to use the IPv6 unspecified address as below:

ip = "::";

As simple as that.  Probably the default behaviour of bip should be to bind :: (IPv6) and on failure bind 0.0.0.0 (IPv4).

Ubuntu Plus One

In the Precise development cycle a new archive oriented team was trialled, the Plus One team.  This team was created to help keep the archive in an installable and buildable state at all times, a major driver for early testing and for a solid LTS release.  The Plus One team is tasked with general house keeping for the Ubuntu archive. for finding issues such as build failures or packages which are no longer built from the source in the archive, and figuring out what to do with them.  They are also responsible for figuring out why our images are broken on any particular day and driving resolution.

This cycle when they were looking for volunteers for the team for the Quantal cycle I was put forward to help.  It sounded interesting as the work has a much broader base than my normal role, touching anything in the Ubuntu archive.  I have been working with Debian packages for over 4 years, but mostly kernel related packages and they have their own quirks. This gave me a chance to branch out and solidify my Ubuntu skills, a good stepping stone to becoming a core-dev in my own right.  An exciting and scary prospect.

I have been working on the Plus One team for a couple of weeks now, and all I can say is it has been a baptism of fire, have had to touch C++, C, python, ruby, perl (and more) often in the same package.  Had to fiddle with autoconf, and get familiar with the multitudinous patching schemes.  I have learned a healthy hatred for quilt (as it lets me lose my changes for the umpteenth time).  Test built untold packages; my poor test build server is crying out for a rest after the utter pounding I have given it.  For all this work we have made some progress indeed, but at this time in the cycle the breakage is building at least as fast as we club it into submission.  At times it is soul destroying.


Overall though it has been a very positive experience, I have learned a huge amount about the archive and packaging in the Ubuntu world, and gained a healthy dose of respect for anyone who voluntarily maintains other peoples packages.  All I can really say is a big thank you to those who look after this stuff full time, you are made of strong stuff indeed.

World IPv6 Launch Day -- 6th June 2012

The 6th of June 2012 is an interesting day, World IPv6 Launch Day.  On this day a swathe of influential web-sites will be enabling IPv6 addresses for their services by default and not turning them off.  Why is this interesting?  For the most part it is not! For most people nothing should happen, things should continue working probably using IPv4, fine.  For those of us with working IPv6 again nothing will change other than we will be producing more IPv6 traffic, great.  It is those who have unused broken IPv6 who will start having fun, they will likely lose connectivity to the participating sites until they sort out their issues.

So why is this a good thing?  This is a key step towards IPv6 adoption, and we really do not have any other choice but to adopt IPv6.  Adoption will only be driven by need, and this move creates exactly that need.  Such ISP and client issues need to be identified and solved, before the end users lose connectivity to even greater swathes of The Internet, those parts which only will exist on The IPv6 Internet.

For more information see: http://www.worldipv6launch.org/

IPv6 at home?

The Internet has been alive with doom saying since the IPv4 global address pool was parcelled out.  Now I do not subscribe to the view that the Internet is going to end imminently, but I do feel that if the technical people out there do not start playing with IPv6 soon then what hope is there for the masses?

In the UK getting native IPv6 is not a trivial task, only one ISP I can find seems to offer it and of course it is not the one I am with.  So what options do I have?  Well there are a number of different types of IPv4 tunnelling techniques such as 6to4 but these seem to require the ability to handle the transition on your NAT router, not an option here.  The other is a proper 6in4 tunnel to a tunnel broker but this needs an end-point.

As I have a local server that makes a sensible anchor for such a tunnel.  Talking round with those in the know I settled on getting a tunnel from Hurricane Electric (HE), a company which gives out tunnels to individuals for free and seems to have local presence for their tunnel hosts.  HE even supply you with tools to cope with your endpoint having a dynamic address, handy.  So with an HE tunnel configuration in hand I set about making my backup server into my IPv6 gateway.

First I had to ensure that protocol 41 (the tunnelling protocol) was being forwarded to the appropriate host.  This is a little tricky as this required me to talk to the configurator for my wireless router.  With that passed on to my server I was able to start configuring the tunnel.

Following the instructions on my HE tunnel broker page, a simple cut-n-paste into /etc/network/interfaces added the new tunnel network device, a quick ifup and my server started using IPv6.  Interestingly my apt-cacher-ng immediately switched backhaul of its incoming IPv4 requests to IPv6 no configuration needed.

Enabling IPv6 for the rest of the network was surprisingly easy.  I had to install and configure radv with my assigned prefix.  It also passed out information on the HE DNS servers, prioritising IPv6 in DNS lookup results.  No changes were required for any of the client systems; well other than enabling firewalls.  Win.

Overall IPv6 is still not simple as it is hard to obtain native IPv6 support, but if you can get it onto your network the client side is working very well indeed.

Oh no 3.0

After 39 2.6.x releases Linus Torvalds has chosen to revisit the upstream kernel version.  The plan is to release what would have been 2.6.40 instead as version 3.0:

"I decided to just bite the bullet, and call the next version 3.0. It
will get released close enough to the 20-year mark, which is excuse
enough for me, although honestly, the real reason is just that I can
no longe rcomfortably count as high as 40."

When 3.0-rc1 was released the Kernel Team had to decide what version to use for it in Ubuntu.  We typically upload every -rcN release within a couple of days of its release so the pressure was on.  We could simply call it 3.0.0 knowing that all the current scripting would cope, or as 3.0 better matching its official name knowing this would not be plain sailing.  This was not a decision we could delay as in Debian versioning 3.0 < 3.0.0 so we were likely to be committed for Oneiric if we uploaded using 3.0.0.  It is also not clear from upstream discussion what version number the final release will carry, as 3.0 clearly will cause breakage on older userspace.

After much discussion we decided we bite the bullet and upload a 3.0 kernel.  At least we get a chance  to identify problematic applications, while still keeping our options open to move to a 3.0.0 kernel for release should that be prudent.  As expected this was not smooth sailing, not least for the kernel packaging which needed much love to even correctly build this version.  Plus we had to hack the meta packages to allow that to be reversioned later too.

Once successfully uploaded the problem applications started to crawl out of the woodwork:

• depmod -- the depmod incantion to create the module dependancies identifies the kernel version in its command line but was assuming that a version contained three digits, this lead it to miss the version entirely and rebuild the wrong dependancies;
• libc6 -- both the runtime and the installation control scripts manipulate the kernel version number, in both cases assuming the version was three digits, enormous fun getting the pending updates installed;
• ps/top -- when starting the kernel version was checked, and miss decoded triggering a rather nasty sounding version warning whenever they are started;
• nfs-utils -- when attempting to read and identify the kernel version the nfs-utils would trigger a SIGSEGV and die, triggering boot failures on machines with NFS roots; and
• lm-sensors-3 -- this package is only compatible with 2.6.5 and above, failed version detection lead to this test failing and sensors being unconfigured.

Those are the ones we have found so far, I am sure there will be more.  If you do find one please file a bug against the failing package but tag it kernel-3.0 then we can find them.

Union File Systems (again)

During the early part of the Maverick cycle we once again revisited out Union Mount solution.  At that time VFS union-mounts was the hit of the day, set to finally to produce something which might get into the kernel.  Since then the complexity of changing every filesystem to support whiteouts, its invasiveness, and its affects on Posix semantics have lead to it falling by the wayside.  In its place has sprung overlayfs.

overlayfs is a small patch set which is a hybrid of the VFS union-mount approach and that of aufs/unionfs in that it also provides a filesystem.  This greatly reduces the complexity of the patch set, reducing its invasiveness and thus increasing its chances of ever being merged.  So much so simpler is it that your author is actually able to understand and debug it.  Win.

We have been tickling overlayfs for most of the Natty cycle, but with Natty in the can I have had had some time to catch up with its development and help out a little, both with testing and bug fixing.  Culminating today in my being able to inject a kernel containing overlayfs support into an Ubuntu LiveCD and boot it, then update it to the latest Natty, all without error.

overlayfs may shortly be in a mergable state, nirvana for all union mount lovers.  Only time and testing will tell.

Ubuntu Kernel Crack of the Day

We have been producing the mainline kernel crack of the day[1] for some time now.  But this targets the upstream kernel, and while great for testing and bug isolation it does not provide us with any pre-upload testing on the Ubuntu kernel delta.

Enter the pre-proposed kernel PPA[2].  We are now uploading the unreleased tips of the ubuntu kernel trees to this PPA.  These builds will contain any bug fixes marked Fix Committed and should provide a vehicle for advanced testing of these before they hit the archive.  For Maverick we will be uploading these automatically as the tree changes, roughly daily.  This should help us avoid the ThinkPad debackle we experienced late in Lucid.

I would encourage you to add this PPA to your sources and help us test this kernel before we unleash it on the world.

[1] https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[2] https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed/