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

[Martin Steigerwald]

Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering:
> On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urpala at pp1.inet.fi) wrote:
> > On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> > > My question really isn't "why are the Debian dependencies the way they
> > > are".  I understand that.  I was trying to highlight the strange
> > > situation of a desktop application requiring a particular init system. 
> > > I *think* this is a result of the init portion of systemd being bundled
> > > together with the logind portion of systemd.  To me (unfamiliar with
> > > the systemd code) those two functions seem distinct enough to merit
> > > being separate.  Debian can't easily separate what the systemd devs
> > > have developed as a single binary, so we end up with these strange
> > > dependency chains.> 
> > "Single binary" is false of course. Logind is developed as a separate
> > program, which is why systemd-shim is possible at all.
> > 
> > AFAIK the actual relevant dependencies go as follows: First, there's a
> > good reason why logind requires cgroup functionality. And there's a good
> > reason why cgroup functionality is best implemented together with init
> > (see
> > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> > for more info). So it's not quite directly "logind has to depend on
> > systemd as init", but "logind has to depend on the system having cgroup
> > support, and there's no equally good cgroup support available for inits
> > other than systemd". It is possible to provide the relevant cgroup
> > interfaces in or on top of another init, as the systemd-sysv + cgmanager
> > combination attempts to do. But it is not trivial to do, as bugs and
> > implementation delays with that combo have shown, and it's quite likely
> > that there will be more problems in the future. It's not a particularly
> > good idea to use the less-tested and less-reliable systemd-shim instead
> > of the more reliable systemd. Thus the overall result is that yes, it
> > does make sense to switch machines to systemd when you add certain
> > functionality, even if that functionality does not appear to be directly
> > tied to the init system at first glance.
> 
> Also note that the systemd concepts logind makes use of are also
> exported in its own API. The "scopes" and "slices" that logind uses
> are exposed on its bus objects, and they are used by tools like
> "loginctl" to do their work.
> 
> The "scopes" and "slices" concept does not exist elsewhere, and
> there's nothing comparable around, so even if we wanted we couldn't
> make logind work on anything else.

Then why in the first hand are the "scopes" and "slices" concepts within 
systemd *tightly* coupled when it is functionality that makes sense to be 
utilitizes in a component that provides a different functionality.

I wonder what functionality systemd provides right now in one more or less 
tightly coupled package:

- early boot process
- managing kernel drivers and device files (via coupled udev)
- resource control for process groups
- logging
- core dumping
- network while I think a distro-unified way to approaching network that 
replaces the current distro specific ways like ifupdown and so on, why does it 
have to be coupled with systemd?
- cron, although that at least in Debian is separate as systemd-cron
 
Thats rather much.

Really rather much.

Way more than traditonal sysvinit covered.

What of this actually *needs* to be coupled with systemd? What of this needs 
to be coupled tightly to Linux kernel? 

systemd is driving a road where its all of this functionality by default is 
only available for Linux and where upstream said they just won´t accept 
patches – is that still true? – for portability. systemd provides more and 
more functionality that desktops like to use, that other tools like to use.

When Microsoft back then did something like this it was called "Embrace, 
Extend and Extinguish"¹…

a) Embrace: systemd provides functionality that is mostly compatible or 
similar with what sysvinit and other components provided

b) Extend: systemd extends on that functionality and makes it more and more 
difficult for desktops and apps to ignore that kind of functionality offers

c) Extinguish: The scope of systemd becomes so broad, the functionality it 
offers in a – admittedly – convenient package to often needed and used, that 
other ways of providing the functionality are extinguished.

Really… it matches quite closely.

I don´t think this was your plan. But… when looking at the currently visible 
outcome this is quite exactly what is happening here.

So if you can follow this just a tiny bit: Do you start to understand why 
systemd triggers the uproar, polarity and split so obvious that one needs to 
have hands before both eyes for not seeing it?

So as I see it: there are *real* concerns. And if systemd is meant to be a 
tool for users and admins, I *highly* and *strongly* recommend that you as 
systemd closely look at these concerns. Unless you are willing to trigger the 
polarity, the split and the uproar that it creates.

In KDE more and more voices come up that developers need to talk to their 
users. Sure… its a do-ocracy. But still… if you want to become really broadly 
accepted and successful with something you offer… its important to listen for 
feedback. And in my oppinion you are in a good opportunity here, cause I think 
there is no lack on feedback on systemd.

[1] https://de.wikipedia.org/wiki/Embrace,_Extend_and_Extinguish

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