Matt Dillon wrote:
: with your rather large diff set. For better or for worse, people
: already know about the daylight savings shift problem. Thousands
: of people depend on cron to work, which means that when you
: make a major change like this it must be tested by a
: with your rather large diff set. For better or for worse, people
: already know about the daylight savings shift problem. Thousands
: of people depend on cron to work, which means that when you
: make a major change like this it must be tested by a wider audience
: for a
Neil Blakey-Milner wrote:
On Sat 2001-01-20 (16:39), Sergey Babkin wrote:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test them out.
Please let me know if you encounter any
Sergey Babkin wrote:
Neil Blakey-Milner wrote:
On Sat 2001-01-20 (16:39), Sergey Babkin wrote:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test them out.
Please let me
Sergey Babkin wrote:
Neil Blakey-Milner wrote:
On Sat 2001-01-20 (16:39), Sergey Babkin wrote:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test them out.
Please let me
On 21 Jan 2001, at 14:50, Sergey Babkin wrote:
Neil Blakey-Milner wrote:
On Sat 2001-01-20 (16:39), Sergey Babkin wrote:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test
Quoting Sergey Babkin [EMAIL PROTECTED]:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test them out.
Please let me know if you encounter any problems caused by them
(and better do that
Greg Black wrote:
Sergey Babkin wrote:
Neil Blakey-Milner wrote:
On Sat 2001-01-20 (16:39), Sergey Babkin wrote:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to
The problem here has nothing to do with whether changing the behavior
is good or bad, and everything to do with the fact that cron is an
absolutely critical core piece of software that runs on these machines
and there is no guarentee that you haven't introduced one or many bugs
Doug Barton wrote:
Sergey Babkin wrote:
Neil Blakey-Milner wrote:
On Sat 2001-01-20 (16:39), Sergey Babkin wrote:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to
Lawrence Sica wrote:
Quoting Sergey Babkin [EMAIL PROTECTED]:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test them out.
Please let me know if you encounter any problems caused
Matt Dillon wrote:
The problem here has nothing to do with whether changing the behavior
is good or bad, and everything to do with the fact that cron is an
absolutely critical core piece of software that runs on these machines
and there is no guarentee that you haven't
On Fri 2001-01-19 (12:44), Matt Dillon wrote:
:I'm just editing the PR with the cron patches to "catch up" with
:OpenBSD in this respect (stating that it doesn't handle DST, but
:has benefits whenever one's clock is jumping or cron waking up
:too late and _could_ be extended to handle DST).
On Wed, Jan 17, 2001 at 18:48 +0100, Gerhard Sittig wrote:
I'm just editing the PR with the cron patches [ ... ]
So it finally happened. It's filed as "bin/24485: [PATCH] to
make cron(8) handle clock jumps" and got archived at
http://www.freebsd.org/cgi/query-pr.cgi?pr=24485
I don't see it
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test them out.
Please let me know if you encounter any problems caused by them
(and better do that before these changes would be MFCed to -stable
in
On Sat 2001-01-20 (16:39), Sergey Babkin wrote:
All,
I've committed these changes for cron to support DST change
to -current (see PR bin/24494 for description of my tests).
Everyone is welcome to test them out.
Please let me know if you encounter any problems caused by them
(and better do
:I'm just editing the PR with the cron patches to "catch up" with
:OpenBSD in this respect (stating that it doesn't handle DST, but
:has benefits whenever one's clock is jumping or cron waking up
:too late and _could_ be extended to handle DST). Therein I
:suggest to
:- not touch current cron at
On Wed, Jan 17, 2001 at 06:43 +1000, Greg Black wrote:
Gerhard Sittig wrote:
In http://www.freebsd.org/cgi/query-pr.cgi?pr=24358 ("/etc/rc
variables for cron(8)") I suggest how to provide knobs to
pass parameters to cron as well as to switch to a different
cron executable, while of
On 17 Jan 2001, at 18:48, Gerhard Sittig wrote:
I'm just editing the PR with the cron patches to "catch up" with
OpenBSD in this respect (stating that it doesn't handle DST, but
has benefits whenever one's clock is jumping or cron waking up
too late and _could_ be extended to handle DST).
Gerhard Sittig wrote:
I'm just editing the PR with the cron patches to "catch up" with
OpenBSD in this respect (stating that it doesn't handle DST, but
has benefits whenever one's clock is jumping or cron waking up
too late and _could_ be extended to handle DST). Therein I
suggest to
-
On Wed, Jan 10, 2001 at 08:51 +1000, Greg Black wrote:
If any change to expected cron behaviour is to be introduced,
the traditional behaviour must be the default, with a knob
documented in the man pages that can be twisted to get the
oddball behaviour that is being proposed here.
In
Gerhard Sittig wrote:
On Wed, Jan 10, 2001 at 08:51 +1000, Greg Black wrote:
If any change to expected cron behaviour is to be introduced,
the traditional behaviour must be the default, with a knob
documented in the man pages that can be twisted to get the
oddball behaviour that is
On 1 Jan, Doug Barton wrote:
Gerhard Sittig wrote:
[ ... reminder after two weeks of silence ... ]
Two weeks of silence is generally enough to let you know that no one is
interested in this modification. If someone was, they'd generally have
said something by now.
John Gregor wrote:
What would happen if the definitions of the hour and minute fields
were subtly changed to mean "elapsed wall-clock time since local
midnight"? Then, the DST conversion is no longer ambiguous. "Two
hours since local midnight" only happens once regardless. On days
where
If someone wants to tackle this, a few words to the wise.
* testing for daylight savings times changes. You test this by comparing
the differential between two time_t's (dtime1) against the differential
between two time_t's after converting them to localtime and then back
On Thu, Jan 11, 2001 at 01:05 -0800, Doug Barton wrote:
Gerhard Sittig wrote:
Looking at the echo returning so far
Which represents a very small percentage of the people who need
to look at the change. A significant percentage (probably a
majority) of the people who are freebsd
On Thu, Jan 11, 2001 at 13:19 -0500, Darren Henderson wrote:
On Wed, 10 Jan 2001, Gerhard Sittig wrote:
Looking at the echo returning so far I see _much_ more "yes"
than "nope" answers. There's consent that *something* has to
be done.
Heh, if its votes you are looking for then you
[ for the impatient there's a summary at the bottom ("/summarize") ]
On Thu, Jan 11, 2001 at 16:33 +1000, Greg Black wrote:
Gerhard Sittig wrote:
I take notice of your (and Greg Black's) reservation / being
opposed, respect it and conclude that the change will have to
- default to the
One of the things that would need to be documented is what will
happen to the new algorithm in the situation where cron is
stopped and re-started during one of the time periods that gets
repeated.
Oh, you bring up an absolutely new datapoint it seems! Since all
the information
Could you guys remove my name from the Cc: list on this thread please?
I've already made my position quite clear.
Thanks,
Doug
--
"The most difficult thing in the world is to know how to do a thing and
to watch someone else do it wrong without comment."
--
delurk
Ok, this has gone on long enough that my normal inhibitions about
driving down the signal-to-noise ratio of a technical list have
long subsided.
Folks, cron is a *LOW LEVEL SERVICE* much in the same vein as UDP.
Neither one makes strong guarantees about ordering, duplication,
or dropped
Gerhard Sittig wrote:
On Thu, Jan 11, 2001 at 16:33 +1000, Greg Black wrote:
BTW: There's good news for those with a dislike regarding
the change: While testing I'm stuck again, so there will be
some more delay.
Previously we were told that this stuff had already been tested
FWIW, I'm against changing cron.
Ted Faber said it best:
If someone wants to change cron's behavior to make DST (and
other timezone shenanigans) behave intuitively, add a flag to
make cron work exclusively in UTC as someone else suggested.
It's simple to explain which means less user
Gerhard Sittig wrote:
On Tue, Jan 09, 2001 at 02:14 -0800, Doug Barton wrote:
Gerhard Sittig wrote:
It's not that I want to talk you into something you don't
want.
But that's exactly what you're trying to do.
Honestly -- no! :)
Alright, I give up. Your post just
On 11 Jan 2001, at 17:06, Greg Black wrote:
And, as I said previously, I'd want to know how the new code
coped with cron being stopped and restarted during one of the
DST transition times, as well as seeing assurances that the
legacy version would do the same thing then as it does now.
If
Hi,
And, as I said previously, I'd want to know how the new code
coped with cron being stopped and restarted during one of the
DST transition times, as well as seeing assurances that the
legacy version would do the same thing then as it does now.
The legacy version only checks for jobs that
Dan Langille wrote:
On 11 Jan 2001, at 16:33, Greg Black wrote:
We'd need some guarantees that the attempt to maintain current
behaviour was done correctly -- i.e., without introducing bugs
that broke things.
What sort of guarantees are acceptable?
In the beginning, something
I know I'm going to regret this, but since silence is being taken to
be consent here, I'd better speak up. My opinion, for those keeping
count:
Changing cron to internally compensate for changing timezones seems to
open more doors for bugs and misfeatures than it closes. FreeBSD is
in use
On Wed, 10 Jan 2001, Gerhard Sittig wrote:
Looking at the echo returning so far I see _much_ more "yes" than
"nope" answers. There's consent that *something* has to be done.
Heh, if its votes you are looking for then you can add another to your
"nope" column for what its worth. The current
On 9 Jan 2001, at 10:20, Doug Barton wrote:
And when you finally realize that everyone else thinks this is a great
idea,
I do not like being included in "everyone". I don't think it's a great idea.
In fact, I'm quite sure that this is not true. I happen to be the only one
who
On Wed 2001-01-10 (21:20), Dan Langille wrote:
And when you finally realize that everyone else thinks this is a great
idea,
I do not like being included in "everyone". I don't think it's a great idea.
If you didn't miss the comment, I was (and am now) attempting to emulate
Doug's
On 10 Jan 2001, at 11:24, Neil Blakey-Milner wrote:
These changes have been tested in OpenBSD for 3 years.
That's a relatively smaller user-base compared to FreeBSD. Do you
consider that sufficient?
The "solution"
is _not_ to tell people they're stupid to schedule jobs during the
On Wed 2001-01-10 (22:35), Dan Langille wrote:
That's a relatively smaller user-base compared to FreeBSD. Do you
consider that sufficient?
I would, yes, considering it has been three years. You may feel free to
disagree, of course, and I'll get to why next:
I don't see how the above
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
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
Well, we've obviously hit a hot button issue for you here Neil,
for reasons that I don't pretend to understand. Please try to reduce the
amount of emotion that's going into your argument It's just a
computer thing after all. :)
On Wed, 10 Jan 2001, Neil Blakey-Milner wrote:
On
On Tue, 9 Jan 2001, Gordon Tetlow wrote:
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
On Wed, 10 Jan 2001, Neil Blakey-Milner wrote:
To summarise: It is broken,
According to your definition of broken, which we have not
necessarily reached a consensus on.
Not only that, but people who don't understand that it is broken are
unable to understand simple facts.
Neil Blakey-Milner wrote:
On Wed 2001-01-10 (21:35), Greg Black wrote:
To summarise: It is broken, we have the fix,
No. You believe it is broken; you believe you have a fix. Not
everybody agrees that it is broken or that any fix is required.
Fiddling with cron to work around
On Tue, Jan 09, 2001 at 02:14 -0800, Doug Barton wrote:
Gerhard Sittig wrote:
It's not that I want to talk you into something you don't
want.
But that's exactly what you're trying to do.
Honestly -- no! :) OK, I've been unclear there. I did reply to
your message, but writing to
[ note to nbm: would you like getting cc'ed, too? I'm used to
keep receiver lists as short as possible, but feel free to state
your wishes :) ]
On Tue, Jan 09, 2001 at 10:20 -0800, Doug Barton wrote:
Neil Blakey-Milner wrote:
Now, consider NTP calibrations,
. . .
Your example
Gerhard Sittig wrote:
I take notice of your (and Greg Black's) reservation / being
opposed, respect it and conclude that the change will have to
- default to the current behaviour (something quite usual for
expanding changes)
We'd need some guarantees that the attempt to maintain current
"Dan Langille" wrote:
On 11 Jan 2001, at 16:33, Greg Black wrote:
We'd need some guarantees that the attempt to maintain current
behaviour was done correctly -- i.e., without introducing bugs
that broke things.
What sort of guarantees are acceptable?
It would need to be tested
Gerhard Sittig wrote:
[ citing from Doug's message in the "OT: silence ..." subthread
to keep the technical discussion in the "how to test" subthread ]
On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote:
You stated in another post that you wished I had elaborated
more. I was in a
On Tue, 9 Jan 2001, Doug Barton wrote:
But that's exactly what you're trying to do. I will not bother to
re-re-restate my points as to why what you're proposing is a bad idea.
Do all the testing you want, but make sure you understand that there
will be vigorous resistance to
On Tue 2001-01-09 (02:14), Doug Barton wrote:
Gerhard Sittig wrote:
[ citing from Doug's message in the "OT: silence ..." subthread
to keep the technical discussion in the "how to test" subthread ]
On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote:
You stated in another
Neil Blakey-Milner wrote:
On Tue 2001-01-09 (02:14), Doug Barton wrote:
Gerhard Sittig wrote:
You're blowing the significance of this part of your argument WAY out
of proportion. After long discussion we've picked times for the periodic
jobs that are the best overall choices,
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
Doug Barton wrote:
Neil Blakey-Milner wrote:
On Tue 2001-01-09 (02:14), Doug Barton wrote:
Gerhard Sittig wrote:
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
On Wed 2001-01-10 (08:51), Greg Black wrote:
If any change to expected cron behaviour is to be introduced,
the traditional behaviour must be the default, with a knob
documented in the man pages that can be twisted to get the
oddball behaviour that is being proposed here.
The oddball
[ citing from Doug's message in the "OT: silence ..." subthread
to keep the technical discussion in the "how to test" subthread ]
On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote:
You stated in another post that you wished I had elaborated
more. I was in a hurry when I wrote that post,
I like these changes.
I'm definitely in favor of code that corrects for the DST handling
oddities that sysadmins have to deal with. This would be especially
valuable for companies which might have deployments in 25 different
time zones globally, which for reasons that are out of scope can't
On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote:
Speaking only for myself, I don't think your proposed changes
are a good idea, which is why I refrained from offering any
suggestions on how you can test them.
Your refusal(id?) has been the only response so far and it didn't
sound
Gerhard Sittig wrote:
Is there anyone out there who feels like rejecting the proposal
for a *reason*? Or to accept the idea, but to redirect the
effort to a "real solution"? I somehow doubt you'd rather
explain again and again that cron(8) isn't broken but that users
should shuffle around
On Wed, Jan 03, 2001 at 02:38:30PM +1000, Greg Black scribbled:
| Gerhard Sittig wrote:
| Is there anyone out there who feels like rejecting the proposal
| for a *reason*? Or to accept the idea, but to redirect the
| effort to a "real solution"? I somehow doubt you'd rather
| explain again
Gerhard Sittig wrote:
[ ... reminder after two weeks of silence ... ]
Two weeks of silence is generally enough to let you know that no one is
interested in this modification. If someone was, they'd generally have
said something by now.
Speaking only for myself, I don't think
[ ... reminder after two weeks of silence ... ]
On Tue, Dec 05, 2000 at 22:56 +0100, Gerhard Sittig wrote:
[ I'm not subscribed to -hackers, please keep CC'ing me; thanks! ]
[ ... ]
This took the DST handling code of OpenBSD's cron, leaving the
other diffs / details (capabilities,
[ I'm not subscribed to -hackers, please keep CC'ing me; thanks! ]
On Mon, Nov 20, 2000 at 19:33 +0100, Gerhard Sittig wrote:
[ ... cron and DST ... ]
But I thought modifying cron(8) itself would be the best way.
Is someone already working on this or should I try to do it
myself (within
68 matches
Mail list logo
