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.