Plymouth Packages For Ubuntu Are Now Available

[Micket]

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?

[gQuigs]

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.

[Louise]

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.

[BlackStar]

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.

[kurros]

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

[AliBaba]

I bet it would be very easy to have GRUB to ask for username and password.

To actually access /etc/shadow Grub has to access the root partition. And, guess what, that requires _some_ services and drivers started.
Imho, there's no need to present a login screen as early as possible.



@others:
In fact you can move the start of the login manager to a very early point in the "boot" process, but no, you can't have gdm start before at least the systems hardware is initialized.


On my system only acpid, dbus and hal are started before GDM, but that takes about 3 seconds. Initializing hardware and system (in rcS) takes about 20 seconds.


I personally don't use GDM to remote login. But what if someone does and there's no network yet?

[Louise]

To actually access /etc/shadow Grub has to access the root partition. And, guess what, that requires _some_ services and drivers started.

How do you think Grub loads /etc/grub.conf now?

[Micket]

On my system only acpid, dbus and hal are started before GDM, but that takes about 3 seconds. Initializing hardware and system (in rcS) takes about 20 seconds.


I personally don't use GDM to remote login. But what if someone does and there's no network yet?

Well some of you have quite optimized bootups already it seems. I have a bunch of stuff that doesn't make any sense to me to wait for, heck i'm almost at the point where i disconnect my external drives quickly during boot. So pointless.

If we had gotten rid of SysV and replaced it with something that can handle dependencies it should easily been able to make login depend on whatever it needs, such as having a network up and running could be one thing.

Heck, I dont even care if the default is to hold off GDM until everything is loaded (parallell boot should still cut it down significantly), but I would like to have the possibility to let me start typing the password earlier, if i want to.
Upstart or launchD both have many other positive things as well (restarting processes and such). I want it so badly.

[AliBaba]

How do you think Grub loads /etc/grub.conf now?

It doesn't. It's /boot/grub.conf here :-)

Well some of you have quite optimized bootups already it seems.
If we had gotten rid of SysV and replaced it with something that can handle dependencies it should easily been able to make login depend on whatever it needs, such as having a network up and running could be one thing.

I don't think that upstart could optimize the boot process on my system a lot. If you look into Debians init-scripts you most likely will notice the init header:

### BEGIN INIT INFO
# Provides:          gdm
# Should-Start:      console-screen acpid dbus hal network-manager
# Required-Start:    $local_fs $remote_fs
# Required-Stop:     $local_fs $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: GNOME Display Manager
# Description:       Debian init script for the GNOME Display Manager
### END INIT INFO

This is already enough info about dependencies. You could use "insserv" and edit /etc/init.d/rc (setting CONCURRENCY=shell or startpar, not sure though atm). I don't know, if this makes any difference. I don't use it because I manually optimized a lot here.

Imho the most significant speed boost is deactivating everything you don't need regularly and loading it on demand. Candidates here are, amongst others, Apache, PostgreSQL, MySQL and VirtualBox. I eg. do a lot of web development, but not every time I start my system => HUGE difference.

[Micket]

Ok firefox just crashes so i lost my entire reply.

The dependencies aren't used in such way. It's just for generating the sequential list of sripts in /etc/rc*.d/* from what i can tell.
It's also very new and debian only. (well ubuntu too i guess)
Unless you hack around it's 100% sequential.

Sure you can manually optimize it alot (with high risk of breaking stuff). Concurrency shell causes many problems, so it's just for those who know exactly what they are doing.
Having a whole new system, leaving those pesky shell scripts behind us is a clean solution, with more than just parallell boot as apositive effect.

1. Parallell (without hacking).
2. Avoid shellscripts (just changing bash -> dash shaves off a few seconds)
3. Managing services even after they have been started.
are some things i'd like to have working, out-of-the-box.