A word about systemd (2016)

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.