Making a splash
As you probably know by now, even if you’re not following the karmic development closely, Ubuntu has gained new splash screen software called xsplash. This is the hard work of Cody Russell and Ken VanDine of the Ubuntu Desktop Experience team.
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.
I am sorry but Usplash and Plymouth are very different. Plymouth can work on the non KMS case using frame-buffer. Xsplash is far more closer to RHGB and RHGB existed far before Usplash as well. Red Hat has worked extensively in the kernel and Xorg and KMS nows works for all major drivers in Rawhide. You are reinventing the wheel and catering to proprietary drivers instead of working on improving KMS support.
Ubuntu has a long history of not participating in upstream development. PackageKit vs app store, notify-osd etc and now is no different except that more people have begun to notice this.
Thank you very much for explanation. I was puzzled as well when I heard that Ubuntu wasn’t adopting Plymouth, but your explanation reassures me that the Ubuntu developers know very well what they are doing.
I wonder if you could also write a blog post to give an update about upstart? Last time I heard upstart hasn’t replaced the init scripts in Ubuntu yet but emulates them, and it does not give an advantage yet AFAIK?
So, if I follow you correctly, the main reason for not going the plymouth way is because of the NVIDIA driver ?
Great Works and good explanation of your work.
[...] http://www.netsplit.com/2009/09/02/making-a-splash/ a few seconds ago from web [...]
This might be an obvious statement, but why not ditch the splash completely? I don’t mean revert to a rapidly passing dmesg screen – still start the xsplash, but make it the gdm login screen instead.
Upon pressing return once login details are entered, it does basic auth and clears the screen ready for the desktop? Surely the slowest part of the login process is that tedious time the user is actually logging in?
That sounds terrific, except for the part where you start usplash in order to ask for the passphrase. It sounds really messy. I use encryption on my laptop and I’m not looking forward to this.
Can’t you modify xsplash to ask for the passphrase?
[...] http://www.netsplit.com/2009/09/02/making-a-splash/ a few seconds ago from choqoK [...]
Hi,
I’m not really informed about the subject, but your (interesting) blog post doesn’t make it clear: is the 10 seconds target “boot to functional desktop” or “boot to login screen fast and then thrash for minutes like Windows” ?
Hoping it’s the first option,
Colin
“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).”
Sorry but that is just wrong, Plymouth does not require KMS it requires a framebuffer and works fine with vesafb (or any other fb).
KMS just adds the benefit of a flicker free boot (no mode switches during boot).
Sounds good, but aren’t you basically doing what windows does?
You can login 10 seconds after turning on your laptop, but there will still be services starting in the background that will make your system sluggish while starting your web browser, email etc…
Fantastic work! Good post too.
Looking forward to seeing the results.
Thanks.
All of this seems excessively complicated. The question I hoped you’d answer: “Why have a splash screen at all?”. If you can boot in 10s, why do you need a splash screen?
Well explained Scott. To me these directions show Canonical has it priorities right with focusing on reducing boot times instead of focusing on flashy boot experiences (emphasis required per reader). Look forward to seeing the fruition of this work.
As far as NIHing usplash goes, I’d suggest that it probably has something to do with usplash being something of a layer of hacks to deal with its rather odd development history – evolving from vga16-only to more complete framebuffer support and then gaining the horrible, horrible svgalib-based vesa code. If I’d wanted to add anything new to usplash, *I’d* have started from scratch at this point. It did its job well, but it’s really not something that deserves to live much longer.
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.
I think you mean this the other way around? The X server is now one of the first things started, rather than one of the last.
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
that sound’s a bit hackish.
The question I’ve yet to see answered in a meaningful way is, why is it so important to have a fast boot time? Wouldn’t this effort be better spent improving hibernate/sleep?
I know development isn’t a zero-sum game, especially in the Free software world, but this seems like scratching an itch rather than making a real contribution to the usability of Ubuntu.
@neo: I’m sorry, but I just don’t agree. Plymouth is simply a reimplementation of usplash, yes it can use a framebuffer but so can usplash. It may be a cleaner implementation (I agree with @mjg59) but it’s still something that Fedora could have done by working with us. They chose not to.
PackageKit isn’t relevant at all, since App Store is intended to be *based* on it.
@Alexander: the flexibility of Upstart gives a massive advantage, the pending updates are primarily a shift from using init script to Upstart jobs. The necessary groundwork for this was Upstart 0.6 which is in karmic already.
@Xav: No, the main reason for not choosing Plymouth over usplash is actually that usplash works today and requires us no effort to keep working. To replace it with Plymouth would require a lot of effort to have it packaged, integrated, learn it enough to develop new themes, implement an SVGA backend for the non-KMS cases, etc.
We simply don’t have the engineering resource to do that *and* boot performance *and* everything else
@Matthew Walster, @Anonymous: well, the first problem with not having a splash screen at all is all that black screen. A 10s boot means the screen would be black for 10s before showing the user’s desktop.
It’s fast, but it’s still not fast enough. Entirely unscientific testing suggests that this is too long to remain black.
For the auto-login case, it’s really necessary.
For the login-screen case, it’s still necessary because the login screen itself takes a few seconds to start right now. I would hope that GNOME could really sort out their dire performance issues such that the GDM greeter could start in as little time as xsplash.
But until then, you need something to look at for the few seconds it takes to display the login screen.
Ovidiu: you can’t use X to ask for the passphrase, because X is on the filesystem that we need the passphrase to decrypt.
Yeah, Plymouth could have been developed with Ubuntu – but by the same token, back in 2005 we could have worked with the Splashy developers rather than writing Usplash from scratch. I decided not to do that because their design made it difficult to make use of any of their existing code. I disagree that deciding not to use an existing codebase is inherently NIHing, especially since I don’t think any of the Usplash code would have appeared in the final work.
@Colin, @Phil: as I said in the blog post:
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.
After the 10s, your desktop is visible (auto-login) and the disk light is off. All services have been started, and your system is idle.
@mjg59: oh, I don’t disagree – I’m just retoring to the claim that Ubuntu NIH everything.
Fedora on the other hand
how’s that NIH apport replacement coming along? how’s that NIH initramfs-tools replacement coming along?
(and, frankly, who am *I* to complain about NIH :p)
@Scott
But will it really improve the experience for the user?
Getting to a login screen as quickly as possible is a laudable goal, but if you then are tapping your fingers for at least a minute waiting for your email client or web browser to start up, surely you are shifting the goalposts?
It will be great to be able to say: “We have a 10 second boot”, but if you are left to twiddle your thumbs while your desktop becomes usable, then you have just shifted the problem.
@Phil: I’m completely baffled by your reply.
We will have a 10 second boot. After those 10s your system will be idle.
If you click Firefox, it will appear straight away (or at least as long as Firefox takes to load these days). THere will be no finger-tapping or thumb-twiddling.
Thanks, I missed that point
@Scott
My question stemmed from this passage:
“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.”
Maybe I just misunderstood it.
@Phil: sure we can start them in parallel with the user’s session, but we don’t consider the boot to be finished until both the user’s session and the other services are running.
In practice, most of those services are actually running by the time the X server has finished initialisation, let along starting the login session
It’s funny, I have the exact opposite experience regarding plymouth and its integration in Mandriva http://blog.crozat.net/2009/08/boot-splash-evolution-in-mandriva-linux.html
- it works out of the box, with or without KMS, no need to implement anything
- it is already working great, it tooks me less than a week to implement what was missing to switch from splashy to plymouth
- plymouth developers are extremely opened and collaborative
I was very happy to hear about xsplash, especially after reading this and it being part of gdm. Which answers one of my previous criticism of plymouth. Basically in line with why you choose to do xsplash.
Having to keep usplash though seems annoying. Could we make GRUB2 ask for the password/encryption key instead? It can be themed (although I’m not sure as extensively as usplash).
I guess we still have to keep it for disk check though…
Just to check..
On a normal boot usplash isn’t started at all in Karmic?
People should also note that it will ALWAYS be possible to have a configuration that takes longer than that to boot, as you could install as much stuff as you have disk space for. Once you have webservers and sql servers and every other kind of service under the sun running, it _will_ take longer. That’s a reflection of the flexibility of any modern OS rather than of any slowness of bootup.
Or for that matter you could just change the boot fsck settings so it checks every boot
SJR: While I understand why there wouldn’t be a major version change of upstart in a specific distro of ubuntu for compatibility reasons, and while I understand this is tedious compared to other work, but the documentation for upstart in 8.04 is sorely lacking. /usr/share/doc/upstart has nothing useful, “man start/stop/initctl” all go to the same page which has nothing on creating jobs (or, more cruicially, no “see also” entry telling me where to go to see how it’s done), and there’s nothing in man under “event.d” or “upstart”
This makes it difficult to know what to do, and while there is interesting hints on your blog, I am unsure what applies to the version shipped with 8.04 – which is, of course, supported for the next 3 and a half years
NIH…. to know whether a particular claim of NIH have any merit.. you really have to understand the design of the available implementations and compare and contrast them with the design goals of what the new project is trying to achieve. Only then can someone really assess if its prudent to write a new codebase versus retooling the design of an existing project.
If the claims of NIH are excessive, perhaps the design goals and rationale for the new codebase were not communicated well enough. With that in mind, could you point us all to a documented specification or blueprint that talks in some detail about the design goals and requirements for xsplash?
-jef
@Scott: Dracut is coming along nicely, thankyouverymuch. I use it as my primary initramfs generator on Karmic these days.
@Scott
Also…
I think you are misinformed about SoftwareStore being based on packagekit. Isn’t SoftwareStore being built around AptDeamon as a replacement for PackageKit?
https://launchpad.net/aptdaemon
http://packages.ubuntu.com/karmic/software-store
Shows the aptdaemon requirement…but not a requirement on packagekit.
I’m not saying that aptdaemon is NIH. I’ll let you judge for yourself if the design of packagekit’s transaction model was such that aptdaemon was required to replace the role of packagekit. I don’t know enough about deb packaging to make an NIH accusation stick.
But I do find the rationale for needing the extra interactivity that aptdaemon provides ironic considering Canonical’s push to strip out interactivity from notifications by removing the action buttons. I would have thought the fire and forget approach to package transactions that PackageKit demands would be exactly the sort of design that Canonical’s in-house design team would prefer.
Live and learn I guess.
-jef
It makes a lot of sense to use X early, because we need to load X anyway. However I too am worried about the need to use a different system for anything in early boot. Crypto root is an obvious one, but there could be all sorts of interactions the system needs when we’re still in early boot/initramfs. It’s a shame we’d need an ad-hoc solution (reverting to usplash) for things like that.
Logically, if Plymouth is a NIH’d usplash, and Xsplash is a new usplash…
That would of course mean that Xsplash is doubly NIH’d, since Ubuntu is not only sidestepping Plymouth, but even instead of revising -their- tool, Ubuntu is NIH’d their own IH stuff.
Sorry, but I don’t buy your arguments concerning Plymouth …
Mandriva is integrating Plymouth in its next release. The Mandriva 2010.0 beta1 released some days ago have Plymouth enabled in KMS and non-KMS mode.
They managed to quickly port their splash theme to Plymouth without great efforts. And it seems that they have no issue working with the Fedora team.
http://blog.crozat.net/2009/08/boot-splash-evolution-in-mandriva-linux.html
Here’s a ten second black screen boot for you…
http://www.youtube.com/watch?v=Vx0vOdnCvoY
To reiterate, boot times need to go back to this…
http://www.youtube.com/watch?v=kyeouqsXwX8
Sorry for the link spam, but I miss my Amiga for boot times…
Thanks again for working hard towards making the Ubuntu experience better.
@nona: Ideally, you don’t want any user interaction in the initramfs at all (except for cryptoroot stuff), and booting to local storage should not take more than a second or two — with those timeframes, do you even need a splash screen?
[...] ο προγραμματιστής Scott James Remnant της κοινότητας αναφέρει στο weblog του, τους στόχους για τη μείωση του χρόνου boot [...]
hello and thanks for your hard work… in 9.10 usplash and xsplash use together? you mean first we see usplash and after loading X it turnes to xsplash? and what about Kubuntu 9.10?
It makes complete sense to me. I have an old computer and the 10 second boot is impossible on my machine. I want to look at something nice, and this is ideal for the non-technical user that is frightened by scrolling text or cursors (before GDM loads). So Canonical have yet again made it easier for non-technical users which is what we want.
@Frederic Crozat: exactly, it took you some amount of effort to do the work, even if it was small. We already have usplash which requires *zero* effort. At the moment, the benefits of Plymouth over usplash don’t yet outweigh the downsides – one of the major ones being the engineering time to do the work.
It’s not that Plymouth isn’t necessarily better; it’s just that something that works right now is better than something that needs some work
@frymaster: the version of Upstart in karmic has significantly more documentation.
Note that the lack is deliberate though, Upstart is not yet stable and everything may yet change, so if you follow the documentation today it doesn’t mean it’ll work tomorrow.
@jef: the specification for SoftwareStore very much says it’ll use PackageKit. The package you’re looking at is the current add/remove software tool rebranded, with no development work done on it. This almost certainly still uses aptdaemon.
You’re quite right that Ubuntu doesn’t prompt for questions during upgrades or installs, whereas Debian does.
Though this brings up the interesting point of the responsibilities of upstreams. What we have here is a situation where the Fedora upstream of PackageKit *refuses* to accept or discuss the requirements of Debian-based distributions.
While that’s obviously up to them, it does mean that you cannot accuse Debian-based distributions of not working upstream when upstream has told them (effectively) to sod off
@TGM: Apples and Oranges. You can trivially upgrade almost any hardware inside your PC. And you can upgrade the Operating System without replacing the hardware (since it’s not stored on a ROM on the motherboard)