Date: Tue, 9 Jan 2001 11:35:30 -0800 (PST) From: Gordon Tetlow <gordont@bluemtn.net> To: Doug Barton <DougB@FreeBSD.org> Cc: Neil Blakey-Milner <nbm@mithrandr.moria.org>, Gerhard Sittig <Gerhard.Sittig@gmx.net>, <freebsd-hackers@FreeBSD.org> Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <Pine.BSF.4.31.0101091115020.26645-100000@sdmail0.sd.bmarts.com> In-Reply-To: <3A5B5656.E2AAF0B5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello again.
On Tue, 9 Jan 2001, Doug Barton wrote:
> Neil Blakey-Milner wrote:
> >
> > On Tue 2001-01-09 (02:14), Doug Barton wrote:
>
> The point I'm trying (obviously in vain) to make is having cron do what
> amounts to "slewing its internal clock" will not work for everyone, and
> violates POLA.
Why won't "slewing it internal close" not work for everyone, I'm not
trying to be a pain, but I just don't know. Also, what is POLA?
> > This way, we never repeat jobs, and never lose jobs. Which makes cron
> > reliable.
>
> For your definition of "reliable." Personally, I find cron doing exactly
> what it's told and not trying to think for itself "reliable."
This is obviously a personal preference that no amount of talk is going to
change.
> > "Timing" problems with separate cron jobs will always be a
> > hack job, and undoubtably they'll lose or double jobs by mistake anyway.
>
> You (pl.) keep referring to the "We need to hand-hold users who are too
> stupid to figure this stuff out for themselves" argument. While there are a
> lot of areas of the system that I try to make simpler and easier to
> understand, I don't see how we can possibly make this problem foolproof.
> The universe keeps producing better fools.
I don't consider myself stupid (maybe other's do =) but when I'm admin'ing
a box, I have a bunch of other things that I'm thinking about and this
usually falls through the cracks. I have a hard time even remembering when
the DST shift is so I can change my alarm clock to make it into work at a
resonable hour.
> > you'll stop your sole campaign to vigourously resist the
> > incorporation of this code? If it helps, we can have an option ('-i')
> > to ignore DST changes, for "advanced administrators who know what
> > they're doing and expect jobs to be lost or run multiple times depending
> > on exactly when they schedule their jobs", and the "clueless newbies who
> > ignorantly expect a job scheduled at 2am to not only run, but run only
> > once" can be served too, by default.
>
> At minimum, the proposed change would have to be described in detail in
> the man page so that people who expect traditional cron behavior will know
> what the heck is going on when cron starts to think for itself. I would
> prefer that this new behavior be an option that is off by default, however
> there would have to be an option to turn it off if ultimately it ends up
> being the default.
I believe that there is already a bit in patch that updates the man page.
That can always be expanded. If this does make it in, it should have an
option to turn it on/off. However, I think that it should default to on.
Doug, you think that this patch is bad. The fact that this thread keeps
coming up twice a year makes me think that *something* should be done
about DST changes. Do you have alternate suggestion for what can/should be
done?
-gordon
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?Pine.BSF.4.31.0101091115020.26645-100000>