For my own use cases, I've found that traditional cron timing specs don't match what I need from scheduled operations. I mainly care about two things: time window and periodicity -- and while it's possible to express both in the same cron timestamp, it's both too specific and not specific enough. I don't see this post making a clear argument about their functional requirements, just that fcron satisfies more technical requirements than Vixie cron.

But going in full "I want a pony"-mode: over the years, I've needed the following features from a job scheduling system:

  1) time window (e.g. only run between 1am and 3am on weekdays)
  2) periodicity (if job was successful, next run is X time away)
  3) retry period (if job failed, retry after X time)
  4) job timeout (if job is still running after X time, kill it)
  5) start randomization (randomize start up to X time in window)
  6) job dependencies (don't run job Y until job Z has finished successfully)
  7) job anti-dependencies (don't run job Y while job Z is active)

FAFAIK, Vixie cron only allows 1 and 2; 4 can be done with coreutils' timeout (don't know if it's a POSIX command or only GNU), and 5 can be done with something like sleep $RANDOM, but the time spent waiting is added to the job's runtime -- which means that you no longer can create useful reports about job processing times. Of this list, fcron only adds nicer syntax, and 5 is built-in. It can kinda do 7, but serial is a global exclusion. If it were possible to make exclusion groups (e.g. job Y and Z have serial(1), job X has serial(2), and user's fcrontab has serial($UID)), that would be much nicer.

I acknowledge that Cron was never meant to solve 6 and 7, but it's still a feature that I require regularly in my systems. But I don't understand why 3 (explicit retries) was never implemented in any cron replacement, even systemd timers don't have it, at least I'm not aware of it (RestartSec is for services only).