| You're not disagreeing with anything I said. You're making a completely different point. systemd might be more convenient from the point of view of an end user. And unit files might seem superficially simpler than a script. But systemd is not simpler. It provides significantly more complexity, while also providing a lot of features. systemd is also not more reliable. The previous system, even with LSB dependencies, was usually run in a linear mode with scripts run in a strict sequence. System boot and service startup was deterministic. If you read the part of the linked article about the sheer quantity and complexity of the internal state managed by systemd, and how it is not deterministic, or even fully understandable even by its authors due to the combinatorial complexity of all the options and how the same settings work differently in different contexts, I'm afraid that I can't do anything further to convince you about the significant design problems it has which directly impact its reliability. Never had it hang irrecoverably at boot, for no discernible reason? There is a reason people such as myself are appalled by its design. It doesn't even have a comprehensive specification for such a critical piece of functionality. It's defined solely by a single implementation. The systemd state is a massive hairball. It's effectively a black box, and understanding why the system exhibits certain behaviours is difficult. The sysvinit state consists of a current runlevel and the state associated with inittab tasks, which is pretty trivial. It doesn't attempt to maintain a mirror image of the state of the whole system, which is largely a constructed fiction. |
Proof? sysvinit's surface is anything you can call. It's internal state is everything on the system.
Systemd's surface is the (well documented) commands in the systemd unit files. Each unit is pretty much independent, the dependencies are specified and well defined. Their internal state can be examined and explored.