4 ms·

> The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. There are many premises for which systemd wa

> The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise". 1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did. 2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files. The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV. Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files. > which may include network and container management, timers and God knows what else. 1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd. 2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files. > ... unless you are insisting on writing all your init files ... It's not an all-or-nothing affair. It never was, not with systemd not with SysV. > ... at which point you may as well use any of systemd alternatives Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.

MertsA 7y ago
>Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false. Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up. With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.

MertsA 7y ago

>Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false. Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up. With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.