As someone who runs linux on a laptop, I'm pretty firmly convinced that cron & crontab need to be rewritten and I'm likely to try my hand at it next year. The immediate problem, for cron & crontab on laptops, is that laptops are usually not running. My laptop is running only about two or three hours most days, so cron jobs, especially those scheduled for execution between midnight and morning, simply don't happen except when I *make* time for them to happen by leaving it running overnight. This keeps file indexes up-to-date, etc. So, we need two new kinds of things we can specify in crontabs: Those that can or should be done next time the machine is turned on provided they're not <time> late (such as mailing reminders), and those that should be done periodically where the period is measured in uptime rather than wall time. This would seem to necessitate changing the age-old crontab file format, and if I wind up doing that, I'll probably add support for truly periodic stuff as well (it's currently very hard to tell cron to do something once every eight days or once every three weeks, for example). However, any monkeying with cron & crontab has substantial security implications. Anybody who manages to edit another user's crontab can run jobs as that user. Anybody who can read the crontabs of daemons or other users can find out things about how and when certain things are done -- possibly discovering windows of vulnerability in the way logs get cycled, when automated security checks run, etc. Anybody who can kill the cron daemon can prevent logs from getting cycled or security checks from happening. I'd really like to see a record of all the security flaws that have ever been found in any version of cron, and how each was dealt with. I don't think such a thing exists, but bits and pieces of it must be here and there, and I think I ought to read them before I start messing with such a fundamental service. Bear