Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: No Plymouth Coming To Ubuntu 9.10

  1. #11
    Join Date
    Aug 2008
    Posts
    233

    Default

    rugby471: Plymouth depends on KMS, but KMS is needed for many other things, like working suspend/resume, BSOD (or any other color hehe) for kernel panics, fast VT switching, to run the Xserver without root privileges.

  2. #12

    Default

    they will not get their 10 second goal
    that's ridiculous

  3. #13
    Join Date
    Apr 2009
    Location
    Woodbridge, VA
    Posts
    116

    Default

    To answer the other question, KMS is in karmic now but only for intel. Nouveau wont make it, 2.6.32 kernel at the earliest I hear, doesn't support all chips (might be wrong on that point), and nvidia binary drivers are incompatable with KMS. ATI depends on if it gets merged in 2.6.31 which it most likely will. That leaves *alot* of cards that wont have KMS support by the time karmic is released, don't forget about everything that isnt from those 3 companies

  4. #14
    Join Date
    Apr 2009
    Location
    Woodbridge, VA
    Posts
    116

    Default

    Quote Originally Posted by SyXbiT View Post
    they will not get their 10 second goal
    that's ridiculous
    15 seconds on a dell mini 9 was the new goal from what I heard.

  5. #15
    Join Date
    Oct 2007
    Posts
    1,274

    Default

    Quote Originally Posted by Svartalf View Post
    Considering that text boot takes roughly the same amount of time (seriously) as the usplash
    The bootcharts I've seen tell a different story, and when boot times get that low, 1s is significant, so maybe my remark was more "helpful" than you think

  6. #16
    Join Date
    Aug 2008
    Posts
    18

    Default Boot times

    Quote Originally Posted by Svartalf View Post
    Considering that text boot takes roughly the same amount of time (seriously) as the usplash or any of the other modes seem to (The time doesn't come from doing pretty things to the screen or just raw text- it comes from the operations being done to generate either, which have traditionally been done serially throughout the boot up, when there's quite a few things that could have been done in parallel...) your remark isn't actually helpful...
    This might not be true in all cases. Got an EEE recently and (for obvious reasons) I decided to replace the sys that came with it. With my own, largely based on LFS-stable but deviating from it when I thought appropriate. Got Plymouth running nicely, but...
    As I said I deviated from the official LFS quite a bit, writing custom bootscripts among other things, resulting in an ~8 sec boot time (GRUB to SLIM). Plymouth added 5 secs to that boot time, so I ditched it and went without bootsplash. I'm quite sure that on a recent multicore desktop that delay would be significantly shorter (not crazy enough to risk hosing my main machine, so no experience with that), but it _is_ a delay in this case. (Well, yes, I might have just misconfig'd stuff.)

    EDIT: Or might have just misunderstood
    Last edited by trepo; 05-29-2009 at 06:29 PM.

  7. #17
    Join Date
    Aug 2008
    Posts
    99

    Default

    I don't believe there's any technical reason for a graphical boot to take longer than a text boot. The people designing the graphical boot simply need to know how to optimize what they're doing instead of just relying on faster hardware or an accelerated video card (something that isn't too common in free software outside of the video apps and libraries like mplayer and ffmpeg, and perhaps the most popular X11 drivers).

    I wrote some applications for the Linux framebuffer a long time ago (including a boot splash that never got released), and in my testing, on a ~200MHz CPU (IIRC), with a plain PCI video card, I was able to push over 30fps full screen to a 1024x768 screen (that's about 68MB/s with packed 24-bit pixels, which was the bandwidth limit of the video card, not a CPU limit). A boot splash doesn't have to draw to the entire screen, and doesn't have to load a bunch of large graphics files from the drive (if they design it right). I haven't used Plymouth (I mostly use Debian derivatives and Gentoo), but my guess is that its bottleneck is either a lack of I/O optimization (reading too much fragmented data from disk) or not-yet-optimized processor and video resource usage, not an inherent failure of the concept of a graphical boot splash.

  8. #18
    Join Date
    Dec 2007
    Posts
    248

    Default

    That's a good decision ...

    Ask anyone what he would prefer a nice graphical boot or shorter boot and the answer should be obvious for most people

  9. #19
    Join Date
    Dec 2007
    Posts
    677

    Default

    Great decision.

  10. #20
    Join Date
    Dec 2008
    Posts
    62

    Default

    Quote Originally Posted by unix_epoch View Post
    I don't believe there's any technical reason for a graphical boot to take longer than a text boot.
    Nothing is free. You can not get around the fact that another program to load and execute will take some time. You can't get around the fact that the image data must be loaded and processed as well.

    Things can be executed in parallel to minimize the damage, but on most computers, the disk is the bottle neck and not capable of doing more that one reads operation at a time.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •