From owner-freebsd-hackers Tue Jan 9 11:35:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id 83C5B37B402 for ; Tue, 9 Jan 2001 11:35:20 -0800 (PST) Received: (qmail 17881 invoked by uid 1078); 9 Jan 2001 19:35:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jan 2001 19:35:30 -0000 Date: Tue, 9 Jan 2001 11:35:30 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Doug Barton Cc: Neil Blakey-Milner , Gerhard Sittig , Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <3A5B5656.E2AAF0B5@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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