[arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

[Carl Schaefer]

It seems to me that, compared to cron/anacron, systemd timers currently
offer reduced functionality and no clear benefit (I don't consider the
act of uninstalling cron to have significant value in itself).  Losing
the ability to control when jobs run is giving up a lot; without that,
the more use is made of systemd timers, the more unpredictable the
results will be.

Perhaps I'm missing something, because I don't fully understand all the
points Thomas raised last month in his proposal on arch-dev-public:

> Pros:
> * enabled by default (in contrast to cronie)
> * systems without need for crontabs can disable/uninstall cron
> * service will be simpler than the rather long dropin scripts
> 
> Cons:
> * services are run in parallel instead of sequentially (is this even a
>   con? timer start will be randomized, and we can increase accuracy to an
>   hour to randomize even more)
> * no holdoff time after boot as it seems

pro#3 is a mystery to me, and missing from the "con" list is the point
Maciej raised about the effect random timer jobs can have on busy
servers.

If this ship is already sailing, though, the goal should be to add
functionality to systemd timers so that it becomes a real replacement
for cron, e.g. allow execution windows to be defined, jobs placed within
these windows, and scheduling parameters like acceptable degrees of
parallelism to be specified.  Something like that could be more powerful
and flexible than cron, and potentially easier to manage than a set of
crontabs.  Does anyone know if the systemd timers roadmap includes
anything like this?
Carl