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

[Martin Steigerwald]

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.

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