The article already explains the difference between cron and systemd timers, so I won't rehash that. Yes, systemd is more verbose, but that comes with advantages over cron. And if cron suits your usecases, it's a fine tool as well.
But with NixOS and this example specifically, you also get (at a minimum):
a) A declarative config without requiring an external tool like Ansible.
b) Any dependencies (rclone in this case) will be implicitly installed if not already present on the system.
c) If configuring a remote machine, this will copy over the encrypted rclone.conf file and decrypt it on the target.
d) And of course, it's trivial to version control and track changes to the config over time.
I want to use NixOS but man it’s a mess with its flakes vs no flakes debates. I’ve stuck with learning Ansible for now, but if flakes is ever properly built in I’d consider it.
Flakes are as stable as they can get imo. They are already widely adopted, so I don't see how they can ever completely walk the feature back. The unstable marker is only there because there are some edge cases to work around afaik.
And I agree that NixOS without Flakes is a worse experience overall.
Putting aside that this is all possible with nix and without systemd, the additional complexity strikes me as having hamstrung the linux community for the last decade. I hope reliable service management arises but I have yet to see the benefit.
In the meantime I'm just going to keep using void because I know how to fix it when it breaks. Systemd i have to google how to even find the service logs.... they certainly aren't easy to find via the filesystem any more.
Well, above a level tools can't be designed to be discoverable without any form of help/learning, and I believe that's fine. They should rely on a "common knowledge base" as much as possible, and I believe systemd commands are done in a POSIX-y style, but you do have to occasionally read a man page or Google.
Do we expect an average dude to just pop into a cockpit and land a plane with no previous training?
the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. Such triggering is nonetheless subject to the delay imposed by RandomizedDelaySec=. This is useful to catch up on missed runs of the service when the system was powered down.
