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

[Tom Gundersen]

On Tue, Oct 21, 2014 at 11:35 AM, Martin Steigerwald
<Martin at lichtvoll.de> wrote:
> Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie:
>> 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).
>
> Thanks, Tom.
>
> As explained in another post – I didn´t read all the new answers… but it makes
> sense to do so – actually I feel uncomfortable about the new cgroup API. Its a
> kernel API. The Linux Kernel is a kernel supporting preemptive multitasking.
> Yet the new cgroup API requires or at least strongly recommends that only one
> process uses it. And… additionally to that that is a change that has been
> proposed by developers that to me oppinion are quite near or even working for
> systemd upstream.
>
> To me a single-process-usable API in the kernel seems broke. It may be hard to
> get the locking right… but still… I think the current cgroup API is still as
> broke as it can get. The unified hierarchy approach makes some sense to me, but
> requiring that only one process modifies it, instead of providing an API
> mutiple processes can use just seems plain broke to me.
>
> And I know, thats probably something to raise on LKML. And I may be inclined
> to do so.

The systemd project does not have much (any?) influence over what
interfaces the kernel provides, so I suggest you take your concerns up
with them. That said, you will likely get further with technical
arguments, and preferably an alternate implementation, than just
claiming you have a bad feeling.

Cheers,

Tom