So I’d like to point out that Canonical are Hiring! and we have many open positions listed on our Employment page.

If you’d like to work on open source software, for a fun company with some of the smartest people you’ll ever work with, or you know someone who would, don’t hesitate to check it out.

We are going to be doing the work to have btrfs as an installation option, and we have not ruled out making it the default.

I do stress the emphasis of that statement, a number of things would have to be true for us to take that decision:

1. btrfs would need to not be marked “experimental” in the kernel config; we understand that this is planned for 2.6.35, which is the kernel version we are expecting to ship in Maverick.
2. btrfs is not currently supported by GRUB2 (our boot loader) or the installer; these pieces would need to be finished before Feature Freeze.
3. If that happens, we may make it the default for Alpha releases to gain testing; that testing must go smoothly.
4. The btrfs upstream must be happy with the idea.
5. We must be happy with the idea.

It’s a tough gauntlet, and it would only made with the knowledge that production servers and desktops can be run on Lucid as a fully supported version of Ubuntu at the same time.  I’d give it a 1-in-5 chance.

As you know, improvements to the boot process has been something that Ubuntu have been working on for a few years now and this led to the development of Upstart.  We’re not the only ones working in this area, Intel have also been hard at work with different improvements of their own with the Moblin and MeeGo projects.

So it’s great to see some Fedora and OpenSuSE guys working on this too, and bringing some different ideas to the table!

I can’t say I disagree with some of Lennart’s observations about problems with Upstart, it’s certainly nowhere near perfect.  Now that the stable period leading up to the release of Ubuntu 10.04 LTS is over, I’m looking forwards to getting back into the code and trying to address them.

It’s far too early to tell which approach is going to work out better in the end; but that’s one of the great things about Linux.  The different distributions are able to develop in different directions, and we’re able to try out many different things.

On a personal note, I’m particularly pleased that Lennart has continued the punny naming scheme I began with Upstart. System D is a French concept that embraces responding to challenges when they happen, thinking fast and on your feet and adapting and improvising to get the job done.

There’s been some press coverage of this already, and various comments from different people raising some questions about why Ubuntu is going down this route.  Since this was largely my idea, I felt I should try and answer a few of the common ones.

Isn’t this just rhgb?

rhgb was the “RedHat Graphical Boot” system they used in RedHat and Fedora until the most recent Fedora releases.  It worked by starting an X Window System server and running the splash screen inside that.

This sounds very similar to xsplash, but with one key difference: the X server used by rhgb was shut down when boot finished, and a new X server started for the user to login with.

Instead, xsplash uses the same X server as the login window, and the same X server as your desktop.  In fact, it’s started by the GNOME Display Manager while it starts the greeter or auto-logins your desktop alongside.

Why don’t you use Plymouth?

Plymouth is RedHat’s replacement for rhgb, instead of using an X server it relies on Kernel Mode Setting to provide a framebuffer in the panel’s native resolution and colour depth and draws directly to that.  When the X server starts, the X server takes over the framebuffer without requiring a mode switch or a screen clear.

In many ways, Plymouth is simply a reimplementation of our original usplash.  Indeed, I found it quite ironic that some people have accused us of “NIH”ing xsplash instead of adopting Plymouth, when technically Plymouth is an “NIH”d usplash.

So really the question as to why we don’t use Plymouth is the same as to why we don’t use usplash.  We did actually consider replacing usplash with Plymouth since the implementation is rather cleaner, but Plymouth only supports Kernel Mode Setting drivers whereas usplash has a fall-back SVGA mode (it always had framebuffer support, thus KMS support, due to the Ubuntu PowerPC port).

Why not continue using usplash?

(or Plymouth, see above)

One of our main goals for Ubuntu is boot performance.  For Ubuntu 10.04 (that’s karmic+1) we’re targetting a 10s boot from the boot loader to a fully logged in desktop with idle disks.  To boot this fast requires some prioritisation.

We need the X Window System server for just about everything.  Until we’ve started the X server, we don’t have a display so can’t even start basic things like the underlying services and agents that run for a user’s login session.

Or, put another way, anything we do during boot that isn’t directly required to start the X server is delaying the boot.

The boot sequence must be setup in such a way that starting the X server is prioritised; once the X server is up, we can begin starting the user’s session (or the login screen session).  We can also start all those other system services that weren’t dependencies of the X server.

This pretty much turns the current sequence on its head, where the X server is one of the last things started rather than one of the first.

