Few technical debates in Linux history have been as heated as SysV init versus systemd — worth understanding both sides fairly, since the disagreement was about genuine, defensible engineering trade-offs, not just resistance to change.
SysV Init’s Simplicity
#!/bin/sh
### BEGIN INIT INFO
# Provides: myapp
### END INIT INFO
case "$1" in
start) /usr/local/bin/myapp & ;;
stop) pkill myapp ;;
esac
SysV init scripts were plain shell scripts — genuinely simple to read, write, and debug, following the Unix philosophy of small, transparent tools closely.
Why systemd Won Anyway
- Proper parallel startup dramatically reduced boot times versus SysV’s sequential script execution
- Built-in dependency management, socket activation, and automatic service restart on failure
- A consistent, structured way to query state (
systemctl status) instead of parsing inconsistent shell script output
The Legitimate Criticism
Critics genuinely argue systemd violates the Unix philosophy by absorbing far more scope than an init system needs — logging (journald), network configuration, DNS resolution, and more — creating a single point of failure and a much larger, harder-to-audit codebase than a minimal init system requires. Alternatives like OpenRC and runit exist specifically for users who find this trade-off unacceptable.