From owner-freebsd-hackers Wed Jan 10 3:36:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 9399A37B404 for ; Wed, 10 Jan 2001 03:35:45 -0800 (PST) Received: (qmail 7815 invoked by uid 1001); 10 Jan 2001 21:35:13 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Wed, 10 Jan 2001 21:35:13 +1000 From: Greg Black To: Neil Blakey-Milner Cc: Dan Langille , Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> <20010110112451.A52255@mithrandr.moria.org> In-reply-to: <20010110112451.A52255@mithrandr.moria.org> of Wed, 10 Jan 2001 11:24:51 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neil Blakey-Milner wrote: > On Wed 2001-01-10 (21:20), Dan Langille wrote: > > > > IMHO, the solution is not to schedule jobs during during the changeover > > period. However, *if* the mods are adopted, it should default to off. Add > > a switch to turn them on. See how that runs for a few years. Then, and > > only then, if the feedback is positive, consider changing it to the default > > behaviour. Such a radical change to cron cannot be implemented > > without sufficient field testing. That will take years. It cannot be > > simulated. > > These changes have been tested in OpenBSD for 3 years. That's not the same as testing under FreeBSD. And it's not just a matter of testing anyway -- it's a matter of changing well known and understood behaviour that has been in place for decades for no other reason than that some people seem to be unable to understand simple facts, such as the fact that playing arbitrarily with clocks for DST leads inevitably to certain anomalies in all kinds of scheduling. Solutions to this include running the scheduler under a more sensible time regime, such as UTC or TAI -- always an option for cron, or avoiding the scheduling of tasks for times that can either occur twice or not at all -- usually an option for Unix cron tasks. None of this is rocket science. Fiddling with cron to work around incompetent sysadmins just exposes the rest of us to new bugs in cron -- a program that we depend on for a large range of important tasks. Of course, those of us who don't want to be bitten by the weird new behaviour will have the option of retaining the current (rather unattractive) BSD (aka Vixie) cron or of replacing it with an entirely new tool and disabling the supplied cron altogether, in much the same way as many people remove sendmail in favour of qmail or named in favour of djbdns. > The "solution" > is _not_ to tell people they're stupid to schedule jobs during the > changeover. It's not a matter of telling people "they're stupid to schedule jobs during the changeover," it's a matter of expecting them to understand what it means to do that in those benighted places that resort to DST. > However, since it _does_ have this "feature", we should > accomodate people who are negatively affected by it. I think we should accommodate them in exactly the same way we accommodate people who are negatively affected by the lack of support for Word documents in vi, surely a far more pressing problem. > It _will_ fix the > twice-yearly complaint about extra and missing jobs. And that will reduce the list traffic of that type by a truly insignificant amount. > It may create > unexpected behaviour for a tiny percentage. Those people should be > reading the release notes ("or they shouldn't be system administrators > or run FreeBSD"). Those people do read the release notes, just as they read the stuff that gets on this list -- and at least some of them have expressed strong reservations about the proposed changes. It seems clear that the loudest noise comes from the proponents, so I guess I'll have to dust off the sources to my old personal cron implementation in readiness for the day when this thing gets into the distribution. > Again, this change is from OpenBSD. We will synchronise with their > changes, and perhaps offer them back a patch to ignore what "ultra leet > sysadmins who rely on broken behaviour because people who don't are > simply stupid and shouldn't be running FreeBSD anyway!" with an option. I cannot parse the final sentence above and don't think it adds much to the case that is being made here. Since it seems that heat rather than light is the base of much of the discussion, I think I'll drop it now -- apart from a final plea that the new behaviour be made to default to off if it gets up enough support to be incorporated into FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message