* Michal Vyskocil <mvyskocil@suse.cz> [2011-06-13 14:25]:
On Sun, Jun 12, 2011 at 09:52:45AM +0200, Guido Berhoerster wrote:
Yeah it sucks, and it has for a long time compared to its alternatives and I'm also familiar with SMF on Solaris, rc on FeeBSD and its modernization efforts[1], as well as upstart on Ubuntu. I'd still be interested in the reasoning why we have to switch right now and why it has to be systemd.
Why now? Upstream claimed it is enough stable and feature complete, it has been already released in Fedora 15, so will be here any better time in future? And of course, having it enabled by default earlier in Factory would help with bugfixing a lot.
From administrator point of view is the most important it provides the simple access to majority Linux features - cpu schedulers, io scheduling, cgroups, pam, process namespaces and so and so [1]
With systemd you can disable, change or override the vendor suppliend service. Nothing will prevents you to create your own sshd.service, which will be never replaced on package upgrade like /etc/init.d/sshd.
Having the same way how the service is started independently on the way how the start is triggered is unique - now you have to maintain init script and (x)inetd configuration file separate. With systemd whatever-activation will turn on the same .service file.
Usage of cgroups makes the system much robust and prevents you from mistakes like killall in one init script will kill all instances of daemon. And with the easy of creating your own variants of init scripts, you can very easy maintain more instances of one service.
And yes, when the whole logic of service run/start/restart is now a part of systemd, so no need to reimplement it again and again.
There are of course more features, like socket-based activation, paralel start, no need of fork, clean execution environment, having a great cross-distro consolidation [2] (because it contains tools like) and so, but I hope this is enough for you.
I know the features systemd provides, some seem genuinely useful while for others I'd dispute whether they are actually features (e.g. making scripting harder) or even belong into an init system and whether a significant amount of functionality not related to init should be centralized this way, even if not all of it is performed by pid 1 (see my other mail). In terms of functionality it goes far beyond that and even its main developer acknowledges that and so far it is not yet in sight where the scope of systemd will eventually end, e.g. AFAICS replacing ConsoleKit and providing some user session management functionality a la launchd seem to be next on the agenda. As far as cross-distro consolidation goes I'm sceptical as well, it does not seem like Debian or Ubuntu will use it as the default init system any time soon. Anyway, since such a decision has implications for the whole distribution and its direction due to the associated costs of switchting to it and possibly away from it in the future I would expect some deliberation based on technical grounds in public _before_ making that decision including an evaluation of the alternatives, reasoning why it is desirable to fully commit to it right now (as opposed to providing optional support), associated costs, reasoning why it is in the interest of openSUSE etc. So far I haven't been able to find any such deliberation or even a simple discussion about making a decision in whichever form, there are just several statements by SUSE employees which take it for granted that systemd will be the default in 12.1, this was my main point and is what irks me the most in this case. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org