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: Sun, 12 Jun 2011 09:52:45 +0200
  • Message-id: <20110612075245.GA2622@wopr.local.invalid>
* Greg KH <gregkh@xxxxxxx> [2011-06-11 22:00]:
On Sat, Jun 11, 2011 at 08:28:39PM +0200, Guido Berhoerster wrote:
* Greg KH <gregkh@xxxxxxx> [2011-06-11 18:39]:
On Sat, Jun 11, 2011 at 10:41:56AM +0200, Guido Berhoerster wrote:
* Frederic Crozat <fcrozat@xxxxxxxx> [2011-06-10 19:04]:
systemd is coming for next openSUSE (12.1) scheduled next fall.

As far as I'm aware there was only one recent discussion on this
this list about it [1] which started with the premise that systemd
will be the default for 12.1. I'd like to know who has decided
when and for what reasons that systemd will be the default for
12.1? More specifically, what alternatives were considered and why
and how is systemd serving the openSUSE project better in the
long term?

There is only one alternative, and that package is no longer being
maintained or developed, so there really isn't anything else to choose
from.

As for why to switch, you did read the long series of posts about
systemd for admins, right? All of those things are stuff that users
want, and care about, why would we not provide them?

This was not about offering systemd as an option, but part of the
proposal ("phase 3") was to replace SysV init files with native
systemd files. And an init daemon is not any arbitrary package,
fully comitting to an implementation has long-term consequences.
Hence, I would expect some kind of decision-making based on some
real considerations rather than just following the latest buzz
and the quite vocal promotion of its author.

And how do you know that was not done already?

I don't, it was and still is my initial question.

And also, please always remember, that changes happen here by people
doing the work, not by people sitting around and discussing things, or
dissing things.

That's not a valid argument when it comes to init which is
probably the most important component of the system after the
kernel. For such a change which directly and indirectly affects
every other userspace component and, as I already said, has
long-term consequences for the project (cost of implementation,
cost of switching later etc.) I would expect a little more
legitimacy. Apart from that a lot of packagers (probably including
me) are expected to do work here.

Do you not trust the developers involved to get this working correctly?
If so, offer to help out. If not, well, that's a different problem...

No I don't and I'm not interested in helping out with it since I
disapprove with the direction it has taken (even in Redhat people
seem to begin to disapprove if you look at fedora-devel). I would
be interested in helping out with either improving the existing
system or switching to something which is an init daemon and not
a jack-of-all-trades attempting to replace half of the system.

I admit that I disapprove of its approach to cram everything but
the kitchen sink into an init daemon (including stuff completely
unrelated to init such as (auto)mounting, handling LUKS volumes,
controlling the system locale, time, and hostname, replacing
ConsoleKit, or the planned per-user session-startup
functionality) rather thank keeping it simple and doing one thing
well (a design philosophy which has served Un*x systems rather
well in terms of functionality, security, and sustainability of
codebases). So far it's not even clear where this will end.

It does one thing well, the rest is supported by helper scripts and
plugins.

Do you have an alternative that you think should be used instead?

I'd really like to have an answer to my initial questions
(including why we have to switch the default init system at all
right now).

Because what we have right now sucks.

Seriously, it does, it was great for the 70's and 80's when things were
static, but now, it makes absolutly no sense whatsoever. Linux has been
evolving to support this type of dynamic, use only what you need when
you need it, type of a system for a very long time now, and this is just
one piece of that progression that has been needing to change for a very
long time.

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.

But the alternatives I am aware of are sysvinit which
we are using right now and upstart, given the (im)maturity of
systemd, the lack of clarity where the scope of systemd will
eventually end, and my aforementioned concerns I'd consider both
of these the lesser evil.

So what would make systemd somehow "mature" in your eyes? A major
distro shipping it as their default init system? The developers working
on it paid to do nothing else but support it and guarantee that it works
properly for everyone?

I don't consider Fedora exactly as the standard for maturity (see
fedora-devel and the Redhat bugtracker). Furthermore, it's not
clear what direction it will eventually take and where it scope
will end, what will come after the planned handling of user-sessions,
a mail client[2]?

Or something else?

Oh, and upstart is a dead-end project, so that's not even an option,
sorry.

Oh right, a year ago it was supposed to be the future.

[1] http://people.freebsd.org/~trhodes/fsc/
[2] http://www.catb.org/jargon/html/Z/Zawinskis-Law.html
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups