[sterlind]

Systemd's real value proposition is its tight coupling. As you pointed out, there were several logging systems, several daemon programs, several hardware managers, a combinatorial smorgasbord of options available.

This means you can't assume almost anything about the distro or setup you're targeting as an application developer. Should I log to /var/log or use journald? Can I bundle a .service file or should I have shell scripts? Can I rely on udev rules or do I need to touch /dev? You can't assume unless you're only targeting Ubuntu.

Systemd is so integrated that programs require minimal porting. The alternative is either supporting everything, which leads to massive bloat, or forcing downstream patches to make the damn thing compile and run. Having a non-modular set of services you can rely on means even small alternative distros like NixOS can support many packages, because those packages require minimal changes.

Consistency across environments is critical. it's why docker is so big - all the wiring lives in one place, and what's inside runs everywhere.

But reducing choices to get consistency and consensus strips away the freedom that Linux offered - you can't uproot and replace components as easily. You can have that freedom or you can have a hassle-free package ecosystem; it's an inherent trade-off.