Announcement

Collapse
No announcement yet.

Plymouth Packages For Ubuntu Are Now Available

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Plymouth Packages For Ubuntu Are Now Available

    Phoronix: Plymouth Packages For Ubuntu Are Now Available

    Last November we learned that Plymouth would replace USplash in Ubuntu, but the official graphical boot splash screen change wouldn't come until Ubuntu 9.10 (a.k.a. the Karmic Koala)...

    http://www.phoronix.com/vr.php?view=NzEyOQ

  • #2
    Can anyone tell me, why the boot process is:

    Code:
    Power on -> Grub -> Load services -> GDM -> Load desktop
    and not

    Code:
    Power on -> Grub -> GDM -> Load services -> Load desktop
    ?

    With the second approach the user wouldn't have to look at the services load.

    Maybe even Grub could ask for the user name and password for the user that should log in, so GDM could be completely removed?

    Comment


    • #3
      Originally posted by Louise View Post
      Can anyone tell me, why the boot process is:

      Code:
      Power on -> Grub -> Load services -> GDM -> Load desktop
      and not

      Code:
      Power on -> Grub -> GDM -> Load services -> Load desktop
      ?

      With the second approach the user wouldn't have to look at the services load.

      Maybe even Grub could ask for the user name and password for the user that should log in, so GDM could be completely removed?
      The desktop requires some things to be loaded, but also having the full pause after GDM isn't good either. Most distributions now have this:
      Code:
      Power -> Grub -> Load some essential services/scripts -> GDM & finish other services

      Comment


      • #4
        Originally posted by some-guy View Post
        The desktop requires some things to be loaded, but also having the full pause after GDM isn't good either. Most distributions now have this:
        Code:
        Power -> Grub -> Load some essential services/scripts -> GDM & finish other services
        Why?

        I mean, of course it would not be the GDM as we know it, but the purpose of GDM really is only to ask for a user name and password.

        Comment


        • #5
          Originally posted by Louise View Post
          Why?

          I mean, of course it would not be the GDM as we know it, but the purpose of GDM really is only to ask for a user name and password.
          Well, there would be so many complaints if such a change happened.
          A new user would be like: "Wow this loads fast" "Why's it so slooow" "What is this sh*t!!!"

          This would be especially bad for older computers that can't handle multiple tasks at once

          Comment


          • #6
            What I am looking for is either a technical or historical explanation.

            Comment


            • #7
              I Agree

              I think another option would be to make a basic loading screen as part of gdm, start all the required pieces to make that work as quickly as possible.

              Fasttrack to GDM loading screen.
              Grub -> Kernel (Mode Setting First) -> Xorg -> Gdm loading screen ...wait... allow login

              Other Stuff (that's still required)
              Grub -> Kernel (the rest) -> Other required services -> end Gdm wait, allow login

              I think we shouldn't waste boot time trying to make the boot prettier :P. Ok, maybe a very very little. What can plymouth do, that Xorg can't?

              Comment


              • #8
                Originally posted by Louise View Post
                What I am looking for is either a technical or historical explanation.
                This isn't something Plymouth would affect either way.

                Historial reason, well, yeah. That's pretty much it. A typical system also does everything sequential, which is unneccesarily slow even on systems with only one core (waiting for devices and stuff like that, the CPU isn't at 100% at all times when booting).
                Hopefully Upstart will soon be fully used (which is ALOT more exciting news than this.
                http://upstart.ubuntu.com/

                Edit: And you guys should vote for the first alternative here:
                http://brainstorm.ubuntu.com/idea/18452/

                Those who oppose the idea to let you type in your password before all services are started are just plain wrong.
                There is absolutely no good reason for me to have to wait for CUPS to start. In the time that I spend typing in my password, it'll have started, thus shaving off a few seconds on the actual time from power on to fully loaded desktop.
                Last edited by Micket; 03-09-2009, 04:29 AM.

                Comment


                • #9
                  Originally posted by Micket View Post
                  A typical system also does everything sequential, which is unneccesarily slow even on systems with only one core (waiting for devices and stuff like that, the CPU isn't at 100% at all times when booting). Hopefully Upstart will soon be fully used (which is ALOT more exciting news than this.
                  http://upstart.ubuntu.com/
                  Those who oppose the idea to let you type in your password before all services are started are just plain wrong.
                  There is absolutely no good reason for me to have to wait for CUPS to start. In the time that I spend typing in my password, it'll have started, thus shaving off a few seconds on the actual time from power on to fully loaded desktop.
                  Typing a username/password usually doesn't dake more than 10 seconds (well, unless the user is old and/or disabled). The "services-loading" phase lasts anywhere from around 30s up to 2min, depending on hardware speed and installed packages. So even in the best possible case you don't really save much time, if you still have to wait for stuff to load after typing the password.

                  I really don't see what benefit a nice desktop with frozen icons brings -- seriously, I've encountered this many times in *win: the system is supposedly "on" and I can try and launch applications, but so much stuff is still being loaded that everything slows to a crawl and sometimes fails to work entirely (for example you try to launch an app yet nothing happens). I really don't want that experience in Linux -- when I log in, I expect everything to be up and running, including CUPS, a web server, sshd and whatever I may have installed on the system.

                  The best thing to do is have the system boot faster. By far the worst offender there is the HDD, especially in a laptop/netbook. If the HDD is replaced by a SSD things improve tremendously, so that will be solved in time as SSD's slowly start to appear everywhere, maybe even included in HDD's for a swift system partition.

                  Another avenue is in improving the efficiency of the boot tools themselves, and here upstart is a very good example which we can hope will be implemented properly -- the problem is a lot of innertia, as always with invasive changes. Shortening loading times for things like X (via KMS and optimizations) will also move us the right way.

                  All-in-all, there are a lot of areas where the boot time can be made shorter, however simply throwing a xDM prompt before the system is half-way loaded is not the right way to do it, that's like swiping dust under the carpet -- it's still there, you just can't see it!

                  As to using GRUB to log in, that may be possible if using something like LinuxBIOS, so the whole system is actually initialized _before_ GRUB. Otherwise, you'd have to implement a whole bunch of things right into it, making GRUB sort-of a miniature kernel. Deffinitely not the right way to go.

                  Comment


                  • #10
                    Originally posted by mgc8 View Post
                    Typing a username/password usually doesn't dake more than 10 seconds (well, unless the user is old and/or disabled). The "services-loading" phase lasts anywhere from around 30s up to 2min, depending on hardware speed and installed packages. So even in the best possible case you don't really save much time, if you still have to wait for stuff to load after typing the password.

                    I really don't see what benefit a nice desktop with frozen icons brings -- seriously, I've encountered this many times in *win: the system is supposedly "on" and I can try and launch applications, but so much stuff is still being loaded that everything slows to a crawl and sometimes fails to work entirely (for example you try to launch an app yet nothing happens). I really don't want that experience in Linux -- when I log in, I expect everything to be up and running, including CUPS, a web server, sshd and whatever I may have installed on the system.

                    The best thing to do is have the system boot faster. By far the worst offender there is the HDD, especially in a laptop/netbook. If the HDD is replaced by a SSD things improve tremendously, so that will be solved in time as SSD's slowly start to appear everywhere, maybe even included in HDD's for a swift system partition.

                    Another avenue is in improving the efficiency of the boot tools themselves, and here upstart is a very good example which we can hope will be implemented properly -- the problem is a lot of innertia, as always with invasive changes. Shortening loading times for things like X (via KMS and optimizations) will also move us the right way.

                    All-in-all, there are a lot of areas where the boot time can be made shorter, however simply throwing a xDM prompt before the system is half-way loaded is not the right way to do it, that's like swiping dust under the carpet -- it's still there, you just can't see it!

                    As to using GRUB to log in, that may be possible if using something like LinuxBIOS, so the whole system is actually initialized _before_ GRUB. Otherwise, you'd have to implement a whole bunch of things right into it, making GRUB sort-of a miniature kernel. Deffinitely not the right way to go.
                    Exactly, you said it all right man

                    Comment


                    • #11
                      Originally posted by mgc8 View Post
                      Typing a username/password usually doesn't dake more than 10 seconds (well, unless the user is old and/or disabled). The "services-loading" phase lasts anywhere from around 30s up to 2min, depending on hardware speed and installed packages. So even in the best possible case you don't really save much time, if you still have to wait for stuff to load after typing the password.

                      I really don't see what benefit a nice desktop with frozen icons brings -- seriously, I've encountered this many times in *win: the system is supposedly "on" and I can try and launch applications, but so much stuff is still being loaded that everything slows to a crawl and sometimes fails to work entirely (for example you try to launch an app yet nothing happens). I really don't want that experience in Linux -- when I log in, I expect everything to be up and running, including CUPS, a web server, sshd and whatever I may have installed on the system.

                      The best thing to do is have the system boot faster. By far the worst offender there is the HDD, especially in a laptop/netbook. If the HDD is replaced by a SSD things improve tremendously, so that will be solved in time as SSD's slowly start to appear everywhere, maybe even included in HDD's for a swift system partition.

                      Another avenue is in improving the efficiency of the boot tools themselves, and here upstart is a very good example which we can hope will be implemented properly -- the problem is a lot of innertia, as always with invasive changes. Shortening loading times for things like X (via KMS and optimizations) will also move us the right way.

                      All-in-all, there are a lot of areas where the boot time can be made shorter, however simply throwing a xDM prompt before the system is half-way loaded is not the right way to do it, that's like swiping dust under the carpet -- it's still there, you just can't see it!

                      As to using GRUB to log in, that may be possible if using something like LinuxBIOS, so the whole system is actually initialized _before_ GRUB. Otherwise, you'd have to implement a whole bunch of things right into it, making GRUB sort-of a miniature kernel. Deffinitely not the right way to go.
                      1. It's not a matter of slamming the login screen before ANY services and keeping SysV as is. Many services are suitable to be started before login is allowed.
                      2. It doesn't stop the services to continue loading to simple LET you start typing your password earlier.
                      3. The biggest offender when it comes to boot time is sequential loading of the startup scripts, when they don't depend on each other.

                      It wouldn't freeze your desktop. You wouldn't even notice the CPU-load of a most of these services (mostly insignificant). Obtaining an IP-address, mounting a few external drives, starting CUPS and alot of other non-critical services require insignificant amount of CPU-time (you will never EVER notice this load) so your false idea about a frozen desktop for 30seconds is false.
                      In fact, I've stopped and started my bluetooth and ssh deamons many times while running, without having my system stop and crawl for 30 seconds, how odd!

                      This is not windows. Just because someone else implemented it in a bad way doesn't mean anything. If done right, this will working very very good. And hey, it's possible to simple make GDM depend on every earlier process and it'll be forced to wait for every service before it lets you type your password.

                      Eeeeveryone wants parallel boot, since it's faster. This is just making the user IO parallel as well. If you wanted to it would have been trivial to make it sequential if you really wanted to, so why oppose the possibility to do so?

                      Comment


                      • #12
                        I'm tired of people blaming the hard drive. Yes, the hard drive is slow and prolli keeping us from a 10 second boot. But we are at 30 seconds right now, which according to my boot chart appears CPU bound.

                        Comment


                        • #13
                          Originally posted by mgc8 View Post
                          As to using GRUB to log in, that may be possible if using something like LinuxBIOS, so the whole system is actually initialized _before_ GRUB. Otherwise, you'd have to implement a whole bunch of things right into it, making GRUB sort-of a miniature kernel. Deffinitely not the right way to go.
                          I bet it would be very easy to have GRUB to ask for username and password.

                          All GRUB would have to do, is to compare if the hash match with the one in /etc/passwd.

                          Comment


                          • #14
                            Originally posted by mgc8 View Post
                            The "services-loading" phase lasts anywhere from around 30s up to 2min, depending on hardware speed and installed packages.
                            Quotation needed. Because, sorry to put it like this, the number is bullshit.

                            I use archlinux and load all services bar hal in the background (hal is needed for input with evdev). Boot time with background services: 15 seconds; without: ~26 seconds. The system is usable immediately after login in both cases (install an archlinux virtual machine and try it, if you don't believe me).

                            Waiting for cups or network to start before you can login is, to put it mildly - dumb.

                            Comment


                            • #15
                              I just looked at my bootchart for this morning on my Ubuntu Jaunty desktop and cupsd is already loading after gdm...

                              Comment

                              Working...
                              X