3 ms·
My take-away is the following: * systemd tries to solve a complicated problem * systemd has a lot of complexity * some of that complexity seems unnecessary
by adekok 11y ago
My take-away is the following:
* systemd tries to solve a complicated problem
* systemd has a lot of complexity
* some of that complexity seems unnecessary
* parsing is hard (see DJB). Parsing (as systemd does) in PID 1 is bad. Complex systems in PID 1 is bad.
* systemd manages states and dependencies (this is good)
* some of the states are only internal, and can't be serialized to storage. The result is indeterminism and race conditions. (This is bad)
* as a result of the above point, systemd behavior is hard to debug, and hard to understand
* another result (not stated explicitly) is that systemd allows for (and apparently can't detect) ordering cycles and dependency cycles.
* The configuration files are simple for simple tasks (good), but not complex enough for complex tasks (bad)
... etc.
i.e. systemd is an engineering solution. It pretty much works, but it has inherent design / implementation issues which cause real-world problems.
- Jweb_Guru 11y agoThis article pretty conclusively convinced me that systemd is actually good, if these are the strongest arguments against it. Most of the dependency-related stuff (process order related, cyclicstuff) seems eminently fixable. I found his arguments about dependency management having to be linearizable highly unconvincing.
- sagichmal 11y ago> I found his arguments about dependency management having to be linearizable highly unconvincing. What? Can you expand on this? To me it rang as a well-reasoned, and pretty devastating, critique.
- 9mit3t2m9h9a 11y agoThese are the strongest argument against its core service management logic; those that explain why it is not better than Upstart (or daemontools or s6+s6-rc …) And systemd causes problems not only by this, but also by its bundling of similarly mediocre or worse other components.