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

[Martin Steigerwald]

Am Dienstag, 7. Oktober 2014, 23:40:45 schrieb Uoti Urpala:
> 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.

I can´t point my finger at it why… but I really feel uncomfortable with this 
tight coupling. I think that the systemd-shim + cgmanager combination may have 
bugs does not *prove* that such a think isn´t workable.

But due to the design choice of you systemd developers to have it all in one 
people who do believe that separating different functionality is for the long 
term benefit of interoperability and avoiding what I´d call vendor lock in, 
although I clearly see that systemd upstream community isn´t a single vendor 
as in one company who produces a comercial product.

In other areas where the Linux kernel requires user space helpers things 
initially have been separated. The whole do it all in once hald daemon was 
split into udev, libudev, udisks and upower… yet now, systemd and udev is in 
one upstream again.

What speaks against putting the cgroup functionality and other stuff from 
systemd into shared libraries with clearly defined APIs – which are documented 
and where the documentation is the reference, not the source code – and 
allowing it to be used elsewhere?

Then systemd may use it as PID 1, but if someother wants to use it in own 
project, can use it as well. I consider cgroups as part of the kernel API and 
I highly dislike the battle on which of the available solutions will get 
control over it. Actually I still think the API is broke if it cannot allow 
for mutiple processes accessing it. I don´t know an easy way to fix it, but I 
think such a kind of API as kernel interface… anyone can read a file, mount a 
filesystem, open a network socket, set a nice value depending on permissions 
but when it comes to control groups it is down to "one to rule them all". I 
can´t help it, but this just seems utterly broke to me.

I can´t help it but I don´t consider this to be a sane operating system API.

> > I never thought much about my init system until recently.  I never really
> > had any complaints with SysV init, although I do recognize that systemd
> > provides real improvements for some use cases.  So for me as a sysadmin
> > the wisest thing to do is stick with what I already know, as long as it's
> > working well enough (and for me, it is).
> The issue with "I should be able to stay with sysvinit because it worked
> fine for me" is that keeping sysvinit working is COSTLY. The reason
> sysvinit used to mostly work was not that it would have been a reliable
> system - it mostly worked because people kept using a lot of effort to
> work around and paper over various issues that kept popping up. And
> there's no justification to keep up that effort for the minority who
> wants to stay with sysvinit. So, you can keep running your old systems
> unchanged if you want, but you shouldn't expect to be able to upgrade
> them or install new software without switching to systemd.

What you write here basically comes down to a forced adoption. At least this 
is how I receive what you write.

I know understand much more clearly on why systemd triggers split and polarity 
and I am quite worried about it.

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