[systemd-devel] What I think is really wrong with systemd

[Colin Guthrie]

I wouldn't normally grace such rants with a reply, but I'll try and keep
this one short.

dottomi at gmail.com wrote on 16/09/15 08:47:
> Hi, sorry for another rant, but I'm a software developer and a user of
> a Linux-based operating system here.
> 
> I read the post about at 0pointer.de about "myths about systemd". [1]
> I want to address the issue of it being monolithic.
> More specifically, I want to tell what where is that coming from.
> 
> systemd started an an init system. It had an idea of doing one thing
> "the proper way" - of system init on Linux-based systems.
> That made the project easy to understand and follow.
> 
> Now, as was written in that post, the project consists of over 69
> binaries, where most of them are entirely optional.
> 
> The problem with this project is not how it is written.
> It is how it is *packaged and distributed* to end-users.
> 
> Luckily, I use Gentoo. I have Portage, which will happily compile the
> package on my system and I can tell it by USE flags what to compile
> and what not to. Other package managers doesn't work this way. They
> fetch *pre-compiled packages*.

So basically you're complaining to the upstream systemd project about
how downstreams consume it?

You should really take this complaint to downstreams.

> Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server?
> A system logger? Something that uses QR codes? Can I replace it with
> another package?
> 
> The answer is: no one but the developers know.

Not true, the developers know, but also the downstream package
maintainers know too - or at least they should know. It's their job to
decide which components to use to build their operating system.

> The package doesn't even have an understandable version numbering. It
> is one increasing number. How is a package maintainer supposed to know
> if version change from 340 to 341 introduces major changes? I don't
> even know *what* changed unless I read a ChangeLog.

Package maintainers are *expected* to read the changelog. This isn't
some minor part of the operating system we're dealing with. These are
the key building blocks that make up the very base of the userspace
layer. If I'm using a distro, I want my package maintainer to at very
least read the changelog, but ideally be much more informed than even that!

> Normally, you have a major version and a minor version. If the major
> version changes, it is an alarm to do throught testing to see if
> everything works wellon the new one. Minor changes are minor, so they
> require less testing.

Minor, major etc., this doesn't matter. Even minor changes can introduce
major bugs. The fact that someone arbitrarily decided "this is a minor
change" doesn't make the change safe in any way. Testing of such key
components should be the same regardless. Adopting such a scheme in a
project like systemd serves no purpose but to create a fake illusion of
"safeness".

> What this project needs is division of this one big have-it-all
> package into individual packages, each containing components for a
> specific purpose. There is nothing wrong with them depending on each
> other, but they should be in different packages, each having a
> separate build system and version, for the following reasons:
> 
> 1) You as developers are more aware of what changes in the project,
>    beause commits are associated with individual componenets.

They already are, both in the commit message and simply by doing "git
log" in the appropriate folders.

> 2) If a component was a failure, you can just drop
>    the package and work on another - nothing else needs work.
>    Most importantly, the main component is not touched.

This can still happen and is irrelevant to how the git repo is structured.

> 3) The people that are not involved with the developement are more aware
>    what the suite of packages called systemd is actually composed of.
>    Package maintainers can now block one component if there is
>    something wrong with it, but not all the others.

If this is how downstream want to work (i.e. provide competing
component) then they can package things that way if they like. Doing it
upstream has no purpose other than adding overhead.

> 4) The user can then install the init system from systemd, and keep
>    their system logger. Example: systemd-logind should not pass the
>    messages to another logger. The other projects should be encouraged
>    to use systemd APIs/ABIs on Linux to get them.
>    This makes systemd-logind more lightweight.

This shouldn't really be about user choice, but distributor choice.
Distributors are welcome to package things as they wish within the basic
constructs.

Your example doesn't make sense. systemd-logind already does not pass
message to another logger, it uses the journal exclusively.

> 5) Most importantly: by such a split you future-proof the project
>    as a whole. Someone might come up with a better solution for
>    a component than you in the future. That someone should not fight
>    with your system in order to use other components. It should be made
>    easy and simple to replace any binary systemd uses now
>    with another - with another PACKAGE.


Again, this is something that is for downstream packagers.


None of these reasons identify anything that really needs to change
upstream.

Also, you have to keep in mind that a shared codebase creates much less
overhead and problems. There is a lot of internal code used by all
components in system that is in private APIs. Splitting out the project
to separate sub-projects would mean committing to API and ABI stability
on much of this code. This is a huge burden and not something to
undertake lightly.

The downstream distributions can do things as you describe now without
the need to split things out as you describe.

> If systemd keeps going the way it does, it will eventually get forked,
> because it will become an unmaintainable mess when you notice
> something major in the system could be done better, and that better
> approach breaks everything else in the system. systemd works fine.
> NOW. I also would want it to work after 20 years, because I see good
> ideas here.

It's precisely because it's all in one place that allows changes to be
made in lockstep and all dependent code updated. If the changes you
mention were related to public API then all the sub-compoenents would
still break but you'd have to go around and update them all separately.
Bisecting history would be a nightmare when searching for regressions
etc. and ultimately this makes things less manageable.

> Actually, I think this project's future is a "Linux-based Init and
> Service Management System Standard", where the systemd suite
> of packages is the reference implementation.

Perhaps it is. If any project wants to provide alternatives to any
component they are free to do so. If a downstream distributor wants to
use that component over systemd's one, they are free to do so. If they
want to offer the user a choice of which one to use, they are free to do so.

Basically, tl;dr, I think some of your comments about what components
people may want to use are valid enough, but I think that none of them
form a basis to change anything in the way systemd codebase *upstream*
is managed. It might make sense to change how it's consumed downstream,
but that doesn't really affect the upstream project.

All the best

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/