Systemd has been a complete, utter, unmitigated success

Perceived Benefits for Admins

• Several long-time sysadmins/devops report uniformly positive experiences: easier service management, clearer status, built‑in restarts, resource limits, and cgroup-based cleanup.
• Many recall the move from SysV/upstart (e.g., RHEL6→7) as a “breath of fresh air,” with unit files far simpler and more reliable than 100‑line shell initscripts.
• Some like that systemd gives a consistent service layer across many distros and environments (desktops, servers, IoT, cloud).

Scope, Components, and “Unix Philosophy”

• Strong disagreement on systemd’s expansion beyond init: logging, DNS (resolved), networking, containers (nspawn), etc.
• Supporters see a coherent platform and argue earlier tools were fragile, fragmented, and non-portable.
• Critics see “scope creep,” erosion of the “do one thing well” ethos, and Linux becoming more Windows‑like or corporate‑driven; some fear reduced freedom to swap components.

Logging and Journald

• Highly polarizing:
  • Fans praise structured metadata, powerful queries (journalctl -b -1 -p err), and easier fleet-wide ingestion; one describes a large-scale, low-maintenance security logging pipeline built on journald.
  • Detractors call it slow (slower than grep on compressed text), fragile (occasional DB corruption), and awkward to integrate with existing log ecosystems; many still forward via syslog to external systems.
• Some disable journald entirely in favor of rotated plaintext logs; others use it only as a local collection point.

Boot Behavior and Device Naming

• Critics report non-deterministic boots, occasional hangs fixed only by reboot, and harder debugging compared to fixed SysV orders or Solaris SMF.
• Defenders say older systems also had race/dependency problems; systemd’s model is different but not uniquely flawed.
• Network interface naming (eth0 vs enp…/ens…/enx…) is a recurrent pain point, with disagreement over whether systemd improved or worsened predictability.

Lock-In, Alternatives, and Ecosystem Effects

• Some argue systemd’s “success” is comparable to Windows dominance: widely adopted, but partly via hard dependencies (e.g., certain desktop environments) and distro defaults.
• Others note many non-systemd options exist (various inits, BSDs, non-systemd Linux distros) and report good experiences after switching.
• There is concern that new APIs and tight integration make it difficult, in mainstream distros, to replace individual components without going “off-road.”

Configuration Model and Usability

• Many praise unit files as simpler, more portable, and less bug‑prone than shell scripts.
• Others find the DSL opaque, highly noun-heavy, and hard to remember; any nontrivial change requires revisiting documentation.
• Debate centers on Turing-complete script-based configs (flexible but messy) versus declarative unit files (cleaner but sometimes clunky and less discoverable).