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

[Martin Steigerwald]

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.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7