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.
Pingback: László Torma (toros) 's status on Wednesday, 02-Sep-09 13:23:34 UTC - Identi.ca
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?
Pingback: kristof keppens (kristofkeppens) 's status on Wednesday, 02-Sep-09 13:32:21 UTC - Identi.ca
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?
Pingback: Ubuntu: νέα πρόγευση από το "Karmic Koala" | Search Top Greek Blog
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)
@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.
Pingback: e-node blog » Ubuntu 9.10 et Xsplash
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.
Pingback: Peng’s links for Monday, 21 September « I’m Just an Avatar
Pingback: Novedades de Ubuntu 9.10 Karmic Koala
Pingback: Novedades de Ubuntu 9.10 Karmic Koala « Libertad Zero
Pingback: DemiLane | Ubuntu 9.10 : Karmic Koala – Beta
Pingback: Se acerca ubuntu 9.10 - Geekdk
Pingback: The Linux Mint Blog » Blog Archive » Mint 8 – Boot sequence
Pingback: Ubuntu 9.10
Pingback: Ubuntu 9.10 è già candidata al rilascio « GmG’s Weblog
Pingback: Nuevas noticias sobre Linux Mint 8
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.
Pingback: Nouveautés dans Ubuntu 9.10 – Partie 1 – Démarrage « Informatique de Julien
Pingback: Linux – Ubuntu 9.10 “Karmic Koala” - Gratis Programas, Descarga Freeware, Warez Full, Noticias
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!
Pingback: Ubuntu 9.10 impressions, extra packages. « khax.net
Pingback: Hablemos del Koala « Seamos realistas…
It looks like finally Lucid will use Plymouth ?
Pingback: Ubuntu 10.04: Uspalsh, Xsplash, Plymouth…? « Lordgiotto Linux Blog
Pingback: Pro PageranK » Archives du Blog » Nouveautés dans Ubuntu 9.10 – Partie 1 – Démarrage
Pingback: Novedades sobre Linux Mint 8 | La vida Linux