Date: Wed, 10 Jan 2001 21:35:13 +1000 From: Greg Black <gjb@gbch.net> To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: Dan Langille <dan@langille.org>, Doug Barton <DougB@FreeBSD.ORG>, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <nospam-3a5c48f1a101e5c@maxim.gbch.net> In-Reply-To: <20010110112451.A52255@mithrandr.moria.org> of Wed, 10 Jan 2001 11:24:51 %2B0200 References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> <20010110112451.A52255@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?nospam-3a5c48f1a101e5c>