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

[Tom Gundersen]

On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
<Martin at lichtvoll.de> wrote:
> Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
>> > Systemd-shim provides some functionality that systemd-sysv provides,
>> >  and allows admins to use init systems other than systemd while still
>> >  installing things like brasero.  I think this is a great thing,
>> >  except I wonder why the systemd project didn't separate this
>> >  functionality from the init system in the first place.  Systemd-shim
>> >  is a duplication of effort.  Not only that, but it must time its
>> >  releases with the releases of systemd-sysv.  That's no big deal for
>> >  Debian's stable release, but it can be problematic in Debian's
>> >  unstable and testing branches.
>>
>> Because it's additional work and complications. Apparently providing
>> systemd functionality without systemd running is not a trivial
>> undertaking, as the lag between systemd and systemd-shim releases
>> shows. I could spend my time for open source development on a
>> (technically) pointless (from my vantage point) split, but I
>> prefer to improve systemd instead.
>>
>> Debian as a project already paid significant to support systemd as an
>> alternative, when systemd version was held back for a year waiting
>> for systemd-shim to catch up. This is certainly not the last time.
>>
>> [snip]
>
> I think exactly this kind of attitude is what triggers most of the polarity
> around systemd.
>
> Its like "We don´t force systemd on anyone, but we provide as lots of
> functionality tightly coupled with it and if you do not implement it
> elsewhere, i.e. catch up, you need systemd anyway".
>
> While I believe it is *extra* work to separate functionality, I think it is
> *important* work. It would raise the acceptance of systemd, it would reduce
> the polarity it triggers. And it would make it more interoperable.
>
> Right now people are duplicating systemd stuff in several other areas. The
> reluctance to adopt systemd with certain distributions creates friction. Other
> implementations need to catch up and at any point in time may not be
> compatible.
>
> So, aside from it being additional work, is there any *solid* or even
> *unavoidable* technical reason to couple functionality that tightly?
>
> Wherever I look free software projects do great extra work to modularize and
> separate out functionality that can be separate. For a reason. See KDE
> community for example. They spend years of development work into separating
> things out into separate packages and have a clear ruling on what may depend
> on what. There are other examples for sure, OpenStack for example, while I do
> not yet know it in detail consists of a ton of separate packages in Debian.
>
> So or so… I think its this kind of attitude that triggers most of the polarity
> and split.

Most of the modules in systemd do not depend on eachother. However,
logind does depend on the cgroups dbus API of systemd (PID1). In the
past logind interacted with the cgroups fs directly, but this had to
be changed as the kernel is moving to a model where only one process
may be in charge of cgroups. On systemd systems that one process is
PID1 (why that is so has been discussed elsewhere so won't repeat
that), so anything needing to deal with cgroups needs to go through
the systemd API.

I hope that explains why logind has to depend on systemd (or at least
something implementing the systemd API).

Cheers,

Tom