[Please mind I'm not an expert on this stuff and I had a beer. Please do correct any factual mistakes I might have made] On Lu, 07 iul 14, 15:40:35, berenger.morel@neutralite.org wrote: > > From what I know about systemd's behavior, and official documents I have > read from it's authors, systemd was not meant to be faster to boot. > > Plus, systemd will only be faster to boot if your system is bloated, which > is quite common for gnome/kde users. > Let me explain that point. > Systemd uses an on-demand strategy to boot services, so, something which is > not needed will not be started at boot, only when it'll be needed by > something. > So, on a system like my personal desktops for which I try hard to keep them > minimal but highly usable anyway, it's useless: only things I use are > installed, and when I have some daemon that I know I use only rarely, I > simply disable it: cups, graphical network manager (when I am in hotel them > are useful, because I have no idea about how to configure a wlan when there > is no wpa protection...) or even ssh or some ftp servers. > > Ok, now it should be clear why the faster boot is achievable on computers. > Now, the question I would like to ask is: does not it feels like a false > speed? We all know about the windows' DE which is unusable for a random > period of time after login, won't systemd's on demand strategy expose people > to the same issue? I think it might, but do not mind: it won't happen to me > and people like me. Quite selfish, you'll think? Not really: I will be happy > to teach other my way, which will probably make other's systems faster and > better autonomy on batteries. I think you're missing something. Assume you have a service foo depending on service bar, where bar listens on some port for requests from foo (these may be for a desktop or a server, doesn't really matter). 1. sysv-init + sysv-rc + static, sequential ordering (pre-insserv): a) order foo after bar b) hope bar starts fast enough so that foo doesn't do strange things, or crash or whatever, insert a big enough 'sleep' in the initscript of foo if it doesn't 2. sysv-init + sysv-rc + dynamic, dependency based ordering and parallel boot (insserv): a) dependency is encoded in the initscript header (Debian specific) b) same as 1a. 3. systemd with socet activation a) dependency is encoded in the unit file (mostly reusable across distros) b) systemd creates the listening socket used by bar and will start it as soon as foo starts sending requests 3a usually does bring speed improvements (test for yourself), but the main benefit is that foo can rely on the *fact* that the socket is available for use (systemd will takes care of that, assuming unit files are correct), no need for arbitrary delays that may or may not work on a specific setup for various reasons. To prove my point (on a laptop with LXDE and just a few services): $ grep sleep /etc/init.d/* | wc -l 27 $ ls /etc/init.d/* | wc -l 75 (that's more than a third of the initscripts) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt
Attachment:
signature.asc
Description: Digital signature