A word about systemd (2016)
Systemd, the dominant init system on modern Linux distributions, is praised by many for standardizing service management, improving dependency handling, and simplifying life for distro maintainers, developers, and admins across disparate systems. Critics argue it violates the Unix “do one thing well” ethos, exhibits scope creep with components like systemd-resolved and timers supplanting traditional tools (cron, classic DNS setups, NTP clients), and was effectively pushed into ubiquity through distro politics rather than pure technical merit. Much of the tension centers on whether its integrated, feature-rich design represents necessary evolution for complex, scalable infrastructures or an overengineered monoculture that locks users into controversial design choices.
Adoption and “bullying” vs choice
- One side claims systemd was politically pushed and foisted onto users, ignoring critics, leading to resentment.
- Others counter that distributions independently evaluated and adopted it because it solved real maintainer and user problems; no distro was “forced”.
- There is recognition that once big distros and desktops (e.g., GNOME) integrated tightly with systemd, non‑systemd options became more work.
Interoperability and standardization
- Supporters highlight that pre‑systemd init was fragmented: different init scripts, logging, and service management per distro.
- Systemd units and associated tools provide a common, mostly distro‑agnostic way for developers and admins to define and manage services.
- Critics respond that this is conformity rather than interoperability, likening it to a dominant, nonstandard API.
Unix philosophy and scope
- A major criticism is that systemd “does too much” (logging, DNS, NTP, networking, timers), violating “do one thing well” and locking users into design mistakes.
- Others argue Unix philosophy is about function, not code size, and that modern requirements naturally increase complexity.
- Some see the project more like GNU: many separate binaries under one umbrella, not a single monolith.
Practical benefits cited
- Easier, unified service management: restart policies, dependencies, per‑user services, cgroups, resource limits.
- Less custom daemonization code; services can just run in the foreground.
- Better handling of boot ordering, socket activation, containers, and packaging (same unit works across distros).
- Timers and other primitives are viewed by many as superior to ad‑hoc cron and init scripts.
Component‑level complaints (especially resolved & journald)
- systemd‑resolved is widely criticized, especially its control over
/etc/resolv.conf, stub listener behavior, and packaging defaults in some distros. - Some see journald’s binary logs and central interception of stdout/stderr as anti‑Unix; others note you can still forward to traditional syslog.
- There is concern about feature creep and “NIH” implementations (DNS, NTP, networking) replacing long‑standing tools.
Alternatives and choice
- Alternatives like OpenRC, runit, s6, and others are mentioned; several distros use or support them.
- Some argue that if you dislike systemd, you should pick or build a different distro, but also acknowledge real constraints in regulated or vendor‑locked environments.