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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 22, 2014 at 10:16:36AM -0400, Dale R. Worley wrote:
> > From: "Jóhann B. Guðmundsson"
> 
> > > Did you ever ask yourself why your project provokes that amount of
> > > resistance and polarity? Did you ever ask yourself whether this
> > > really is just resistance against anything new from people who
> > > just do not like "new" or whether it contains*valuable*
> > > and*important* feedback?
> > 
> > I'm not sure why you are under the assumption that we do not consider 
> > and have not and are not gathering feedback from individuals, 
> > communities or companies for that matter but I'm going to address your 
> > questions anyway.
> 
> I've brought a complaint about one of systemd's behaviors here.  I
> have gotten useful feedback allowing me to refine what I think would
> be a good solution to the problem.  What I *haven't* gotten is any
> useful feedback on how to implement a solution.  I suspect others have
> had similar experiences.
>
> One metric that might be useful is to ask:  Of the people who complain
> about one or another aspect of systemd, what fraction ultimately
> consider their complaint to be satisfactorily resolved?
Hm, if you looked at any of the bugtrackers, most systemd issues are
resolved (e.g. on bugs.freedesktop.org we have about 140 of of 950
issues still opened). Most of the time they are actually fixed, and
the ones that are left open are either RFEs or more complicated issues.

> There are also "architectural" issues about systemd that I've
> noticed.  I don't know to what degree these indicate quality control
> problems with the code, or whether they are just a matter of things
> being done in ways that are not common in the Un*x universe.  But they
> do seem to me to be things that are going to inhibit adoption.
> 
> 1. Systemd has some very large binaries, each of which implements many
> aspects of the system.  Conversely, the typical Un*x approach is to
> separate functions into many executablels, many of which are scripts.
> The latter approach makes customization easier, especially for
> sysadmins who aren't deeply familiar with the system.
Actually, based on what I've read e.g. in the UNIX haters' handbook,
the idea of separating into many separate binaries wasn't all that
common in UNIX. Also, historically programs used to be real binaries,
not scripts.

More seriously, the idea of having shell scripts which you're going
to modify to customize your setup is simply crazy. How robust would
your changes be? How would you ever handle upgrades? How would more
than one admin manage a machine without sitting in the same room?

I don't know where you get the idea that systemd has "big binaries".
Existing source code compiles to ~140 binaries and a few libraries.
Many of them are really tiny, a few that do more complicated things
are bigger. And things are very much separated by function between
daemons.

> 2. Systemd includes a tremendous number of features and behaviors, but
> a lot of them aren't documented very well.  That's not so unusual in
> Un*x, but if you're introducing something new, nobody has any prior
> knowledge of it, and the lack of documentation becomes visible.
Again, this seems rather ignorant of the status quo. Between the blog
posts and wiki documentation and the 164 man pages, systemd is rather
copiously documented. Not to say that things can't be improved, but
by Linux standards we are at least making an effort. Bugs for missing
or unclear documentation and usually handled, and any patches for
documentation are applied fairly quickly.

> Ultimately, writing e-mail messages saying "They're wrong" is useless,
> even if they *are* wrong.  If there is a substantial body of people
> out there who dislike systemd, it's going to prevent its adoption.
> The fix is adjusting systemd (or the project surrounding it) so that
> people like it better.
Sometimes, sometimes not. Doing everything that is requested, especially
by newcomers to the project, would quickly cause the project to
lose focus and consistency and turn into an unmaintainable mess.

Zbyszek