From owner-freebsd-hackers Wed Jan 10 5:12:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id B271D37B402 for ; Wed, 10 Jan 2001 05:12:15 -0800 (PST) Received: (qmail 79104 invoked by uid 1003); 10 Jan 2001 13:12:11 -0000 Date: Wed, 10 Jan 2001 15:12:11 +0200 From: Neil Blakey-Milner To: Greg Black Cc: Dan Langille , Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010110151211.A37285@mithrandr.moria.org> References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> <20010110112451.A52255@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gjb@gbch.net on Wed, Jan 10, 2001 at 09:35:13PM +1000 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2001-01-10 (21:35), Greg Black wrote: > > These changes have been tested in OpenBSD for 3 years. > > That's not the same as testing under FreeBSD. Of course not, but it's a reasonably similar population type. > 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. To summarise: It is broken, we have the fix, but some people don't need it, because they've given up on cron, beacsuse it's broken, and avoid using the broken bits. Not only that, but people who don't understand that it is broken are unable to understand simple facts. In addition, it took the FreeBSD project about 7 years to finally get their daily runs to run exactly once, once every day. > 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. You left out "detecting DST changes, and acting accordingly". > 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. Here you are doing it again. You're calling people who expect a tool to work in a reliable and obvious way "incompetent", and the few people who know the arcane arts to be some sort of elite. If you hadn't noticed (despite my indication of the fact), I was attempting to emulate the style of the detraction; that's why you seem to believe I'm getting worked up over this. Trust me, I'm not. If these people who know the arcane system administrator's art upgrade their systems, don't read the release notes, and don't use the options I'm suggesting we attempt to give them, then we've done all we can to provide an alternative reliable and obvious scheduler (without "don't schedule tasks in the morning! Beware!" notices). > 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. Or using the supplied option. > > 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. Or of providing them with the option to not have to worry about all that stuff? Or does that make FreeBSD too easy for plebs to use? (: > > 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. You seem to believe this is a feature. This is a bugfix for a feature that already exists. > > 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. Or just do the least-work thing and use the option provided to act in the old way? In summary: I do not see a valid argument for not having the bugfix at all, available as an option. I do see the argument for not changing the default. I also see that everyone who opposes seems to believe that it is only people without major skills that get confused by all this, since people with major skills know not to rely on any behaviour over DST changes. 66% of them agree (33% haven't expressed an opinion) without provocation that those people with major skills will read the release notes. Common sense indicates that they are able to use a command line option that disable the new reliable behaviour. There has been expressed a need for testing. That is dealt with by three years in OpenBSD, and a period of time in the development branch, as per most development. What we haven't seen is any technical opposition to the algorithm used, which has been explained. If there is a problem with it, then that should be determined. My review of it indicates the OpenBSD cron behaviour is very specific, reliable, and obvious. 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