Arguments against systemd

From Without Systemd
(Difference between revisions)
Jump to: navigation, search
(Poor design)
m (Poor design)
Line 80: Line 80:
 
* [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10 Improper argument parsing]
 
* [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10 Improper argument parsing]
 
* [http://www.freedesktop.org/software/systemd/man/systemd.special.html systemd has a filename that starts with a hyphen!] - This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don't even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, "-.slice", they refer to as the "root slice" which causes confusion as the term "slice" has been used for decades as an alternative way of referring to a [https://en.wikipedia.org/wiki/Disk_partitioning#Notes disk partition] yet their usage is completely unrelated.
 
* [http://www.freedesktop.org/software/systemd/man/systemd.special.html systemd has a filename that starts with a hyphen!] - This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don't even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, "-.slice", they refer to as the "root slice" which causes confusion as the term "slice" has been used for decades as an alternative way of referring to a [https://en.wikipedia.org/wiki/Disk_partitioning#Notes disk partition] yet their usage is completely unrelated.
* [https://news.ycombinator.com/item?id=10999335 Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'] See also [https://bbs.archlinux.org/viewtopic.php?id=207549 No POST after rm -rf /] - Lennart's argument for mounting ''/sys/firmware/efi/efivars'' as read/write as a default behaviour doesn't hold water. Yes it's true that some tools may need to write to it but those tools are not needed for the general running of a system. ''efivars'' should not even be mounted as read-only by default. Those tools that need to write to ''efivars'' will generally only be invoked by a system administrator. A competent sysadmin will know how to mount ''efivars'' with read/write permissions when they need to to use those tools. There only reason to mount ''efivars'' by default is for convenience. This is by no means a good reason. From a security perspective, mounting ''efivars'' by default should be strongly discouraged as it breaks the [https://en.wikipedia.org/wiki/Principle_of_least_privilege principle of least privilege]. Lennart goes on to state that [https://github.com/systemd/systemd/issues/2402#issuecomment-177907110 systemd needs to write EFI variables]. This demonstrates yet another example of scope creep and thus poor design.
+
* [https://news.ycombinator.com/item?id=10999335 Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'] See also [https://bbs.archlinux.org/viewtopic.php?id=207549 No POST after rm -rf /] - Lennart's argument for mounting ''/sys/firmware/efi/efivars'' as read/write as a default behaviour doesn't hold water. Yes it's true that some tools may need to write to it but those tools are not needed for the general running of a system. ''efivars'' should not even be mounted as read-only by default. Those tools that need to write to ''efivars'' will generally only be invoked by a system administrator. A competent sysadmin will know how to mount ''efivars'' with read/write permissions when they need to to use those tools. The only reason to mount ''efivars'' by default is for convenience. This is by no means a good reason. From a security perspective, mounting ''efivars'' by default should be strongly discouraged as it breaks the [https://en.wikipedia.org/wiki/Principle_of_least_privilege principle of least privilege]. Lennart goes on to state that [https://github.com/systemd/systemd/issues/2402#issuecomment-177907110 systemd needs to write EFI variables]. This demonstrates yet another example of scope creep and thus poor design.
 
* http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=28640752854
 
* http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=28640752854
 
* https://bugzilla.redhat.com/show_bug.cgi?id=1170765
 
* https://bugzilla.redhat.com/show_bug.cgi?id=1170765

Revision as of 23:43, 6 February 2016

Contents


Links

Breaking promises and immaturity

"After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time"

"...this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call."

Linux (kernel) coup attempt: "kdbus support is no longer compile-time optional ... We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled." comment on this on LKML

Stability Promises

To quote from the systemd stability promise:

"Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future."

One of their promises is for the export format:

"Entry metadata that is not actually a field is serialized like it was a field, but beginning with two underscores. "

This is not true for version 44 of systemd for example.

Scope creep

Absurd Bugs and Responses

Scope Creep Leads to Vulnerabilities

Poor design

Myths

Debunking the myth of unit files being significantly shorter than scripts used by all other init systems: A side-by-side look at run scripts and service units

Ignorance of fundamental operating system concepts

Personal tools