On Tue, Jan 21, 2014 at 07:43:41PM +0100, Andreas Cadhalpun wrote: > On 21.01.2014 03:35, Josh Triplett wrote: > > If splash were a non-default boot option, and plymouth did nothing > > unless the kernel command line had that option, that seems entirely > > reasonable. Very easily done; just add this to the plymouth service, > > for instance: > > ConditionKernelCommandLine=splash > > I'm not sure what you are trying to say here, but you're actually > quoting line 7 of plymouth-start.service. ;)
...good to know. :) In that case, to clarify further: I don't have any objection to installing plymouth as long as the "splash" option is *not* included by default. It's a minor waste of disk space if unused, but it might be worth the convenience of being able to quickly turn on the splash. (On the other hand, if apt-get install plymouth enabled the splash by default, that's not hard to do either.) > > On current systems, there's an even better way to do that: make sure > > the kernel doesn't change the video mode set by the BIOS, and doesn't > > draw on the screen at all until X takes over. Then, you go straight > > from the BIOS or bootloader to your display manager login prompt. > > The display manager can even crossfade from the former to the latter, > > if you like. > > This sounds very nice, but what happens if the boot hangs and you > want to look at the boot messages? And how would you enter a > password for an encrypted partition? If you need to enter a passphrase, you can keep the same mode, switch to either a text or graphical passphrase prompt. > > When you're attempting to boot in a fraction of a second, 86ms is an > > eternity. If your boot process takes long enough that 86ms is lost in > > the noise, it's taking *far* too long. > > It looks as if I didn't make myself clear enough. Plymouth does > *not* make the boot 86ms slower. > Looking a bit closer at my startup: > plymouth-start.service is executed in parallel to > systemd-fsck-root.service and finishes a lot before that. > plymouth-read-write.service is executed, while network.service > blocks the boot. > plymouth-quit.service and plymouth-quit-wait.service are executed in > parallel, while network-manager.service blocks the boot. > > So it *seems* that plymouth makes the boot slower by 0ms! That would be worth measuring. A bootchart showing the disk and CPU activity of plymouth would help greatly here. > > Furthermore, I don't think that counts the delay incurred by any mode > > switches caused by Plymouth, and to the best of my knowledge only the > > most modern systems and hardware can avoid those mode switches, so > > you're actually incurring disproportionately more of a delay on > > lower-end systems. > > For these reasons I wanted to compare the whole boot time > with/without plymouth, but unfortunately for me any difference > vanishes in the noise. If you don't have such varying boot times, it > would help if you could carry out this measurement. I don't have a strong interest in splash screens, so it'd fall fairly low on my list, but after I work on integrating all the services installed on my system with systemd, I might be interested. :) > > On Mon, Jan 20, 2014 at 11:12:21PM +0100, Andreas Cadhalpun wrote: > >> Of course, this would be the best solution. So as soon as Debian > >> boots even on old grandma's computer in less then a second, plymouth > >> will be unnecessary. ;) > >> Unfortunately, this seems rather like utopia. > > > > It's spelled "systemd". ;) > > But seriously, that's very much the goal. And I think "less than a > > second" is not required to make a splash screen unnecessary; less than > > 5 seconds seems quite sufficient to make a splash screen superfluous. > > Plymouth and other splash screens were created when the norm was for a > > system running a desktop environment to take 30-60 seconds to boot; on > > such systems, a splash screen and progress bar seems quite reasonable. > > Of course, systemd makes the boot much faster, but systemd cannot do > magic, or can it... > * ...boot in less than 5 seconds, if the kernel takes longer than > 10 seconds? No, of course not. But if the kernel takes more than a fraction of a second to exec init, it needs fixing. > * ...boot in less than 5 seconds, if a particular service takes > longer than 10 seconds (e.g. clamav-daemon)? Sure, as long as gdm and X don't need clamav-daemon. clamav-daemon shouldn't be running on non-servers, in any case. Ideally, systemd should launch X and gdm (socket-activated) in the very first batch of services launched. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
