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)...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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.


                Edit: And you guys should vote for the first alternative here:


                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; 09 March 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.

                  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

                    Working...
                    X