puppyfun.org

systemd is not bad, actually

• 3-minute read

This website is commonly cited as a source when people are asked for valid criticisms of systemd. Despite this, a thorough review reveals it to be a low-quality mashup of historical issues and extremely misleading statements meant to radicalize impressionable users against systemd for no good reason.

Below is a review of every claim made on the website with issue numbers or quotations provided whenever applicable.

"notable bugs and security issues"

  1. Datadog's deployment process was primarily responsible
  2. #1988119: Fixed since
  3. #437: Up to a distro to ship it configured ideally. Time servers are tricky
  4. #1143: Caused by a 32-bit timer issue, not a systemd bug.
  5. #1312: systemd now provides ways to model recovery
  6. #1596: Fixed since
  7. #2402: Bad firmware allowed for bricking. systemd mounting efivars read-write can be criticised
  8. #2460: Valid, but no alternatives suggested
  9. #4863: Not applicable since version 240
  10. #5644: Fixed since
  11. #6237: Fixed since
  12. #6369: Intended: the kernel hostname isn't meant to accept every possible DNS FQDN representation
  13. #6381: Fixed since
  14. #6478: Valid and stale since 2017, though not necessarily a regression
  15. #6620: The behaviour is inherent to how journald streams work with restarts
  16. #7184: Fixed since
  17. #8579: Extremely specific regression, unclear whether still applicable
  18. #1795921: Fixed since
  19. #6078: Not applicable in its original form since networkd gained runtime reload/reconfiguration support
  20. System Down: Fixed since
  21. #11810: Hardware fault
  22. eCryptfs thingy: Not a systemd defect
  23. #2913: Valid, but no alternatives suggested.

"other issues arising around systemd"

systemd will be able to kill a process if he needs/wants more RAM

The wording is deceptive, the existence of an optional OOM service is not a criticism. (why is systemd referred to as a he here? it's not even phrased that way in the source provided)

We need to enforce the use of systemd to everyone, by the creator of systemd itself.

This one is straight up a lie: the linked email contains nothing of the sort.

systemd kills background processes after user logs out

Up to the distribution maintainer

Don't panic, but Linux's systemd can be pwned via an evil DNS query

Fixed since

Systemd Could Fallback to Google DNS?

Up to the distribution maintainer. A pre-configured fallback exists to prevent issues with a distro not configuring their own

DNS search domain not removed from resolv.conf on disconnect

This is an Ubuntu bug filed against NetworkManager; it isn't a systemd problem

systemd ignores system-wide resource limits

This one is extremely misleading. systemd having its own limit configuration instead of using the ones applied through PAM is not remotely similar to it ignoring system-wide resource limits. Also, the source is 10 years old.

final thoughts

Unrelated to its content, the site itself is very poorly made and manages to lag out Chromium-based browsers due to inexplicably stacking blur filters which are barely visible when viewed.

← all posts