> They're not "hidden", just managed with systemctl like other services.
So far in the history of nix, services have never equaled periodic tasks, to my knowledge. In that sense, it's a hidden surprise that would sooner or later bite everybody that has not been initiated in systemd. It makes things harder to debug.
> As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot
Now do you go from that need to "and that requires an internal crond implementation in your init system". Why not atd, or regular cron, or sleeping processes? I'm genuinely curious, so if you're aware of public discussion of it, please point me in that direction.
> The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option.
I appreciate that the chaining and dependencies of SysV init were horrible. That doesn't make it OK for systemd to introduce more subtle breakages in even a very basic* usecase.
> The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager
In the scenario where you do not need NetworkManager/GUI hostnamed would be quite worthless as well. /etc/hostname and the `hostname` command are more than enough to handle that case, thank you.
I guess my main issue with systemd is that it introduces (mostly?) unnecessary complexity, which makes me waste more time debugging problems. Of course it is better than SysV init, and I'm very happy with the syntax of system files. Yet, upstart showed that you can have those niceties without an excess of complexity.
So far in the history of nix, services have never equaled periodic tasks, to my knowledge. In that sense, it's a hidden surprise that would sooner or later bite everybody that has not been initiated in systemd. It makes things harder to debug.
> As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot
Now do you go from that need to "and that requires an internal crond implementation in your init system". Why not atd, or regular cron, or sleeping processes? I'm genuinely curious, so if you're aware of public discussion of it, please point me in that direction.
> The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option.
I appreciate that the chaining and dependencies of SysV init were horrible. That doesn't make it OK for systemd to introduce more subtle breakages in even a very basic* usecase.
> The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager
In the scenario where you do not need NetworkManager/GUI hostnamed would be quite worthless as well. /etc/hostname and the `hostname` command are more than enough to handle that case, thank you.
I guess my main issue with systemd is that it introduces (mostly?) unnecessary complexity, which makes me waste more time debugging problems. Of course it is better than SysV init, and I'm very happy with the syntax of system files. Yet, upstart showed that you can have those niceties without an excess of complexity.