Not that I have a problem with systemd, which I don't hate and I use extensively (both in my customers' products and on my machine because it's the default init system of the distro I use), but this thread illustrates a lot of why a lot of pre-systemd Linux users just don't dig it.

Every time someone asks "why should I use systemd instead of cron" they get these (technically correct -- the best kind of correct!) answers about how systemd timers allow you to attach jobs to cgroups, define dependencies, test unit files separately vs. changing crontabs for 1 minute ahead (which I don't think is a "cron idiom" -- I've certainly never done i -- but we all have our weird hacks), and how it has built-in jitter options and per-job environment settings and whatnot.

These are all very relevant for real-life workloads of super advanced cloud systems, I'm sure. (Which I'm not saying in a derogatory way. I haven't written back-end code in like 12 years now, the things that are happening there today blow my mind. I know these are complex systems so I'm pretty sure they have complex problems which have complex solutions.)

But guys, I just need to run a bash script every day at 2 AM. 99% of us just need to run a bash script every day at 2 AM. This has worked reliably in cron since practically forever. I have grumpily learned the new way of doing it but I can't really justify the time I've put into it, nor the (very extensive) troubleshooting that was involved in it. I just woke up one morning and sat down in front of a Linux machine and I found out that there's a new way to run things at 2 AM.

If you want to woo me with cool systemd-timers features, tell me that it finally has an equivalent to cron's MAILTO, so that I don't have to write yet another systemd unit file that wraps a script written by me if I want to get a notification when a job has failed, because somehow that hasn't made its way into the "everything but the kitchen sink" list which otherwise includes things like attaching jobs to cgroups.