boycott systemd

systemd0 is a replacement for the sysvinit daemon used in GNU/Linux and Unix systems, originally authored by Lennart Poettering of Red Hat. It represents a monumental increase in complexity, an abhorrent and violent slap in the face to the Unix philosophy, and its inherent domineering and viral nature turns it into something akin to a "second kernel" that is spreading all across the Linux ecosystem.

This site aims to serve as a rundown and a wake-up call to take a stand against the widespread proliferation of systemd, to detail why it is harmful, and to persuade users to reject its use.

Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.


The Rundown
  1. 1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog and other things.

  2. 2. systemd's journal files (handled by journald) are stored in a complicated binary format2, and must be queried using journalctl. This makes journal logs potentially corruptable. Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well.

  3. 3. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.

  4. 4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago3.

  5. 5. By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using systemd-coredumpctl4. Besides going against all reason, it also creates complications in multi-user environments (for example, a university setting where students rely on running gdb to analyze core files), since systemd requires root to control. It assumes that users and admins are dumb5.

  6. 6. systemd's size makes it a single point of failure. As of this writing, systemd has had 9 CVE reports, since its inception in March 20106. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.

  7. 7. systemd is viral by its very nature. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps7. This means GNOME versions >=3.8 are incompatible with non-Linux systems, and due to GNOME's popularity, it will help tilt a lot of maintainers to add systemd. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. It's also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well - blatant coercion8.

  8. 8. systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system goes down. There are several ways that this can occur9. This happens to be another example of SPOF.

  9. 9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much10.

  10. 10. systemd's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the systemd API, or even patch systemd directly.

  11. 11. Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and is just anti-Unix in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.

External Resources and References

References

[0] http://www.freedesktop.org/wiki/Software/systemd/
[1] http://people.debian.org/~stapelberg/docs/systemd-dependencies.html
[2] http://www.freedesktop.org/wiki/Software/systemd/journal-files/
[3] https://lwn.net/Articles/490413/
[4] https://web.nvd.nist.gov/view/vuln/search-results?adv_search=true... [truncated; not all entries apply]
[5] http://www.freedesktop.org/software/systemd/man/systemd-coredumpctl.html
[6] https://unix.stackexchange.com/questions/65110/no-more-coredumps-after-migrating-to-systemd
[7] http://forums.gentoo.org/viewtopic-t-965660-start-0.html
[8] http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c?id=080ffcb4a124bd77054a3909bbd5f14d62f79b62
[9] http://ewontfix.com/14/
[10] http://lists.freedesktop.org/archives/systemd-devel/2011-July/002935.html

Articles critical of systemd


Lennart Poettering out doing what he does best

Send inquiries, feedback and suggestions to boycottsystemd@openmailbox.org