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.
@SJR:
but even if upstart changes tomorrow, surely that is unlikely to affect what is in 8.04 LTS? (from my POV it would be nice if it did, but I don’t know what the backwards compatibility issues might be)
And doing a remote upgrade of my server (which is multipurpose and thus runs everything under the sun) isn’t an option (apart from the fact that it would take my server off the LTS version, meaning I’d also be commiting to a further upgrade down the line)
just saying, it’s all very well saying there’s improvements in the latest and greatest, but 8.04 is going to be around for a long time, so can’t it get a little documentation love?
(though I just about get by, I get the feeling I’m missing out on some stuff, especially elusive references to logging facilities. that lack aside, it’s still better than daemontools, which managed to take down my previous server with some kind of infinite loop bug)
Scott:
Oh the software-store that is currently in Karmic is just a rebrand of an existing codebase. That’s interesting. Was this the software Phoronix previewed in their article or were those screenshots from the new codebase you are implying will exist? I’m make sure I quote you when people mischaracterize the rebranded codebase in Karmic as new development work when they write any more articles about it.
And the SoftwareStore wikpage says “may use PackageKit”:
“The Store is implemented using Python, GTK, and Aptdaemon, and may use PackageKit for some components”
That sentence confirms that Software Store is using Aptdaemon and further states that there is no firm commitment to transition to PackageKit. Would you disagree with my reading of that page?
And I think its pretty disingenuous to speak for the PackageKit project lead and his motivations with the design framework he has chosen without reference to an actual discussion that he participated in. Would you like me doing that to you? Putting words in your mouth considering design choices as a developer you have made and questioning your motivations for making those design choices?
I’ve read as much material as I can find that has been publicly archived where Richard Hughes as spoken in defence of the long standing and foundational no transaction interactivity design goal that PackageKit has. I would not characterize his involvement in such discussions in the same way you have. If there is a discussion you feel best represents the characterization you have made concerning Richard’s intent..feel free to point me to it.
-jef
@Jef: If you want an authorative voice on whether or not Software Store is going to use PackageKit or APT Daemon, you’re far better off talking to a developer working on that than one working on the boot sequence
Scott:
All I am asking is that when you speak you provide factual information which can be verified. If you can’t speak authoritatively and cannot reference authoritative information.. then don’t talk about it. Misinformation only serves one purpose..to raise the temperature of a discussion. I’m not trying to score points off of you by showing you up…but I care about is making sure information that is being presented is factual. Ronald Reagon: “trust but verify”
Now back to Xsplash… is there a specification specifically for Xsplash in the wiki that is authoritative that you can point me to?
-jef
@Jef: I do not know of any written specification for xsplash.
Scott:
Isn’t the lack of a public specification for xsplash a significant oversight? You’ve written a blog post..a pretty defensive one in tone…before an effort to widely communicate the design goals of what xsplash is meant to achieve was made. Without that documented specification in place there’s nothing documented which serves to counter a plausibly constructed NIH argument. If it matters to you that the work is not seen as NIH, and it seems that this does matter to you, then the xsplash design goals need to be articulated in the context of the project documentation…not as a reactionary personal blog post.
-jef
Hi Scott,
Very interesting your post about, and I think those are good reasons to change it. BUT one thing I think you guys could (should maybe?) do some effort, is in the way to make customization of the new XSplash easier. This USplash is not that easy to change. Actually I was trying to figure out how it really works(change the image, progress bar, colors, alignments..), but I gave up right now and wait to study this new version.
[]‘z
Lucas Mocellin.
[...] autant que l’optimisation d’Upstart censée apporter un meilleur temps de chargement. Sur son blog, Scott James laisse filtrer quelques informations, l’occasion pour nous de faire une petite [...]
Sequential Reads are vastly faster than Random Reads.
How hard would it be to read all required data in one sequential read?
Scott,
I was just referring to the fact that the slowest part of the booting process is the part where you login. Could you not rig up a login screen that accepts input before the system has finished booting? I don’t just mean launching gdm, I mean actually having a login screen come up instead of usplash etc. Then, when you actually finish typing in your user/pass, the boot process will already be 90% complete, or in the case of the normal computer user – done
Maybe it’s a bad idea, who knows.
My ideal bootup would be:
* Grub finishes, screen is black.
* Screen fades into a pastel shaded background, 2D animation happens similar to the demo “Life force” by ASD (in particular, 1:42 to 2:12 in http://www.youtube.com/watch?v=P0OfkJc711A&feature=related)
* Login/Password boxes appear.
* User logs in, even though booting may not be complete.
* Once user hits enter, login details are held in limbo until PAM is ready to take the details and authenticate.
I just thought it might be a nice way of logging in, that’s all. I imagine it can all be done within a standard 565 framebuffer, and if you get the handoff between the login and the xserver right, you may be able to do it without a screenmode change too.
Or am I just talking crazy now?
@Matthew: What you propose is definitely a revolutionary idea. The only problems that I see are those who authenticate against LDAP or W2K+ servers via samba. Networking, ldap and pam need to be up before that will work since it would be pointless to pretend to accept the credentials to prompt 5-10 seconds later telling them the authentication failed, but if we gave them a “Please wait authenticating…” with an animation it might be plausible.
Jeremy – we’re only talking about caching for a few seconds, plus this would only be applicable to home users etc, I can’t imagine corporate desktops wanting customisable bootup screens etc.
The “Please wait, authenticating” message is a good idea, but it goes back to the whole “technical” issue. Having the login field shrink out the way and a pulsating line of dots while it waits for the right services to come up could be a different idea.
The whole point of this is to make the login process feel quicker and less like a bunch of subsystems coming up. Instead, to give a nice flow through to logging in. Or, at least, it is to me.
[...] James Remnant: Making a splash. One of the biggest pains in working with the Mac4Lin dev team is that every time Ubuntu rolls out [...]
[...] Como parte de los esfuerzos por mejorar el tiempo de carga se ha sustituido el programa de arranque gráfico del sistema que venía utilizando la distribución, USplash, por un nuevo software desarrollado por la gente del Ubuntu Desktop Experience: XSplash. Uno de los desarrolladores de Ubuntu, Scott James Remnant, da una explicación más técnica del por qué de la sustitución de USplash y su negativa a utilizar Plymouth en su lugar (el software que utilizan Fedora y Mandriva) en Making a splash. [...]
[...] 6. Como parte de los esfuerzos por mejorar el tiempo de carga de la distribución se ha sustituido el programa de arranque gráfico que venía utilizando Ubuntu, USplash, por un nuevo software desarrollado por la gente del Ubuntu Desktop Experience: XSplash. Uno de los desarrolladores de Ubuntu, Scott James Remnant, da una explicación más técnica del por qué de la sustitución de USplash y su negativa a utilizar Plymouth en su lugar (el software que utilizan Fedora y Mandriva) en Making a splash. [...]
[...] improved and faster than before. Splash screen software has been replaced with Xsplash (Read the blog post of Scott James Remnant that’ll explains why). And by default, Ubuntu 9.10 uses ext4 [...]
[...] Como parte de los esfuerzos por mejorar el tiempo de carga de la distribución se ha sustituido el programa de arranque gráfico que venía utilizando Ubuntu, USplash, por un nuevo software desarrollado por la gente del Ubuntu Desktop Experience: XSplash. Uno de los desarrolladores de Ubuntu, Scott James Remnant, da una explicación más técnica del por qué de la sustitución de USplash y su negativa a utilizar Plymouth en su lugar (el software que utilizan Fedora y Mandriva) en Making a splash. [...]
[...] called xsplash which I find much more powerful than the older usplash. There’s a lot of underlying reasons involved in using xsplash but in this blog post I’d like to focus on the graphical part. The visuals produced by [...]
[...] processo di boot continueranno anche nella prossima versione di Ubuntu, la 10.04 (Lucid Lynx), che secondo Scott James Remnant, autore di Upstart, dovrebbe ridurre i tempi di caricamento del sistema operativo a soli 10 [...]
[...] processo di boot continueranno anche nella prossima versione di Ubuntu, la 10.04 (Lucid Lynx), che secondo Scott James Remnant, autore di Upstart, dovrebbe ridurre i tempi di caricamento del sistema operativo a soli 10 [...]
[...] En Ubuntu Karmic Koala se ha implementado una tecnología denominada splash xplash y esta misma regirá en Mint 8, que según clem, es más potente que usplash, al proveer gráficos más agradables. Razones para cambiar a xplash. [...]
10sec boot is great but I feel it needs to be accompanied by a 1 sec suspend and resume that doesn’t flash a view of the desktop (with potentially sensitive documents) before asking for the password to unlock the screen (if password is set off course).
Maybe faster Hibernate would be good also but if you can boot in 10 sec Hibernate becomes a little redundant for a lot of use-cases.
[...] Article d’un développeur Ubuntu sur ce choix [...]
[...] de Ubuntu, Scott James, explicaba de forma muy detallada el porqué de esta decisión en un post en su blog [...]
I’m not 100% certain why boot times are so important on a desktop system. This isn’t Windows. I reboot my laptop after kernel updates (and sometimes if I let the battery drain on accident).
Don’t get me wrong, improvements to any aspect of the system are always welcome, but it’s clear that xsplash and the new gdm aren’t quite prime-time just yet, so I’m a bit baffled as to why it was pushed into a release so quickly (Ubuntu 9.10 reminds me of the issues that prompted me to abandon Fedora, although in this case I just went back to 9.04).
Granted, xsplash and gdm were only a couple of the minor details that contributed to my overall dissatisfaction with 9.10, but Ubuntu has been appealing to date exactly because of the attention to these minor details. Without this attention to details and stability, it’s just Fedora all over again.
Keep up the work on xsplash, but perhaps keep it on the back-burner until it’s actually a finished product.
Hey Jef Spaleta, do you have problems getting laid? May be a big mountain gorila can do it.
It seems so, asshole.
Edit: I don’t really spect you publish my comment, but hey! Doesn’t sound great a reader writes what you have in mind!? lol xDD
I’m certainly changing to Gentoo or Arch when I buy my new computer in few months but after hopping a lot of distros and being using Linux Mint 7 for several months until it was killed by new Karmic Koala all I can say is Ubuntu accomplishes it’s objetives fullfiling it’s achievements and is undoubtly the King of all distros for the average to intermidiate user AND home/enterprise environment, it’s hard to think about another distro targeting such a wide user spectrum and doing it brilliantly.
Keep up your excellent work no matter what other envious people would say.
Cheers!
[...] am really impressed with the direction that to boot theming is taking, well done Scott and team. Nvidia black redraw issues have gone away too. Sound is working better for me. Easier to [...]
[...] No todo es perfecto, y ciertamente Ubuntu tambien tiene sus fallas, y en ellas yo pondria la implementacion de GRUB2 y xsplash, el primero ha creado una oleada de posts acerca de su configuracion, fallas en la instalacion con otro sistemas, quizas algo normal cuando pasaun cambio como este. Y el otro es xsplash, que es bien sabido que este es parte del plan de booteo mas rapido para la proxima LTS de Ubuntu (más aqui). [...]
It looks like finally Lucid will use Plymouth ?
[...] Xsplash a Plymouth è spiegata chiaramente da Scott James Remnant (Ubuntu Developer Manager) in un articolo di questo Settembre sul suo blog . Scott illustra, appunto, come la priorità sia quella di un boot [...]
[...] Article d’un développeur Ubuntu sur ce choix [...]