Date: Thu, 11 Jan 2001 10:47:05 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Doug Barton <DougB@gorean.org> Cc: Greg Black <gjb@gbch.net>, Dan Langille <dan@langille.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010111104705.A74850@mithrandr.moria.org> In-Reply-To: <Pine.BSF.4.31.0101101246510.91066-100000@dt051n37.san.rr.com>; from DougB@gorean.org on Wed, Jan 10, 2001 at 12:52:29PM -0800 References: <20010110151211.A37285@mithrandr.moria.org> <Pine.BSF.4.31.0101101246510.91066-100000@dt051n37.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed 2001-01-10 (12:52), Doug Barton wrote: > > To summarise: It is broken, > > According to your definition of broken, which we have not > necessarily reached a consensus on. I agree - there is no consensus, and there never will be. Some people want cron to be reliable, and not skip jobs or run jobs multiple times, and other people want cron to be reliable, and to skip jobs and run jobs multiple times. I believe the reliable behaviour is to never skip jobs. People schedule fixed-time jobs (the _only_ type affected by this change) with the intention that they will be run. I also believe people schedule fixed-time jobs (tagain, the only type affected by this change), with the anticipation that it will be run only once. Time doesn't really go backwards or forwards merely due to timezone changes or corrective time changing. Wildcard jobs are not affected by this change. Your hourly jobs will run every hour still. _Every_ hour. If there are two two-o'clocks in a row, it will be run twice, because in reality, there has been an hour passing. Every five minutes will run every five minutes, even if you correct the time backwards 18 minutes - it'll run at 10:30, 10:15, 10:20, 10:25, and 10:30 again (just like the current cron behaviour). One side says POLA means never changing a programs, and others say POLA means that a program shouldn't act in an astonishing way. They both have merit. > > Not only that, but people who don't understand that it is broken are > > unable to understand simple facts. > > Or perhaps we understand the simple facts, but there are more > complex facts that make this change a bad idea. Note, I was quoting a detractor, not saying this myself to anyone. I don't attack people when I don't agree with their argument. > > In addition, it took the FreeBSD > > project about 7 years to finally get their daily runs to run exactly > > once, once every day. > > This is overstating the case. It was never really considered a > huge issue by most, and at various times in the past the "correct" change > for the majority of our userbase got mired down in socio-political > arguments that had nothing to do with the technical merits. Of course it's hyperbole - what I'm saying is that every 6 months people get confused (and astonished) that jobs get skipped or doubled, and still nobody could agree on a simple way to fix this. My personal concern isn't DST changes (since I'm not influenced by them), but other corrective time measures that cron really should act reliably around. > > What we haven't seen is any technical opposition to the algorithm used, > > which has been explained. > > What you are seeing is opposition to the idea itself. I'm not > going to waste time analyzing the implementation of what I think is a bad > idea. :) The opposition I've summarised already: "People who don't know that cron is not reliable are unable to understand basic facts" (rough paraphrase). The arguments have often been against the idea in it's entirety, saying that this behaviour should never occur, even as an option, since it's a stupid idea. That is policy, and should be ignored - we don't enforce policy on our users. The only argument people can have is against the implementation of the change, and whether it should be default or an option. The implementation is good, unless someone cares to review it. I think it should be default, as the only people who will be inconvenienced by the new behaviour will be people who already consider cron to not be reliable around time changes. If they rely on it being unreliable, they can always use an option supplied to get the old behaviour, since they already spend a lot of time thinking of how to avoid the problems inherent in the old behaviour, and remembering a command line option (or looking it up in the man page) shouldn't be an issue for them. Yes, this is a POLA issue - it is astonishing to people that cron behaves this way, when they first see it. It will be "astonishing" to very fewer people if the default changes to the new behaviour, and we accomodate these people by placing it in the release notes, having an option for the old behaviour, and possibly delaying the use of the new system in the -STABLE branch until 5.0, if that is deemed necessary. Now, if anyone has a reasoned argument about the new algorithm (like, how it handles certain kinds of events in a surprising way), I'd like to hear it, or we can proceed to make it an option. If anyone has some clear cases why this is a truly astonishing change for people that can't adequately be handled in the accomodations listed above, we can hear your concerns too. If there is no clear winner, we can have it as just an option. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010111104705.A74850>