> I disagree. If you really look at the problem space, it turns out that "classic cron" is just a "batch scheduling system" that is poorly implemented. I'm a b

> I disagree. If you really look at the problem space, it turns out that "classic cron" is just a "batch scheduling system" that is poorly implemented. I'm a bit confused. It still sounds like you're describing a batch scheduling system and that cron isn't one (because it only implements a narrow function of such a system). What features does PBS (not cron) lack that any of the re-inventions do have? > Unfortunately, cron leaves all the actual hard challenges unsolved > the Unix philosophy wisely encourages us to separate out concerns into complementary tools that fit together. I'm also having trouble reconciling these two positions. Cron does one thing, which is forking on a schedule. To leave something like "dogpiling" for another utility (e.g. dotlockfile) to solve seems consistent with the Unix philosophy. > Not "everyone just uses Yarn" at all. For the projects I work on, we use distributed cronjobs on Kubernetes That doesn't quite refute my point, as you can feel free to consider "Yarn" as merely a metaphor for the currently most-popular inbuilt scheduler of a currently popular distributed computing platform.