Meta point: I'd really like to see (non-www) subdomains added to the article title. I clicked through to the article thinking that Heroku had redesigned their Cron management only to discover something completely different. Subdomains are included in Posterous links; why not everywhere?
I generally agree with the weak points that the OP pointed out regarding cron. That being said, throwing out cron, or any other built-in system tool, isn't always a great idea.<p>When you adopt a new scheduler, you're inevitably creating work for your enterprise. It's yet another thing that must be learned and documented. There may be a new syntax to learn, which will mean you're incurring training costs (and the cost of errors) down the line.<p>Programmers love to improve things, but there's a real world cost to change that can't be ignored. cron may be archaic and lacking power, but it's well understood.<p>As for enterprise schedulers, they've been around for years. Off the top of my head, I've worked with 'Autosys', and 'Appworx'. These were robust, enterprise-ready schedulers that supported conditional execution, locks, as well as their own scripting language.
<i>And the subtle differences between a cronjob’s shell environment and your command prompt’s shell environment can be maddening.</i><p>This is my favorite thing to complain about with cron. I can't believe that there's still not a way to test run cron entries. So far I just add > tmp.out >> tmp.err, set it to run every minute, and wait.
At Bizo (<a href="http://dev.bizo.com" rel="nofollow">http://dev.bizo.com</a>), we manage scheduled tasks via Hudson.<p>It works great for us. It's centralized, has a web interface, and is already familiar to everyone on the team (we already used Hudson for CI). It has a ton of plugins, so notifications, single sign-on, and a host of other desired features were no problem to bolt on.<p>Here's a quick post from a few months back on why we chose Hudson:
<a href="http://dev.bizo.com/2009/11/using-hudson-to-manage-crons.html" rel="nofollow">http://dev.bizo.com/2009/11/using-hudson-to-manage-crons.htm...</a>
I'll reprise my comment from the last time a new and better cron was posted here[1]:<p>While cron is clearly pushed way past its capabilities by many people (without always realizing it), this strikes me as a reinvention of something that's been around forever: the batch system.<p>If the goals are improved reliability, management, fault-tolerance, etc., you'd be better off using mature software that was designed to solve this problem, and already has good community support, like Condor.<p>[1] <a href="http://news.ycombinator.com/item?id=916737" rel="nofollow">http://news.ycombinator.com/item?id=916737</a>
I developed Whenever (<a href="http://github.com/javan/whenever" rel="nofollow">http://github.com/javan/whenever</a>) to at least make the Cron syntax more reasonable.
OP wants a distributed operating system. Linux, FreeBSD and Windows by design are not distributed. POSIX specifically cripples this. How do you take into account an action that needs to be distributed but have a central return point? How will fault tolerance be handled? Expecting every application to handle this won't work, what's needed is a distributed operating system.
No mention in the article about Gearman for worker queues so I'll promote it here. I like its simplicity and language agnosticism. <a href="http://gearman.org/" rel="nofollow">http://gearman.org/</a>