If we started a splash screen such as usplash before the X server was up, we’d still have to wait for the Kernel Mode Setting driver to be loaded (or hardware to be sufficiently probed to know that we don’t have a Kernel Mode Setting driver for it).  This is one of the primary dependencies of the X server too (the other is a mounted, writable filesystem), so in many cases we can start the X server at the same time!

Now, you could suggest that we do start the X server but also start the splash screen as well; and that the splash screen animates while the X server is running and the X server doesn’t paint to the screen until the desktop is logged in or the login screen is ready.  Unfortunately this simply doesn’t appear to be possible, the X server “takes over” the framebuffer in such a way that the splash screen simply freezes at that point (we can prevent it clearing the screen).  With an early X server start, it would spend more time frozen then it would animating.

This also wouldn’t work for the non-KMS case.

You could also argue that we could load the KMS drivers earlier, in the initramfs for example.  While possible, this adds a significant time to the boot time for the extra loading and probing required.  If we load the KMS driver in the initramfs, it takes about 8-10s to load the X server; if we load the KMS driver in the full system, it only takes about 6-8s to load the X server.  Easy win.

But what if we have to check the filesystem, or enter a decryption passphrase to mount it?  That’s why we still have usplash.  In those cases we will start usplash to display the progress or request the key.  The usplash theme will be themed such that when it finishes, and X starts up, it looks ok frozen for the short time until xsplash replaces it with an identical theme.

But karmic doesn’t boot any faster

Patience, my friend.  The 10s target is for Ubuntu 10.04 (karmic+1), not karmic (9.10).

That being said there are a number of updates planned for karmic that will boost the performance quite a bit, especially in terms of starting the X Window System server earlier.  These have always been targetted to land between Feature Freeze and Beta, simply because it’s delicate work that needed a lot of testing first and that everyone else’s uploads prior to Feature Freeze kept throwing it off.

Look for a call for testing RSN.

Its detractors will tell you how it takes much longer it takes to program anything in C.  They’ll point at how much C code it takes to do something as simple as create a GObject sub-class compared to the equivalent in Python or C#.  They’ll also probably complain that everything in C has to be compiled first, which takes even more time up.

No argument would be complete without them pointing out that C has no standard types for strings, let alone linked lists, binary trees, associative arrays, etc. and that you have to spend all that time implementing your own.  They’ll probably make a point about how C’s static type system means that even if you have a array type, you need to know in advance what types you’re going to put into it and can’t just mix and match.

Don’t feel tempted at this point to counter with a discussion about how great and flexible pointers are.  You’ll receive a lashing about how they’re even more evil than people who talk in the theatre.  The rant about the C problems of uninitialised memory, out of bounds pointer errors and segmentation faults is a timeless classic.  Especially when they get to the bit about how much time was lost debugging them.

And do you know what?

I simply do not agree with them.

I cannot think of a single project where the majority of time was wasted writing GObject header files compared to the single line of Python I needed.  I can think of lots where I’ve sat for hours trying to figure out which class I needed to derive from, or reworking the code after I realised I derived from the wrong class to begin with.  The high-level language doesn’t make this any easier.

As to the number of projects where I’ve needed to write a linked list or hash table implementation because C lacked a convenient dynamic array or associative array type like Python?  If it takes you any time to write that kind of code, you’re doing it wrong.  I’ve spent far more time realising that the structure is a performance bottleneck, and planning on the whiteboard a faster alternative.  Neither language helps with this whiteboard time.

And all those pointer issues?  This comes down to the tools that you’re using.  If you’re writing in a language and not using its development environment properly, then it’s little surprise that you’re not being as efficient in it.  gdb, valgrind, gprof and gcov are your friends.  Use them well.  I’ve spent just as much time dealing with other language-specific issues to make me believe that pointers aren’t any more evil as (for example) monkey patching.

The vast majority of my time on any new project is first of all spent thinking, and on a more mature project its figuring out what I did wrong and how I need to rework it.

Yes, the next biggest use of my time is working out what the best way is to express that.  If I’m writing in C, that means I’m deciding whether it needs a linked list, or a hash table, or some other fancy structure.  But if I’m writing in Python, believe me I spend just as much time normalising my class structure and coming up with all sorts of insane Pythonic ways of doing things.

If you’ve ever written in Perl and not lost a day or two to optimising your regular expressions, or eliminating code to arrive at the shortest possible expression, you’ve never written in Perl.

