Mailinglist Archive: opensuse-factory (710 mails)

< Previous Next >
Re: [opensuse-project] Re: [opensuse-factory] The road to systemd for openSUSE 12.1
  • From: Guido Berhoerster <gber@xxxxxxxxxxxx>
  • Date: Mon, 13 Jun 2011 18:45:33 +0200
  • Message-id: <20110613164533.GB4240@wopr.local.invalid>
* Michal Vyskocil <mvyskocil@xxxxxxx> [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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread