Differences

This shows you the differences between two versions of the page.

--- en:philosophy:systemd_denial [2022/11/15 14:03]
throgh
+++ en:philosophy:systemd_denial [2022/11/18 12:37] (current)
throgh [Points for criticism in detail]
@@ Line 21: / Line 21: @@
 We will never address criticism making usage of personal attacks as we conclude neither being unfair nor using false argumentation methods. Besides there are many points to be found making it further a problem to use systemd for any system with lightweight focus.
-=== Breaking promises and immaturity ===
+=== Breaking promises ===
 “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”
@@ Line 32: / Line 32: @@
 http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html
-=== Stability Promises ===
+=== Stability failed ===
 "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."
@@ Line 39: / Line 39: @@
 <note>This stability promise was broken as one of their [[http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/|promises]] is for the [[http://www.freedesktop.org/wiki/Software/systemd/export/|export format]]: This is not true for version 44 of systemd for example!</note>
-=== Scope creep ===
+=== Scope of the project ===
 [[http://article.gmane.org/gmane.linux.hotplug.devel/17392|systemd includes udev]]
@@ Line 59: / Line 59: @@
 [[http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount|systemd includes mount]]
-=== Absurd Bugs and Responses ===
+=== Problematic bugs and responses ===
 [[https://bugs.freedesktop.org/show_bug.cgi?id=74589|Unchecked null pointer dereferencing in PID 1 not considered a serious issue]]]
@@ Line 102: / Line 102: @@
 [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394|systemd kills background processes after user logs out]]
-[[http://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is-broken.html|systemd-resolved is broken]]
-[[https://jdebp.eu/FGA/run-scripts-and-service-units-side-by-side.html|A side-by-side look at run scripts and service units]]
-=== Scope Creep Leads to Vulnerabilities ===
-=== Poor design ===
-=== Ignorance of fundamental operating system concepts ===
 ===== Conclusion for the Hyperbola-project =====
-In the retrospective of all the points listed here Hyperbola has the stance not to accept systemd. It is just the point that there are better alternatives fitting within the approach of a lightweight and stable context for a modern operating-system based on the essentials of the Unix philosophy. It is not a denial as we for sure just see no usecase for a so complex and also bloated piece of software to be used. Our ideal in this: **We search for alternative ways as it is an an achievement of civilization that not all need to be the same but treated nevertheless with fairness and therefore in conclusion the same way!**
+With the retrospective of all the points listed here Hyperbola has the stance not to accept systemd. It is just the point that there are better alternatives fitting within the approach of a lightweight and stable context for a modern operating-system based on the essentials of the Unix philosophy. It is not a denial as we for sure just see no usecase for a so complex and also bloated piece of software to be used. Our ideal in this: **We search for alternative ways as it is an an achievement of civilization that not all need to be the same but treated nevertheless with fairness and therefore in conclusion the same way!**
-So systemd has to persist the comparison towards other possible init-systems and in that way is for sure too big, too complex and too full with flaws.
-== Conceptional problems ==
-== Scope Creep Leads to Vulnerabilities ==
+So systemd has to persist the comparison towards other possible init-systems and in that way is for sure too big, too complex and full with flaws we don't want to accept as we would therefore need to be worried even on top of continuous upgrades for just one essential part. And even though every single point can be declared as solved or in some way older, we just don't want to use systemd as single-point for a failure as it just this simple.
-* [http://seclists.org/oss-sec/2014/q4/592 systemd-resolved DNS cache poisoning]
-* To run systemd properly in container a FUSE [https://linuxcontainers.org/lxcfs/introduction/ LXCFS] had to be created, and surely its own share of vulnerabilities:
-** [https://www.cvedetails.com/cve/CVE-2015-1342/ LXCFS before 0.12 does not properly enforce directory escapes] CVSS 4.6
-** [https://www.cvedetails.com/cve/CVE-2015-1344/ The do_write_pids function in lxcfs.c in LXCFS before 0.12 does not properly check permissions] CVSS 7.2
-* [https://latesthackingnews.com/2017/06/29/a-systemd-vulnerability-allows-attackers-hack-linux-machines-via-malicious-dns-response/ A Systemd Vulnerability Allows Attackers Hack Linux Machines via Malicious DNS response]
-== Poor design ==
-* [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/Slice_(disk) 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.  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
-* https://bugzilla.redhat.com/show_bug.cgi?id=1170765
-* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720
-* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 "Now you can no longer expect a long running background processes to continue after logging out. For example, you can no longer start a screen or tmux session, log out, and expect to come back to it."
-* https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ systemd's predictable NIC names are actually unpredictable...
-== Ignorance of fundamental operating system concepts ==
-* [http://lists.freedesktop.org/archives/systemd-devel/2015-February/028514.html Lead systemd developer doesn't understand RAID or checksum]
-* [https://github.com/systemd/systemd/issues/825#issuecomment-127917622 Lead systemd developer doesn't understand ''su'', expects it to do something else and then labels it a "broken concept"] - ''su'' isn't supposed to inherit cgroups or audit,  those concepts are relatively new and arrived well after the creation of ''su''.  TTYs were originally physical devices so of course ''su'' is supposed "inherit" the same device otherwise it would be truly broken.  Pseudo TTYs emulate real TTYs so their behaviour is obviously expected to be identical.  ''su'' really is just a simple mechanism that calls setuid(2) in order to switch to another user.  If he needs to write a new utility to handle scenarios that ''su'' was never designed to handle, no problem, but to label it as a "broken concept" demonstrates a lack of understanding of what ''su'' actually is.

Hyperbola GNU/Linux-Libre

HyperWiki

Differences