Refactoring takes you just as long in Python as it does in C.  Just because when you do it to C code you end up setting segfaults doesn’t mean that when you do it to Python code, suddenly your class structures don’t match anymore.

Proponents of test-driven-development, AGILE, LEAN and ANEMIC programming methodologies will probably argue that it’s easier to practice their religion with a high-level language.  I’m not buying that either, I’ve managed to write several large software projects in C that have a comprehensive test suite – including testing for allocation failures.

Ah, Rapid Application Development I hear you say?  Well, the only people I’ve ever heard say how great RAD is are people who’ve never had to support the software that was written rapidly, or debug issues with it years later.  RAD is great when v2 is going to be a complete rewrite, and v3 a complete rewrite again.  Very few websites have upgrades without announcing a completely new codebase.

It’s certainly true that it’s faster to mash up some code in a high-level language.  I use shell scripts and bits of Perl for this kind of thing all the time, and I frequently even do basic mock-ups or essays in Python.  But ultimately it all tends to be throw-away code, that I don’t really ever intend to take seriously or attempt to support later on.

For larger projects, I just don’t see any difference in the time it takes to write.

I’d like to cite an example.  The GIT and Bzr revision control systems are about the same age, one of them is written in C and one of them is written in Python.  It hasn’t taken them any less time to write the one in Python than it’s taken the others to write the other in C.  The one in Python doesn’t have extraordinary features that the one in C lacks.

C# fans would point out how much faster it is to UI code.  Really?  Then why isn’t Banshee that much dazzingly better than Rhythmbox?  Sure they’re different, but there’s nothing there that suggests one language is better than the other.

And do you know what?  I trust code written in C far more than I do any higher level language.  No, that’s probably not fair.  I trust C programmers far more than I do programmers of other languages.  If you tell me I have the option of choosing a program or library written in C over one written in Python or C#, I’ll take the C one every time.

Posting Date & ID: September 2007 UDD
Job Location: Your home with broadband. Some international travel will be required.
Job Summary: To adapt and develop the GNOME desktop to improve the Ubuntu user experience.

Key responsibilities and accountabilities:

• Use open source development methods to create, select and adapt software to produce innovative user experiences and address the common problems of desktop computing
• Extend the desktop platform as necessary to support development
• Work with designers, artists and other developers to develop ideas and complete the project
• Involve the community of development projects, teams and Ubuntu supporters to incorporate a range of perspectives and ideas
• Take ownership of many aspects of the desktop user experience (“look and feel”) in Ubuntu
• Follow projects and trends in user interface design in the open source world, integrate the best technologies into Ubuntu and ensure their quality
• Analyse, triage and respond to bug reports

Requirements skills and experience:

• A keen and insightful eye for user interaction
• A passion for intuitive, usable and visually appealing interfaces
• A strong desire to produce distinctive ideas that stand Ubuntu out from the crowd
• Experience with the GNOME development platform and desktop environment and technologies such as GTK+
• Some experience with mainstream graphics technologies such as OpenGL and Cairo in the C programming language
• Ability to be productive in a globally distributed team through self-discipline and self-motivation, delivering according to a schedule
• Familiarity with open source development tools and methodology, especially those in common use for Ubuntu and Debian package maintenance

How to apply

Please send a cover letter and CV with references to hr@canonical.com. Please indicate in your submission the role for which you are applying. We prefer to receive applications and CVs/Resumes in either PDF or plain text format.

As you can imagine, three people performing repeated tests of edgy means that the fabled startup sound got many, many playings.

A tradition started.

Now, whenever you hear that sound, remember to get up and dance, wave your arms in the air or just tap your fingers on the table.

The first ritual is that of the sprint, I don’t think this is orthodox XP but rather something inspired from it that we picked up from the Python community. With all of the Canonical developers scattered across the globe mostly working from their own homes, it’s become a useful tool; particularly for the Launchpad team.

The basic idea for those that haven’t heard of it is simple, and perhaps obvious; you get a selection of the team together in one place, sit them around the same table with particular goals to complete. In effect it’s highly compressed facetime and high bandwidth interaction to nail those tasks that need it, before you head off again and work at a more sedate pace.

The second is directly from XP doctrine and is that peculiar observance known as pair programming, something that is often coupled with sprints. For anybody who hasn’t encountered this before, it’s something I’ve always found rather odd. You get two programmers together, both itching to code, and you take one of them’s laptop away; and you don’t just force them to fight over the keyboard either, the laptop-less soul isn’t allowed to touch it.

