[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Sun, 05.10.14 12:20, Martin Steigerwald (Martin at lichtvoll.de) wrote:

> > However, I also believe that the change we are making is for the good,
> > and even though it might not be obvious to many immediately, it brings
> > major benefits when administering machines, and they massively
> > outweigh the disadvantage of changing things. And apparently I am not
> > entirely alone with this, as the folks who make technical decision for
> > the various distributions ended up deciding in favour of systemd in
> > most cases.
> 
> Why do you believe so? What key points make you believe so?

Believe what precisely? Why I believe systemd is better than sysvinit?
Well, that's a big question, and I am pretty sure already well enough
discussed elsewhere, that we really do't have to repeat this here.

> Here the feedback I read over and over again is that you and RedHat basically 
> forced the systemd decision onto other distributions. While I do not see how 
> you actually can be powerful enough to do that, as we live in a free will 
> zone. I do see tendencies that more and more stuff *depends* on systemd cause 
> it needs features only available there.

Well, we provide good APIs. We provide them for a reason, because
applications benefit from them. App developers see that, so they adopt
them. That's pretty natural and obvious, no? If you want to know more,
about why they do that, then ask them.

What I find so puzzling about certain aspects of the criticism is that
some people apparently assume that logind and similar things were
entirely redundant, and that the APIs that it provides were so
redundant, that one could trivially write the same app, but not make
use of them... This idea that logind had exactly no merits, and was
little more than just an evil tool to drive systemd adoption...

> Dependencies like this actually create some force to adopt systemd.

Well, I certainly don't force anybody. We provide APIs for technical
reasons, and because we believe that people might benefit from them,
even need them. And apparently I am not too wrong with that, after all
they tend to adopt them...

> Now I know ConsoleKit isn´t developed anymore, but also I never got why a 
> logind implementation needs to depend on systemd base package in such a way 
> that at least in Debian systemd package has to be installed if someone wants 
> to use GNOME.

Well, logind talks to systemd to manage user sessions and user
processes in cgroups. That's why it depends on systemd. And since only
systemd implements that, we couldn't even support anything else even
if we wanted.

Our intention with systemd is to provide a strong platform. One
platform. If people want to use our code in other contexts, then
that's totally fine, but please understand that I am not going to do
any work for that, I am not going to maintain it, and I don't want to
see that in my code. 

> Much of the feedback is related to that. Many would appreciate something like 
> systemd if it just did *services* stuff. That is also what seemed to have 
> motivated the dev behind the use less d fork.

Well, I am sorry, but systemd is more than that. If systemd is no what
people want, they can roll their own thing, can continue to use
sysvinit, or even fork systemd, That's completely OK. But for what we
have in mind for systemd it's definitely a goal to make Linux more
attractive for developers, by providing a good set of core OS APIs
that people can just make use of, instead of a zoo of things that are
combined in wild combinations.

> > The current increase noised level around systemd adoption I attribute
> > to three things: the fact that RHEL7 is out now, the fact that due to
> > the adoption of systemd as default by Debian and Ubuntu the folks who
> > ignored the discussion so far now are faced with this change, and also
> > to a big part to certain "columnists" who in the interest of
> > generating traffic to their sites try to create a hubbub out of very
> > little.
> > 
> > Anyway, long story short: we knew what we did, and yeah, I read
> > feedback, even if it is written in a hateful style, and we learn from
> > it.
> 
> Well, I for myself have been concerned and surprised by *such an mount* of 
> uproar. Not even GNOME 3 triggered anywhere near that amount of threads and 
> mails.

Well, I am not sure this is really that way. GNOME 3 noise was pretty bad too,
maybe you just weren't involved so closely... But even if it wasn't,
our stuff touches most of the Linux community, which is larger than
the GNOME community.

> And I worry regarding various attempts to replace systemd functionality (by 
> systembsd services) and by use less d or using different inits. I think quite 
> some of them are based on solid technical arguments. I wonder whether systemd 
> might be missing out on something here.

Well, some competition would be great. I am pretty sure that uselessd
is not based on solid technical arguments though, and pretty sure
it's maintainer will figure that out pretty soon too...

Anyway, more power to him, at least he does soemthing, and isn't just
one of the do-nothing complainers, even if I certainly disagree with
much of his technical reasonings and decisions.

> > Well, note that systemd used for user services actually saves you
> > resources, as the systemd binary only needs to be mapped into memory
> > once and then is shared between all user instances and the system
> > instance.
> 
> But what about the argument of stability? Arguably a 1,3 MiB binary have more 
> chances for bugs and security problems. What happens if PID 1 crashes? I heard 
> about that systemd would in some circumstances have the chance to get 
> restarted.

So far we are doing pretty well with stability. And why would be
multiple different binaries from different projects be any more stable
than a single one we reuse at multiple places?

systemd does a lot more than sysvinit. It's larger because of
that. That's hardly surprising.

systemd is a fraction in size of the Linux kernel. If something in the
Linux kernel goes wrong it's a lot worse than if it goes wrong in PID
1. If the Linux kernel can manage the stability, so can we for
systemd.

(Heck! even wpa_supplicant has more lines of code and binary footprint
that the systemd binary!)

> And… with two binaries and a library or so… wouldn´t the result – i.e. the 
> memory footprint – the same? Except some per process data area all would be 
> mapped once.

Not following? Are you suggesting that systemd would be more stable if
we built the systemd binary in two versions and would link the common
code as shared library?

I am sorry, but that's not really how this works...

> > Well, some is valuable and important, but much certainly isn't. The
> > 200nd complaint that systemd was "monolithic" or so is something I am
> > genuinely not interested in anymore, for example...
> 
> Why do you think there is no point or vadility in it?

Because it has been discussed 199 times before. Because it isn't true,
unless you define what "monolithic" means to your own taste?

I mean, I am pretty sure the "monolithic" argument is really not about
anything technical. It's more about the fear that the systemd folks
monopolize too much influence over the whole system, and that they'd
rather see that splinter.

I can understand that feeling. We try to work against it, by
diversifying who can commit to systemd and things like that, but
ultimately, if people don't like if only the systemd group pushes the
OS forward all alone, then we can do little about it. People would
have to actually do something on their own, and if people just talk
and don't act, then yes, there will be only us left...

We will not split up systemd into multiple tarballs or repos, just to
create fake sense of "bazaar"... The stuff we do is supposed to be
streamlined, and uniform in its appearance. While you can adjust it
pretty neatly to your specific needs by picking only the components
you care about it, ultimately whether it's one repo or more, or one
tarball or multiple is just a boring technical detail that matters
only for building things and reusing code...

> systemd does a lot. And an 1,3 MiB binary is a hug binary size for something 
> that started out as managing services and sessions via control
> cgroups.

Well, it does a lot more these days. 

The Linux kernel also started out pretty small too. Nowadays it does a
lot more, which makes it so unversially applicable. I figure systemd
goes a similar path. (Though hopefully will never grow as massive,
complex and monolithic as the kernel...)

Lennart

-- 
Lennart Poettering, Red Hat