systemd is the best example of Suck.

There is a menace which is spreading like a disease throughout the Linux world, it is called systemd.

Short Historical Summary

systemd is a replacement for the standard init command, which normally runs as process id 1 on initialisation of a UNIX bootup. There has been a movement, especially around the Red Hat-related developers to copy Microsoft Windows and all of its features. Now this interpretation of how a userspace should look like is implemented and was introduced with big criticism and change in the Open Source world into many distributions. The debacle in Debian is the best example in how to not introduce such a changing technology into a distribution.

What PID 1 Should Do

When your system boots up the kernel is executing a given binary in its known namespace. To see what are the only tasks the application running as pid 1 has to do, see sinit. Just wait for child process to reap and run some other init scripts.

The systemd Chronicles

Now follows a collection of links related to all the features systemd tries to enforce upon you as a Linux user, because »they know better«.

Please add all the links you can find! Generations after us have to know how to not do software and system development! See the wiki instructions in how to contribute to this page.

The Never Ending Part

Your link here.

The SystemD Platform: an Unbiased Critique

Part 4

Part 3

NEWS revision 76153ad45f09b6ae45464f2e03d3afefbb4b2afe

from 2016-08-06

Part 2

Part 1

(If you are adding more parts, link to the right revision and not just the plain file.)

NEWS revision 3f80af378331748e1373d4c189a8e20cddb735c9

from 2015-07-31

Practical systemd

Here is what happens on a stock Arch Linux system, powered by systemd, when a non-root user tries to restart the system:

$ reboot Failed to set wall message, ignoring: The name org.freedesktop.PolicyKit1 was not provided by any .service files Failed to reboot system via logind: The name org.freedesktop.PolicyKit1 was not provided by any .service files Failed to talk to init daemon.

In contrast, here is the equivalent error message on a system powered by runit:

$ reboot init: fatal: unable to create /etc/runit/stopit: access denied

And on the oldest and best, Slackware:

$ reboot reboot: must be superuser.

systemd is driving "just google the problem" attitude, because how the hell are you expected to troubleshoot this kind of error otherwise?

Further Reading