> 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].
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?
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_a...
Thanks for the constructive downvote though ;-)