3 ms·

The declarative format of systemd unit files is just much easier to maintain, grasp and allows doing things that just cannot be done else, for example, a generi

The declarative format of systemd unit files is just much easier to maintain, grasp and allows doing things that just cannot be done else, for example, a generic way to parallel starting service at boot, as all dependencies and before/after ordering is known. And the great things is, that declarative format means that systemd can actually be replaced by something else, as one just needs to be able to parse the ini-style configs and execute the ExecStart and ExecPreStart in order. One really cannot do that to the other init-systems, AFAICT, they are far too scripted and rely a lot on side effects to do anything like that, besides packager choosing different solutions for the same problem. Some KI-paper could possibly take a shot at parsing out some sensible information reusable for another tool ;-) I can get the dissentient about systemd incorporating so much stuff, but just from POV of it as init-system it is really nicer to work with, speaking as user and as someone which job includes packaging software for a Debian based distro.

froh 5y ago
in system V init scripts on Linux they had standardized dependency declaration comments. when you added services you ran a dependency checker which would translate the dag into a total ordering, laid out using 01 02 03 ... numeric file name (symlink) prefixes. it was robust, simple and straightforward. however it was built around bash. which was large and slow to start up,compared to e.g. dash as scripting shell. and dash was not widely around yet. so each script had the cost of bash startup, the milliseconds of which added up. and at some point the tipping point was reached.
- tlamponi 5y ago
  > in system V init scripts on Linux they had standardized dependency declaration comments. when you added services you ran a dependency checker which would translate the dag into a total ordering, laid out using 01 02 03 ... numeric file name (symlink) prefixes. Yeah, I know, but in practice this did not really work out and was a mess. In fact, every update was scary to do, in that time I frequently just re-installed the distro on my private workstation, simpler than to deal with the rc stuff. A plain setup may have worked, but anything slightly complex was just bonkers to do. > it was robust, simple and straightforward. Do you package for a relevant distro or is this just your experience as user? Asking because I just personally do not know any maintainers of software with a slightly complexer system interaction which would agree with that. There surely are some, but FWICT on some ML's anti/pro systemd flames it's <1% of maintainers - and from them it's actually almost never the new unit file format what is the issue, but the way systemd eats up basic system services. IMO the systemd unit files are exactly what you say "robust, simple and straightforward", the implementation may not be, I never even touched that, but the unit file schema is just better, as it's not bash/dash with some slight optional possibility to use some hacks like comments (urgh) as schema, but actually provides a standardized format for doing that and more. As someone maintaining dozens of packages and as common user, I'm happy that I do not need to mess around and fight the init-system, and I'm not the only one thinking so[0]. [0]: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/ https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Thanks for the constructive downvote though ;-)
  - froh 5y ago
    I did package, for suse, yes. and I agree the declarative unit files are simpler to maintain. the dependency comments were standardized, and the parser would give errors for incorrect comments. and of course for the RC scripts, great powers came with great responsibility --- for the package maintainer. I recently had to deal with the limited feature set of journald logrotation, compared to logrotate and syslogd. without going into the details, just compare the man pages, if you hit the limits of the available declarative feature set, you find yourself patching or doing fancy work arounds. if the features that come with systems are sufficient, it's a happy switch. if some corner case is missing, good luck. ps: I did not downvote. I don't do that for a healthy and interesting debate. that's not what we do on here, no?

froh 5y ago

in system V init scripts on Linux they had standardized dependency declaration comments. when you added services you ran a dependency checker which would translate the dag into a total ordering, laid out using 01 02 03 ... numeric file name (symlink) prefixes. it was robust, simple and straightforward. however it was built around bash. which was large and slow to start up,compared to e.g. dash as scripting shell. and dash was not widely around yet. so each script had the cost of bash startup, the milliseconds of which added up. and at some point the tipping point was reached.

tlamponi 5y ago
> in system V init scripts on Linux they had standardized dependency declaration comments. when you added services you ran a dependency checker which would translate the dag into a total ordering, laid out using 01 02 03 ... numeric file name (symlink) prefixes. Yeah, I know, but in practice this did not really work out and was a mess. In fact, every update was scary to do, in that time I frequently just re-installed the distro on my private workstation, simpler than to deal with the rc stuff. A plain setup may have worked, but anything slightly complex was just bonkers to do. > it was robust, simple and straightforward. Do you package for a relevant distro or is this just your experience as user? Asking because I just personally do not know any maintainers of software with a slightly complexer system interaction which would agree with that. There surely are some, but FWICT on some ML's anti/pro systemd flames it's <1% of maintainers - and from them it's actually almost never the new unit file format what is the issue, but the way systemd eats up basic system services. IMO the systemd unit files are exactly what you say "robust, simple and straightforward", the implementation may not be, I never even touched that, but the unit file schema is just better, as it's not bash/dash with some slight optional possibility to use some hacks like comments (urgh) as schema, but actually provides a standardized format for doing that and more. As someone maintaining dozens of packages and as common user, I'm happy that I do not need to mess around and fight the init-system, and I'm not the only one thinking so[0]. [0]: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/ https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Thanks for the constructive downvote though ;-)
- froh 5y ago
  I did package, for suse, yes. and I agree the declarative unit files are simpler to maintain. the dependency comments were standardized, and the parser would give errors for incorrect comments. and of course for the RC scripts, great powers came with great responsibility --- for the package maintainer. I recently had to deal with the limited feature set of journald logrotation, compared to logrotate and syslogd. without going into the details, just compare the man pages, if you hit the limits of the available declarative feature set, you find yourself patching or doing fancy work arounds. if the features that come with systems are sufficient, it's a happy switch. if some corner case is missing, good luck. ps: I did not downvote. I don't do that for a healthy and interesting debate. that's not what we do on here, no?