|
|
|
|
|
|
by andrewstuart3
1373 days ago
|
|
|
Can't speak for the whole systemd "opposition", especially since I'm not really a part of it, but I think it is rather a matter of multiple implementations sharing standardized interfaces, versus a single implementation with its custom interfaces: compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols. With a single interface and different implementations, you can easily swap those, but with a monolith like systemd you are mostly stuck if the software actually makes use of it. I think there are other reasons why people dislike systemd (and recalling a few articles with people ranting about it; I think there are many around), and usefulness of standards and alternatives/choice wouldn't necessarily make sense either, but here is at least one of the ways to view it. As for init scripts, I think it can be even a bit nicer than that, since systemd provides some backward compatibility with sysV-style init scripts [1], but in that systemd acts almost like a swappable implementation. [1] https://www.freedesktop.org/software/systemd/man/systemd-sys... |
|
|
Well, but then you must be aware that you are leaving lot of effectiveness, unification and deduplication on the table.
See, many people think of systemd as if it was init replacement that grew timer support too. They are looking at the wrong level of abstraction: it is an event machine, that manipulates units when events happen. That event might be boot to certain runlevel, timer, hotlplug, incoming request on socket, dbus activation, whatever.
By cutting and dragging out one of the event handlers outside into special-cased, custom flow component that duplicates existing functionality anyway, you are ending up with a worse system.