HyperWiki

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
en:philosophy:systemd_denial [2022/11/03 14:02]
throgh 		en:philosophy:systemd_denial [2022/11/18 12:37] (current)
throgh [Points for criticism in detail]
Line 3: Line 3:
 We are surely aware about the criticism towards systemd as project. But this article should not only be focussed onto that and be therefore more oriented towards our reasoning for a system beyond using only bloated packages and frameworks. So we could now list for sure many reasons why we stay critical towards the adaption for systemd as basic init-framework, but we want to provide a complete picture. We are surely aware about the criticism towards systemd as project. But this article should not only be focussed onto that and be therefore more oriented towards our reasoning for a system beyond using only bloated packages and frameworks. So we could now list for sure many reasons why we stay critical towards the adaption for systemd as basic init-framework, but we want to provide a complete picture.
  
-====== Systemd denial ======+===== Introduction =====
  
-Obarun compromises neither principles nor finctionality!+systemd was initially first started back in 2010 as a project to replace the conventional System V init. It was then developed further to be now a "software suite providing an array of system components for GNU/Linux". And with this short but fitting description there is the first major issue as the project is only aiming towards GNU/Linux as basic and is very much more than a pure init-startup for the operating-system. It provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging.
  
-I feel like I have found a real hidden gem with Obarun.+As Hyperbola is created as pure lightweight system the orientation of systemd is not following the [[:social_contract|Social Contract]] to **respect modular and lightweight design**. This was announced within 2017 in a dedicated [[https://www.hyperbola.info/news/end-of-systemd-support/|news-entry]].
  
-I'm not a huge fan of SystemD, not because it's slow or anything, mostly ideological reasons. Plus I find Distributions that choose no to use it make other choices I like, such as being more minimalistic.+With the essential design-decision being just more than only init and management systemd has also included more attack surfaces and further security-issues. To be mentioned there are dereferencing null pointers ([[https://github.com/systemd/systemd/pull/5998|Issue 5998]]), or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number ([[https://github.com/systemd/systemd/issues/6237|Issue 6237]]). Yes, all of them solved or handled in other ways. But a big codebase of a project like systemd is staying also complete intransparent for everyone with not a big amount of time and the reaction of maintainers behind the project are also not that kind of helpful: Communication is a basic element for a good project oriented onto **technical emancipation** as this is the absolute basic for free culture and free, libre software on its own.
  
-I went to through great efforts trying to remove SystemD completely from Gentoo (as you may be aware, it uses elogind and quite a bit of SystemD code even when using OpenEC as init). I got it done, sure, but at the cost ofba great deal of functionality. No elogind, no steam or firefox for you!+===== Back and forth: The role of init-systems =====
  
-So down the rabbit hole, finding out most supposedly systemd free distros use great quantities of SystemD code. Very disappointing, why bother avoiding SystemD if you aren't going to follow through?+There are different approaches followed by the different systems and distributions. Nevertheless the key-role of an init-system is just to start the basic system and initialize the services. Afterwards it is about a supervisor to look behind the services running and removing those crashed ([[https://ewontfix.com/14/|Broken by design: systemd]]) .
  
-I find a lot of Distros that go the extra mile, but seems very difficult may be accused of being "memes" such as Kiss linux and whatnot. They look quite fun, but i need something less alien.+Again the size and the understanding of systemd in a whole is here the major point for issues: Too many components integrated, too many design-flaws within and too less transparency. Hyperbola has chosen for a reason to follow strict the [[en:project:fhs|Filesystem Hierarchy Standard]]. It would not be possible with adaption of systemd and leaving a complete mess for a structured, lightweight operating-system to follow the [[https://en.wikipedia.org/wiki/Unix_philosophy|Unix philosophy]]. Therefore the conclusion to follow the [[https://wiki.hyperbola.info/doku.php?id=en:start#what_is_the_init_freedom_campaign|Init Freedom Campaign]].
  
-I stumble upon Obarun. The Arch base is comforting since I know Arch well, and s6 is intriguing. No SystemD nonsense whatsoever! I try it instantly! Some growing pains, s6 is pretty tricky compared to others.+===== Points for criticism in detail =====
  
 +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.
  
-22nd June 2018: Renaming Network Interfaces.</h3> +=== Breaking promises ===
-<div class="col-lg-10 col-lg-offset-1 text-left"> +
-<p> +
-As announced in the systemd mailing list, <a href="https://lwn.net/Articles/758128/" target="_blank" rel="nofollow">version 239 of systemd +
-will name network interfaces differently than in previous versions</a>.</p> +
-<p>Because breaking the name of my network adapter is exactly what I was asking for.</p> +
-<p>There are a whole set of other changes in the same announcement which should make it clear to any sane person contemplating switching +
-over to this system that it is not yet ready for production use. The definitions of blacklist/whitelist have swapped over; a hibernate update +
-notes that "swap files should work for hibernation now." - because it's absolutely fine to "support" hibernation for years, for 239 releases, without +
-hibernation actually, well, working+
  
-https://pwnies.com/winners/">pwnie awards</a> awarded systemd its "Lamest Vendor" prize in 2017, due to its handling of bugs <a target="_blank" rel="nofollow" href="https://github.com/systemd/systemd/issues/5998">5998</a>, <a target="_blank" rel="nofollow" href="https://github.com/systemd/systemd/issues/6225">6225</a>, <a target="_blank" rel="nofollow" href="https://github.com/systemd/systemd/issues/6214">6214</a>, <a target="_blank" rel="nofollow" href="https://github.com/systemd/systemd/issues/5144">5144</a>, and <a target="_blank" rel="nofollow" href="https://github.com/systemd/systemd/issues/6237">6237</a>. The Register <a target="_blank" rel="nofollow" href="https://www.theregister.co.uk/2017/07/28/black_hat_pwnie_awards/">has more details</a>.</p> +“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” 
-</div> +http://article.gmane.org/gmane.linux.hotplug.devel/17392
-</div> <!-- /row -->+
  
 +”…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.'“
 +http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
  
 +“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.”
 +http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html
  
-<div class="row" id="dynamicusers"><h3>Dynamic Users</h3><div class="col-lg-10 col-lg-offset-1 text-left"> +=== Stability failed ===
-<p>Dynamic Users is a feature added between v232 and v235 of systemd. There's a <a target="_blank" rel="nofollow" href="http://0pointer.net/blog/dynamic-users-with-systemd.html"</a>blog post by Poettering here</a>.</p> +
-<p>What is a Dynamic User, you ask?</p> +
-<p>Well, it's a system account which is created when the service starts, and is deleted, along with all the files owned by that user, when it stops. And yeah, that's about as stupid and dangerous as you might imagine it to be. It claims that it avoids the "problem" (have you ever encountered this problem?) with the numerical limit on available UIDs and GIDs, yet it also allows for persistent directories - you know, just in case you wanted your data to still be there after you've restarted the service! (some people are *so* fussy about actually *keeping* their data, I don't know!).</p> +
-<p>But it keeps them hidden under "chmod 0700" root-owned directories. Then they realised that if you start the service up again, and another process has taken your previous UID, then they'll have to do a recursive "chown -R" on your data, so you'll just have to wait for that to complete before you can start the task of actually starting up your application. Heaven forbid it'd be a large amount of data, or on a slow, or read-only, or remote media such as NFS.</p> +
-<p>Given systemd's history in terms of security and protection of user data (that is, the designers simply don't care about such things), it will only be a matter of time (<B>the blog post above was 6/10/17; this rant was written on 17/10/17; I'll try to remember to update this piece when I hear of the first example of inadvertent data loss or exposure caused by systemd as soon as I hear of it</b>) until this implementation loses somebody their data. That is, if anybody is stupid enough to make use of this "feature" in the first place. Which does seem unlikely, since it's solving a problem that nobody has ever reported. Ever.</p>+
  
 +"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."
 +http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/
  
->DNS</h3><div class="col-lg-10 col-lg-offset-1 text-left"> +<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>
-<p><a target="_blank" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-15908">CVE 2017-15908</a> has the full details, and you can read a bit more in plain-English <a target="_blank" rel="nofollow" href="https://usn.ubuntu.com/usn/usn-3466-1/">from Ubuntu</a>, but in a nutshell: a given DNS response (so far, I believe, the details have not been made public) will cause systemd to hang entirely. So a total Denial of Service (DoS) attack on your ability to manage your system.</p> +
-<p>Wow - nobody ever warned that there was a massive danger inherent in putting so much arbitrary code into <code>PID 1</code>, did they?</p> +
-<p>Oh, wait. They did. Yes. Absolutely everybody did warn them about this huge, monolithic, unwieldly <code>PID 1</code> process taking control of so may existing subsystems, with the potential for new bugs in any one of them to affect the stability of the entire system. Many times. We did that. But systemd rolled on anyway. And broke a lot of systems for a lot of people.+
  
 +=== Scope of the project ===
  
-https://ewontfix.com/14/ +[[http://article.gmane.org/gmane.linux.hotplug.devel/17392|systemd includes udev]]
-https://suckless.org/sucks/systemd/ +
-https://the-world-after-systemd.ungleich.ch/+
  
 +[[http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html|systemd takes over logging with a binary format]]
  
- <h2>What is so bad about systemd?</h2> +[[http://www.phoronix.com/scan.php?page=news_item&px=systemd-networkd-IP-Forward|systemd Gains IP Forwarding, IP Masquerading & Basic Firewall Controls]]
- <p>List of notable bugs and security issues:</p> +
- <ul> +
- <li><a href="https://github.com/systemd/systemd/issues/437">#437: timeX.google.com provide non standard time</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/1143">#1143: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/1312">#1312: restarting systemd service on dependency failure</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/1596">#1596: journalctl -r -n flags incorrectly processed</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/2402">#2402: Mount efivarfs read-only</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/2460">#2460: Showing status of service via systemctl is slow (>10s) if disk journal is used</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/4863">#4863: systemd-journald drops all bytes after '\0'</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/5644">#5644: tmpfiles: R! /dir/.* destroys root</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/6237">#6237: systemd can't handle the process previlege that belongs to user name startswith number, such as 0day</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/6369">#6369: hostnamed does not like fqdns with trailing dots</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/6381">#6381: systemd-cryptsetup: Booting with encrypted root partition fails instantly</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/6478">#6478: `systemctl` should not consider active->failed as a successful operation</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/6620">#6620: services writing to stdout become silent after journal restart</a></li> +
- <li><a href="https://github.com/systemd/systemd/pull/7184">#7184: resolved: fix loop on packets with pseudo dns types</a> (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15908">CVE-2017-15908</a>)</li> +
- <li><a href="https://github.com/systemd/systemd/issues/8579">#8579: systemd breaks my mouse</a></li> +
- <li><a href="https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795921">Out-of-Bounds write in systemd-networkd dhcpv6 option handling</a> (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15688">CVE-2018-15688</a>)</li> +
- <li><a href="https://github.com/systemd/systemd/issues/6078#issuecomment-308240231">#6078: Applying systemd-networkd configuration disconnects all other interfaces</a></li> +
- <li><a href="https://www.openwall.com/lists/oss-security/2019/01/09/3">System Down: A systemd-journald exploit (CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866)</a></li> +
- <li><a href="https://github.com/systemd/systemd/issues/11810#issuecomment-489727505">#11810: Can't suspend again after suspending one time</a> (<a href="https://twitter.com/FiloSottile/status/1125840275346198529">explanation why this is bad</a>)</li> +
- <li><a href="https://bugs.freedesktop.org/show_bug.cgi?id=72759">Systemd user manager interferes with ecryptfs - private directory not being unmounted</a> (also <a href="https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/313812">umount of ecryptfs does not automatically clear the keyring</a> and <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854">ecryptfs-utils: Private directory not automatically unmounted anymore on logout</a>)</li> +
- </ul>+
  
- <p>Other issues arising around systemd:</p> +[[http://www.phoronix.com/scan.php?page=news_item&px=systemd-Gummiboot-Boot-Loader|Gummiboot UEFI Boot Loader to be added in systemd]]
- <ul> +
- <li><a href="https://github.com/systemd/systemd/pull/15206">systemd will be able to kill a process if he needs/wants more RAM</a></li> +
- <li><a href="https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html">We need to enforce the use of systemd to everyone, by the creator of systemd itself.</a></li> +
- <li><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394">systemd kill background processes after user logs out</a> (see also: <a href="https://github.com/tmux/tmux/issues/428">[RFE] add a way to run in a new systemd scope automatically</a>)</li> +
- <li><a href="https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/">Don't panic, but Linux's Systemd can be pwned via an evil DNS query</a></li> +
- <li><a href="https://isc.sans.edu/forums/diary/Systemd+Could+Fallback+to+Google+DNS/22516/">Systemd Could Fallback to Google DNS?</a></li> +
- <li><a href="https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1713457">DNS search domain not removed from resolv.conf on disconnect</a></li> +
- <li><a href="https://fredrikaverpil.github.io/2016/04/27/systemd-and-resource-limits/">systemd does not respect system wide resource limits</a></li> +
- </ul>+
  
- <h2>How do I get rid of systemd?</h2> +[[http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html|systemd includes DNS-cache]]
- <p>Free your system by replacing systemd with an alternative init system. Here are a few guides on how to do that:</p>+
  
- <ul+[[http://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.service.html|systemd includes web server]]
  
-https://without-systemd.org/wiki/index_php/Arguments_against_systemd/:+[[https://github.com/tmux/tmux/issues/428|developer asks tmux to add systemd specific code]]
  
 +[[https://lists.fedoraproject.org/pipermail/devel/2012-October/172163.html|systemd requires HTTP server and serves QR codes]]
  
-__TOC__ +[[http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount|systemd includes mount]]
-== Links == +
-* [http://fromthecodefront.blogspot.in/2017/10/systemd-no.html systemd: Please, No, Not Like This] (October 2017)  +
-* [http://ewontfix.com/14/ EWONTFIX - Broken by design: systemd] +
-* [http://ewontfix.com/15/ EWONTFIX - Systemd has 6 service startup notification types, and they're all wrong] +
-* [https://pwnies.com/winners/#lamestvendor Lamest Vendor Response 2017 #PwnieAwards goes to Lennart Poettering for SystemD f*ckups] [https://twitter.com/dalmoz_/status/890397041674911745/photo/1 photo] +
-* [http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt Patrick's playground - Systemd propaganda: It's a crap!] +
-* [http://draketo.de/light/english/top-5-systemd-troubles Top 5 systemd troubles - a strategic view for distros] +
-* [http://wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd Systemd? More like Shit-stemd] +
-* [http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdCrashAndMore The bad side of systemd: two recent systemd failures] +
-* [http://landley.net/notes-2014.html#23-04-2014 "...There are several problems with systemd unrelated to code quality..."] +
-* [http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html Systemd: The Biggest Fallacies] +
-* [https://forums.bunsenlabs.org/viewtopic.php?id=4346 Fast boot?] in-the-wild discussion (workarounding slow OOTB systemd boot) "Performance tuning the boot process" +
-* [http://news.dieweltistgarnichtso.net/posts/systemd-assumptions-bullying-consent.html systemd: Assumptions, Bullying, Consent] +
-* [https://lkml.org/lkml/2014/8/12/459 Open letter to the Linux World] +
-* [http://fromthecodefront.blogspot.in/2017/07/systemd-pitfalls.html systemd pitfalls] (July 2017) +
-* [http://mrpogson.com/2015/02/09/systemd-or-poettering-name-your-poison/ systemd Or Poettering, Name Your Poison] +
-* [http://forums.debian.net/viewtopic.php?f=20&t=120652&p=570371 Combatting revisionist history] +
-* [[Local copy of boycottsystemd.org archive]] +
-* [https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/ Ts’o and Linus And The Impotent Rage Against systemd] +
-* [https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU A realization that I recently came to while discussing the whole systemd controversy...] +
-* [http://neofutur.net/systemd-vault systemd vault - Everything you need to fully understand the systemd problem] +
-* [http://louwrentius.com/systemd-forward-secure-sealing-of-system-logs-makes-little-sense.html Systemd Forward Secure Sealing of System Logs Makes Little Sense] +
-* [http://blog.gerhards.net/2011/11/journald-and-rsyslog.html journald and rsyslog] +
-* [http://blog.gerhards.net/2011/11/what-i-dont-like-about-journald.html What I don't like about journald / Linux Journal] +
-* [http://blog.gerhards.net/2012/01/disappointing-press-reactions.html Disappointing press reactions...] +
-* [http://www.steven-mcdonald.id.au/articles/systemd.shtml Why I dislike systemd] +
-* [https://muchweb.me/systemd-nsa-attempt/ Is `systemd` an NSA attempt?] +
-* [http://suckless.org/sucks/systemd Systemd is the best example of Suck] (suckless.org) "There is a menace which is spreading like a disease throughout the Linux world, it is called systemd." +
-* [http://blog.darknedgy.net/technology/2015/10/11/0/ Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise] +
-* [http://pappp.net/?p=969 PAPPP's ramblings - Linux Future (how systemd is not like Unix)] +
-* [https://github.com/coreos/rkt/issues/576 Systemd requiring CAP_SYS_ADMIN weakening container safety in coreOS/rkt] +
-* [https://bsdmag.org/randy_w_3/ Problems with Systemd and Why I like BSD Init by Randy Westlund] +
-* [https://www.ubuntubsd.org/wiki:why_not_systemd ubuntubsd.org article titled "Why Systemd is so bad?"] +
-* [https://www.jordynsblog.org/index.php/2017/04/30/the-reasons-why-i-hate-systemd/ The reasons why I hate systemd] +
-* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#20 Debian Bug #668001 "debootstrap: cant install systemd instead of sysvinit"] (2014 mailing list thread, 100+ msgs)<br> +
-[[File:the_new_order.jpg]] +
-== Breaking promises and immaturity == +
-[http://article.gmane.org/gmane.linux.hotplug.devel/17392 "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"] +
-[http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html "...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: [http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html "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."] [http://lkml.iu.edu/hypermail/linux/kernel/1506.2/03764.html comment on this on LKML ] +
-[https://lwn.net/Articles/641275/ "The kdbuswreck"] +
-[https://github.com/systemd/kdbus "kdbus now out-of-tree"] +
-[https://en.wikipedia.org/wiki/D-Bus#kdbus "kdbus dropped in favor of BUS1"] +
-=== Stability Promises === +
-To quote from the systemd [http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ 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 [http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ promises] is for the [http://www.freedesktop.org/wiki/Software/systemd/export/ 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 == +
-* [http://article.gmane.org/gmane.linux.hotplug.devel/17392 systemd assimilates udev] +
-* [http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html systemd takes over logging] (and as if that wasn't bad enough, it uses a binary format) +
-* [http://www.phoronix.com/scan.php?page=news_item&px=systemd-networkd-IP-Forward Systemd Gains IP Forwarding, IP Masquerading & Basic Firewall Controls] +
-* [http://www.phoronix.com/scan.php?page=news_item&px=systemd-Gummiboot-Boot-Loader Gummiboot UEFI Boot Loader To Be Added To Systemd] +
-* [http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html DNS cache]  --- [https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html systemd-resolved] +
-* [http://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.service.html web server] +
-* [https://github.com/tmux/tmux/issues/428 Systemd developer asks tmux to add systemd specific code] +
-* An init system that requires even on a server a library for rendering QR codes: Post in [https://www.heise.de/forum/iX/News-Kommentare/Red-Hat-Enterprise-Linux-for-SAP-Solutions/Neulich-auf-einem-RedHat-Server/posting-31123843/show/ Heise Forum] and reference in [https://lists.fedoraproject.org/pipermail/devel/2012-October/172163.html Fedora] +
-* [http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount Systemd assimilates mount]<br> +
-[[File:Systemd_anigif.gif]]<br><br>[[File:Systemd_scopecreep_chart.png]]<br><br> +
-== Absurd Bugs and Responses == +
-* [https://bugs.freedesktop.org/show_bug.cgi?id=74589 Unchecked null pointer dereferencing in PID 1 not considered a serious issue] - <i>"To make this work we'd need a patch, as nobody of us tests this."</i>, <i>"I will not work on this"</i> - Systemd <b>requires</b> cgroups and segfaults if there is no cgroups support. +
-* [http://www.phoronix.com/scan.php?page=news_item&px=MTYwMzg Screen locking issues (including a security issue) with gnome-shell] - remained unfixed for over a year] +
-* [http://soylentnews.org/article.pl?sid=14/12/21/1343258 PID 1 segfaulting on upgrade; journalctl usability issue] - bug report still marked as "NEW" +
-* [https://lists.debian.org/debian-user/2015/02/msg00010.html "Tried to boot my laptop from a cafe..."] +
-* [https://bugzilla.opensuse.org/show_bug.cgi?id=918226 systemd segfaults after updating from 208-23.3 to 208-28.1] +
-* [https://github.com/systemd/systemd/issues/2402 Mount efivarfs read-only] - Doing rm -rf / bricks your computer +
-* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171 Unable to shutdown] +
-* [https://bugs.freedesktop.org/show_bug.cgi?id=61191 journald eats up CPU] +
-* [https://bugs.freedesktop.org/show_bug.cgi?id=64116 Corrupted binary logs] +
-* [https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet How to Crash Systemd in One Tweet] (works as any user, not just root) and [https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d response] and [https://www.agwa.name/blog/post/systemd_is_not_magic_security_dust rebuttal] +
-* [http://www.openwall.com/lists/oss-security/2017/01/24/4 Systemd v228 local root exploit] +
-* [https://github.com/systemd/systemd/issues/5644 tmpfiles: R! /dir/.* destroys root] See also [https://www.preining.info/blog/2017/04/systemd-again/ Systemd again (or how to obliterate your system)], Poettering's response: <i>"I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?"</i> (Hint: no.) +
-* [https://github.com/systemd/systemd/issues/6237 systemd can't handle the process previlege that belongs to user name startswith number, such as 0day] Poettering: "not a bug, a feature" +
-* [https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime systemd Using 4GB RAM After 18 Days of Uptime] +
-== Conceptional problems == +
-* [http://soylentnews.org/article.pl?sid=14/12/21/0145243 Systemd Prevents the Skipping of fsck while Booting] - still unresolved +
-* [http://soylentnews.org/article.pl?sid=14/12/21/1554227 Systemd Disables the Linux Magic SysRq Key] - closed as "NOTABUG" +
-* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 Please do not default to using Google nameservers] - Debian package maintainer refuses to acknowledge the privacy leak and closed the bug. +
-* [https://github.com/systemd/systemd/issues/437 timeX.google.com provide non standard time] - Horrible default behaviour but Lennart tries to shift the blame on distros because "systemd is not a product". +
-* [https://bugs.freedesktop.org/show_bug.cgi?id=76935 Do not parse "debug" command line parameter] - [https://lkml.org/lkml/2014/4/2/415 Response on LKML] Response: [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c2 That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.] +
-* [https://github.com/systemd/systemd/issues/2447 journal ip anonymization] - It's very difficult to use systemd/journal on a privacy aware system or infrastructure. +
-* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 systemd kill background processes after user logs out] - Poettering's answer: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XW7V5A3RAWYCACU2ZMPA27ARRLIZUI37/ In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.] +
-* [http://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is-broken.html systemd-resolved is broken] - doing DNS resolve wrong, with the [https://github.com/systemd/systemd/issues/5755 usual attitude towards feedback] +
-Debunking the myth of unit files being significantly shorter than scripts used by all other init systems: [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 == +
-* [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.+
  
 +=== 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]]]
  
-maybe use already installed sync plugin to pull resources from devuan wiki+[[http://www.phoronix.com/scan.php?page=news_item&px=MTYwMzg|Screen locking issues (including a security issue) with gnome-shell remains unfixed]]
  
-As systemd doesn't follow our Social Contract, we have decided to remove it and use OpenRC as our default init system. The decision means that the Stable v0.1 will be the first and the last version supporting systemd.+[[http://soylentnews.org/article.pl?sid=14/12/21/1343258|PID 1 segfaulting on upgrade; journalctl usability issue]]
  
-To ease the transition, systemd support will remain in the stable repositories for the time being, while we are removing it in the Testing version and creating our OpenRC migration guide. As of Stable v0.2 release, systemd support will be completely removed without further notice.+[[https://lists.debian.org/debian-user/2015/02/msg00010.html|Fail boot for the computer as systemd demands strict sequences]]
  
-Further details:+[[https://bugzilla.opensuse.org/show_bug.cgi?id=918226|systemd segfaults after updating from 208-23.3 to 208-28.1]]
  
-    Unchecked null pointer dereferencing in PID 1 not considered a serious issue (https://bugs.freedesktop.org/show_bug.cgi?id=74589) +[[https://github.com/systemd/systemd/issues/2402|Mount efivarfs read-only]] 
-    Mount efivarfs read-only (https://github.com/systemd/systemd/issues/2402) + 
-    Unable to shutdown (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171) +[[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171|Unable to shutdown]] 
-    journald eats up CPU (https://bugs.freedesktop.org/show_bug.cgi?id=61191) + 
-    Corrupted binary logs (https://bugs.freedesktop.org/show_bug.cgi?id=64116) +[[https://bugs.freedesktop.org/show_bug.cgi?id=61191|journald eats up CPU]] 
-    tmpfiles: R! /dir/.* destroys root (https://github.com/systemd/systemd/issues/5644) + 
-    systemd again (or how to obliterate your system) (https://www.preining.info/blog/2017/04/systemd-again/) +[[https://bugs.freedesktop.org/show_bug.cgi?id=64116|Corrupted binary logs]] 
-    systemd can't handle the process previlege that belongs to user name startswith number, such as 0day (https://github.com/systemd/systemd/issues/6237) + 
-    systemd Using 4GB RAM After 18 Days of Uptime (https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime) +[[https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet|How to Crash Systemd in One Tweet]] 
-    Please do not default to using Google nameservers (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658) + 
-    journal ip anonymization (https://github.com/systemd/systemd/issues/2447) +[[http://www.openwall.com/lists/oss-security/2017/01/24/4|systemd v228 local root exploit]] 
-    systemd kill background processes after user logs out (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394) + 
-    systemd-resolved DNS cache poisoning (https://seclists.org/oss-sec/2014/q4/592)+[[https://github.com/systemd/systemd/issues/5644|tmpfiles: R! /dir/.* destroys root]] 
 + 
 +[[https://github.com/systemd/systemd/issues/6237|systemd can't handle the process privilege that belongs to user name startswith number, answered as being "not a bug"]] 
 + 
 +[[https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime|systemd using 4GB RAM after 18 days of uptime]] 
 + 
 +=== Conceptional problems === 
 + 
 +[[http://soylentnews.org/article.pl?sid=14/12/21/0145243|systemd Prevents the Skipping of fsck while Booting]]] 
 + 
 +[[http://soylentnews.org/article.pl?sid=14/12/21/1554227|Default to using Google nameservers]] 
 + 
 +[[https://github.com/systemd/systemd/issues/437|timeX.google.com provide non standard time]] 
 + 
 +[[https://bugs.freedesktop.org/show_bug.cgi?id=76935|Do not parse "debug" command line parameter]] 
 + 
 +[[https://github.com/systemd/systemd/issues/2447|Journal ip anonymization]] 
 + 
 +[[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394|systemd kills background processes after user logs out]] 
 + 
 +===== Conclusion for the Hyperbola-project ===== 
 + 
 +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 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.