On Wed, Jan 22, 2014 at 12:53:05AM +0100, Andreas Cadhalpun wrote: > On 21.01.2014 23:14, Josh Triplett wrote: > >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. > > As far as I know, this would be the outcome, if plymouth was just > added to task-desktop without further action of the installer. > But this is not what I (and Antoine) intended with this bug report, > as this wouldn't really change much for 'novices' that don't know > how to change boot options. > > >(On the other hand, if apt-get install plymouth enabled the splash by > >default, that's not hard to do either.) > > So you agree that it is easy enough to manually remove the 'splash' > boot option if you don't like it (assuming it was enabled by > default)?
I don't see where you got that from what I said. No, I'm still arguing against having a splash screen by default. I was saying that two options potentially make sense: installing it and leaving it disabled, or leaving it uninstalled but having it active on install. The latter seems potentially easier for a novice user than the former: just install plymouth and you have a splash. > > On Tue, Jan 21, 2014 at 07:43:41PM +0100, Andreas Cadhalpun wrote: > >> On 21.01.2014 03:35, Josh Triplett wrote: > >>>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. > > So the kernel would have to draw on the screen, before X takes over. For the text variation, yes; or, long-term, you'd use something like kmscon. > By the way, how can I make sure, that the kernel doesn't change the > video mode? Take a look at the work on i915 and "fastboot". > >>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. > > How can one create such a bootchart? Boot with init=/usr/lib/systemd/systemd-bootchart . > >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. :) > > That's great. :) > The funny thing is, I'm also currently trying to write unit files > for the services on my machine, that don't have one. > I usually manage to get them working for me, but I'm new to systemd, > so I'm not sure they are totally correct, as there are things in > init scripts ... *argh* ... > Perhaps you can help me (or tell me who to ask for help)? Happy to chat by IRC, Jabber, or email; the #systemd IRC channel and the upstream mailing list are also extremely helpful. > >>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. > > I actually thought about the time that is called 'kernel' (in > contrast to 'userspace') by systemd-analyze plot. That's what I'm talking about; that should take almost no time. > >> * ...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. > > How can I achieve that? > Currently it seems as if multi-user.target waits for exim4.service, > which starts only after clamav-daemon.service is ready. Ieally, by uninstalling exim4 and clamav-daemon; getting the MTA removed from standard is another big goal of mine. :) But more seriously, as far as I know you just need to make sure that gdm doesn't depend indirectly on exim4 or clamav-daemon. > >clamav-daemon shouldn't be running on non-servers, in any case. > > There might be reasonable use cases for this or other services that > take long to start. Sure, but almost none of them should be in the critical path to launch gdm. > >Ideally, systemd should launch X and gdm (socket-activated) in the very > >first batch of services launched. > > I'm afraid I don't see how this would help, as they need at least > local-fs.target. Sure, like almost everything else, but just about everything else they need should be able to run in parallel. (Remember one of the huge benefits of socket/bus/etc activation: you can launch a service and its dependencies in parallel.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122003047.GA16287@cloud
