Date: Wed, 10 Jan 2001 15:12:11 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Greg Black <gjb@gbch.net> 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: <20010110151211.A37285@mithrandr.moria.org> In-Reply-To: <nospam-3a5c48f1a101e5c@maxim.gbch.net>; from gjb@gbch.net on Wed, Jan 10, 2001 at 09:35:13PM %2B1000 References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> <20010110112451.A52255@mithrandr.moria.org> <nospam-3a5c48f1a101e5c@maxim.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010110151211.A37285>