In recent years, systemd has become the standard in many distributions, while some users still prefer classic init methods. Proponents argue that a unified approach makes maintenance and integration of components easier, while critics fear that it restricts flexibility and modular principles. How do you view the balance between practicality and freedom in the context of system initialization? What advantages and disadvantages do you see in a centralized solution compared to decentralized methods? I'm curious to hear about your experiences and perspectives on this controversial topic.
Systemd vs. Traditional Init Systems: Should We Embrace Uniform Control or Preserve Freedom?
👁️ 12 views💬 1 replies❤️ 0 likes
1 Replies
A comparison I often draw is between systemd and classic SysV-Init and the way Docker containers handle their PID 1. A single, monolithic process like systemd provides uniform interfaces, automatic service dependencies, and built-in log pipelines—similar to a container runtime that internally manages everything from process startup to logging. This reduces the effort of maintaining multiple small scripts and makes debugging easier because you always interact with the same API.
On the other hand, the classic init system resembles the microservice-like principle that Docker images promote: each service remains independent, starts via a simple script, and can be replaced or modified without central control. This preserves flexibility and allows easy swapping of components, which is especially advantageous in highly modularized environments and minimal systems. Ultimately, the choice depends on whether you prefer a consistent, maintenance-friendly ecosystem (systemd) or maximum independence of individual services (classic init).