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

[dottomi at gmail.com]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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*.

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.

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.

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.

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.
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.
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.
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.
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.

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.

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.

[1] http://0pointer.de/blog/projects/the-biggest-myths.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV+R5zAAoJEDRBz9VZHKuW2psQAKiqMb0H8djvKcWanKsYguIg
pUFp2e32rHUGMW7DVtF1pk18rYygq+6vOgi+ACQVLlHOL0nOxhwyjqSkfhVF/Ew6
p6worj+PZIuHiEE6VwMZ9v7ptlPFniLQc73avPv7661YpC7DIsQGlV5GmtmR+Q73
LwQsAm82f1NR8Oh8Ud0MgJRVBpY9NYAmN0PSJnSxfYmmx4epO9MtLAf0aG4pnhKc
13EmVcD3N+bkHk8jWo4X3o1DiDDDJ/afWBIqbHxd0Z7o9JHn2YCyAWcC4t0DO2Tu
vUvlzhced8jfFMua+323XNXzSP6BsRoDWiit4qTXGW8ptXW1VNc3wRLtef4i3Jao
6owtN7NIaYHRAKymUJUad5XH7a6EwcOBu3wtZ0jAJMa/1MdmG1VPtXUVobEAzCEj
vjm+X0aJMB5JkOPkmT9szm0QSQh0Uj4Cme3e6GwTppteZNga9s1OV068zB/gdDIB
y7bHHSO6d4AN4tFQXYyX7P0cBsQ3HWIaqn+IIDnPEz/hwNeh+6yEHPzdktWX5ksg
Z4V7IkVOHYS60ejlldhavNOM2fF/57OTC9HtWjU1cbjithKzNzbLmTzbpt/UI6Ha
LVFqQnKLqwfMvP+IQMlE4+rTaBa7Jl/VgQaogxScO1W1TBV+Nf4IIubob7BTR834
Mv1H1NT/S3+rp98uMTud
=6YJT
-----END PGP SIGNATURE-----