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

[Rob Owens]

----- Original Message -----
> From: "Martin Steigerwald" <Martin at lichtvoll.de>

> Heck, I started a thread here and then didn´t manage to take time to
> carefully
> read it and reply here and there as I see fit. But I challenged people on
> debian-user mailing list to constructively voice their concerns upstream, and
> even pointed them to this mailing list. As far as I saw *no one* of the
> posters in debian-user took up on that challenge. Which I view as a pity.
> Cause now actually you invited constructive feedback. I wonder whether I may
> forward your answer to debian-user so they see your statement of inviting
> constructive feedback.
 
I am here from debian-user, due to Martin's suggestion.  So now that he's calling me out, I guess I'll post my questions :)

For the record, I'm a sysadmin and not a developer.  I imagine my questions and opinions will reflect that.

> Here the feedback I read over and over again is that you and RedHat basically
> forced the systemd decision onto other distributions. While I do not see how
> you actually can be powerful enough to do that, as we live in a free will
> zone. I do see tendencies that more and more stuff *depends* on systemd cause
> it needs features only available there.
> 
> On of the most talked on things on debian-user is the logind thing. GNOME
> actually depends on it, as far as I know. While KDE in Debian still uses
> ConsoleKit, as it seems to me when looking at the process list and finding:

On Debian, I came across an unusual dependency.  Installing a cd burner (brasero) required me to change my init system to systemd.  Sounds kind of ridiculous, I think.  The dependency chain went like this:

brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv 

I don't know enough about this stuff to comment very intelligently, which is why I haven't said anything up until now.  But my research shows that each of these dependencies is indeed valid in the sense that each dependency represents some real requirement for functionality.  The issue, I think, is that some of these packages provide very broad functionality.  As I put it in a Debian bug report:

Brasero needs X functionality, which can be found in package W.  Package W also provides Y functionality, which depends on systemd-sysv.  So therefore brasero depends on systemd-sysv, even though it doesn't *need* it.

I gather that this has something to do with logind and/or cgroups.  I can appreciate the benefits (on some systems) of giving only the local user access to removable media.  But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd.

> Dependencies like this actually create some force to adopt systemd.

Based on Lennart's and others' comments in this thread, forced adoption does not seem to be a goal.  But forced adoption is a reality due to dependencies like the one above.  I think there would be a lot less skepticism about systemd if the perception of forced adoption weren't so strong, and I'd love to see something done about this situation.

> Now I know ConsoleKit isn´t developed anymore, but also I never got why a
> logind implementation needs to depend on systemd base package in such a way
> that at least in Debian systemd package has to be installed if someone wants
> to use GNOME.

Is this what Debian's systemd-shim is for?  If not, well I'm going to talk about that anyway...

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.

Wouldn't the systemd developers prefer to have their implementation of this functionality be used, regardless of the chosen init system?

> > Let me stress this: constructive feedback is *always* welcome!

The following may not concern you personally, but Debian is attempting to support multiple kernels (Linux, BSD and Hurd I think).  As I understand it, systemd is Linux-only.  Defaulting to a Linux-only init system makes supporting non-Linux kernels more work, because an alternate init system must be maintained, as well as init scripts for that init system.  If functionality was separated as I described above, and the systemd project provided a very basic init-only package, would that be portable to non-Linux kernels?

> Users can also decide to help test the alternatives. Unlike other distros
> Debian still supports them.

But systemd's approach of incorporating additional "non-init" features into its init system (what some people mean when they say "monolithic") is making it difficult to support the alternatives.  Which is one reason I'm asking you to consider keeping the init portion of systemd and all the other stuff separately installable.  I see good benefits in all that other stuff for some/many applications.  In other applications sysvinit is jsut fine, in which case switching to systemd really just represents a waste of the sysadmin's resources because he has to learn new syntax/methodology/etc for no new functionality (that he cares about).

I hope that last paragraph didn't come across as too harsh.  I do mean all my criticisms to be constructive.

-Rob