The theory here is that it frees the deprived individual of the hassle of coding and allows them to direct the programmer in ways that may not be immediately obbious, or alternately think about the next bit of work that needs doing. Another interesting side-effect is it can be an interesting way to learn code you’ve not worked with before, if you’re the one doing the coding and you’re being guided what to do by a sage who already knows it.

I have a funny story here, so I’m going to digress from the main stream for a moment to tell it. A few months ago I was working in the London office, Mark had been up all night coding and had then given me responsibility to get his changes landed onto the Launchpad mainline. I’m not that hot on quite a bit of Launchpad, and fade to utterly clueless the nearer the code gets to the web application itself; and when trying to merge the two there were conflicts which I needed Mark’s help to resolve.

Now as anybody who’s met Mark knows, he’s a pretty good example of a Type-A personality, yet he suggested that we do a spot of pair programming to get the code in and I’d be the one with the laptop as it’d help me get to grips with the affected parts. This hilighted something I’ve always seen as a problem with pair programming, dealing with it when the a person with the keyboard has a totally different way of working to you. In particular, I’m an emacs user, whereas Mark is a die-hard vim user; but also right down to the working directory I would work from, how I test results, etc.

When you’re the one without the laptop, this can be quite infuriating, as you know exactly how to solve a problem and the idiot with the keyboard is dithering about doing things you don’t understand just to get there. If you’re a Type-A personality, you generally snatch the laptop away at this point and do it yourself; or at least you would, if you could drive the strange editor the other person uses.

I swear Mark was sulking as he gave the laptop back and let me do it.

Anyway, there is some relevance to that and we’ll come to it in a moment.

The third and final methodology is the concept of unit tests and more specifically test driven development. For anyone who hasn’t come across this before, I highly recommend it; I was suspicious too when Robert Collins took it upon himself to teach me the true way, but now I’m sold.

Simply the idea is that if you have any code that doesn’t have another piece of code in a test suite that checks that it’s working correctly, that code is broken. More particularly unit testing involves checking just one feature or requirement at a time, and stacking them together to test all of the code paths. I’ve actually found that this improves the APIs I design, as I write the code in small blocks and functions to make them easier to test.

Test driven development takes it even further, you write the unit tests first, before you write the code they’re supposed to test; usually one or two at a time. Obviously these tests will fail at first, it’s then your job to write as little code as possible to make them pass. If your code isn’t right, you add a unit test that will fail, and modify the code to make it pass.

This really comes into its own when you’re fixing bugs later, once you’ve identified the bug you write a test case or two that cause the problem; these will of course fail. You can then modify the code to make them pass, and at the same time be sure you’ve not broken other functionality because of the existing test suite. I’ve also found it really useful for particularly complicated or tricky pieces of code, especially those intricate algorithms that do particularly heavy lifting.

So onto the event itself, this was a sprint in our London office to indoctrinate Gustavo Niemeyer with the various projects he’d be working on. The goal for this sprint was decided to start the conversion of HCT to Bazaar-NG, and to do this Gustavo and I would pair program.

Now my last experience of pair programming had been that story with Mark (see, it had some relevance) and I knew I’d be just as bad if I wasn’t allowed to have the keyboard. I was also acutely aware that if Gustavo was just sitting by and watching, he wouldn’t get much benefit from it either, so he needed to be actively involved in the coding so he could learn the things he’d be working on.

I came to what I thought was a pretty neat, and obvious, solution to these problems. We set up my laptop with the code we’d be working on, and on my display were two side-by-side terminals both running screen sessions. Gustavo then set up two same-sized terminals on his, ssh’d into my laptop from both of them and joined the screen sessions. In the left-hand one he ran vi, and in the right-hand one I ran emacs.

Thus we both had keyboards, and both had editors, yet could see each other working and even steal the keyboard without danger of violence. We didn’t just sit side-by-side and code on different things though, that’s not pair programming and is just ordinary programming with a bit of a voyeuristic twist.

What we did was: in my terminal I started writing the test cases for the code we needed, it was Gustavo’s job to write the code that would make them pass. We actually added a third terminal in which we could run the test cases themselves; so I could run them when I’d added something that would fail, and Gustavo could run them when he thought he’d made them pass again.

This turned out to be a rather fun way to work, and at one point I was almost able to try and convince myself that the code was writing itself to pass the test cases I was writing. It also got me thinking that it’d be really neat to use genetic algorithms to breed code to pass test cases.