Introducing stronger dependencies on systemd

Original Article ↗ Hacker News Discussion ↗

Scope of the Change & “Desktop for All” Irony

  • Many see the stronger systemd reliance—especially on userdb/logind APIs—as contradicting GNOME’s “desktop for all” messaging, since “all” now effectively means “Linux with systemd or a clone.”
  • Some note GNOME doesn’t technically require systemd-the-program, only its APIs, so alternative implementations (elogind, userdb reimplementations) remain possible—but now those are clearly someone else’s problem to maintain.

Maintenance Focus vs Portability / Diversity

  • Supporters: narrowing to one main stack (Linux+systemd) is framed as sane engineering—fewer backends, less code, better testing, clearer expectations for both GNOME and distros.
  • Critics: argue GNOME and Red Hat/IBM have plenty of resources and are actively manufacturing a systemd monoculture by making critical components (login, user DB, etc.) depend on it.
  • Several point to a broader “backend plague” in FOSS: every extra backend looks cheap upfront but is costly to test and maintain; systemd’s opinionated approach is seen as an intentional reaction to this.

Systemd: Benefits, Problems, and Monoculture Risks

  • Pro-systemd comments highlight:
    • Far better than ad‑hoc init scripts; consistent service management; cgroups integration; easy hardening (syscall filters, resource limits, sandboxing); user services.
    • It “won” because it solved real problems faster and more comprehensively than fragmented alternatives.
  • Anti-systemd comments emphasize:
    • Tight coupling of many subsystems (logind, udev, userdb, journald) makes it hard to replace and hard to fully understand or audit.
    • Perceived “forced adoption” via indirect dependencies in Xorg, GNOME, etc.; users feel coerced rather than convinced.
    • Binary logs and complexity are disliked; some report worse robustness or performance compared to lighter init systems.
  • Monoculture concern: one widely‑used stack becoming a single point of failure; XZ backdoor’s proximity to libsystemd is cited as an example of how deeply such risks can propagate.

GNOME’s Position in the Desktop Landscape

  • Several see GNOME as the de facto Linux desktop (default on Ubuntu, Fedora, Debian, RHEL, etc.), especially in corporate and institutional contexts.
  • Others strongly prefer KDE or lighter desktops (XFCE, MATE, i3/sway), citing better performance, customizability, or Wayland experience.
  • Some argue the browser is now the real “desktop,” so these battles matter less, while others blame GNOME’s “my way or the highway” attitude and unstable extension ecosystem for ongoing friction.

APIs, Documentation, and Impact on Non-systemd Systems

  • A few suggest the real issue is API standardization and documentation: if systemd’s interfaces (userdb, logind, sd_notify, etc.) were better specified and possibly spun out, alternatives could implement them more sustainably.
  • Others counter that the referenced documentation is linked directly from the blog post, and that GNOME is reasonably shifting the integration burden onto those who choose non-systemd inits.
  • Concerns are raised about impacts on FreeBSD, musl-based systems, and whether GDM will still reliably start other desktop environments as these dependencies deepen.