[Subject says NetBSD, but context has drifted to MacOS]
> That said, I'm going to push - not hard, not hill-to-die-on, just moderately
> - for remaining strict about our C99 conformance policy and culling old
> releases/minor platforms that can't meet it.
We aren't discussing C99 but rather the
> Nice idea, but prolly breaks some regression tests. Maybe for after 1.0?
Do we have any tests for that area?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 09/14/2017 11:46 PM, Eric S. Raymond via devel wrote:
A fair point. But...on the other hand, a major platform. Not by our
criterion, which is more or less "Are flocks of these going to be
running in $J_RANDOM_HUMONGOUS_DATACENTER?" Part of our strategy is
to optimize for the toughest, hig
(Lifted from the thread on lldexp)
Ian Bruene via devel :
> As I understood it part of the rationale for NTPsec was the yawning security
> chasms in NTPclassic. Shouldn't wide adoption therefore be highly desirable?
>
> Possible answer: Aunt Tillie is not going to hunt down NTPsec and install
> i
Hal Murray :
> It gets rid of that ugly pivot code. I think you call it a defect attractor.
Damn straight I do!
> Even if it is correct, it makes the rest of the code harder to read.
>
> I think it cleanly sets things up so that our first jump works-right time
> range is relative to build ti
Hal Murray :
>
> [Subject says NetBSD, but context has drifted to MacOS]
> > That said, I'm going to push - not hard, not hill-to-die-on, just moderately
> > - for remaining strict about our C99 conformance policy and culling old
> > releases/minor platforms that can't meet it.
>
> We aren't dis
Yo Eric!
On Fri, 15 Sep 2017 13:40:21 -0400
"Eric S. Raymond via devel" wrote:
> Yet a third implication is that support for 32-bit platforms is not
> very important either. We're doing that mainly because (a) good code
> hygiene and (b) ARM32 and similar hardware make nice microservers.
I pre
Gary E. Miller via devel :
> Yo Eric!
>
> On Fri, 15 Sep 2017 13:40:21 -0400
> "Eric S. Raymond via devel" wrote:
>
> > Yet a third implication is that support for 32-bit platforms is not
> > very important either. We're doing that mainly because (a) good code
> > hygiene and (b) ARM32 and simi
Yo Hal!
On Fri, 15 Sep 2017 00:10:51 -0700
Hal Murray via devel wrote:
> [Subject says NetBSD, but context has drifted to MacOS]
> > That said, I'm going to push - not hard, not hill-to-die-on, just
> > moderately
> > - for remaining strict about our C99 conformance policy and culling
> > old re
devel@ntpsec.org said:
> I think C99 was used here to to include the whole NTPsec policy of also
> wanting POSIX conformance. POSIX very much defines how the clock is played
> with.
POSIX defines ways to access the clock, but only the simple functions like
reading and setting the clock. It do
Hal Murray via devel writes:
> Suppose we release some code. Assume it is bug free so users are happy.
You can drop that assumption without any change to the outcome.
> How long do we expect it to run correctly?
The question really is: What should we do when we know it stops running
correctly a
>> Suppose we release some code. Assume it is bug free so users are happy.
> You can drop that assumption without any change to the outcome.
I was thinking of roughly the following:
Suppose the code is good for 20 years after the build date. That covers GPS
rollover.
If we have a security fix
Gary E. Miller via devel :
> Yo Hal!
>
> On Fri, 15 Sep 2017 00:10:51 -0700
> Hal Murray via devel wrote:
>
> > [Subject says NetBSD, but context has drifted to MacOS]
> > > That said, I'm going to push - not hard, not hill-to-die-on, just
> > > moderately
> > > - for remaining strict about our
Hal Murray via devel :
>
> devel@ntpsec.org said:
> > I think C99 was used here to to include the whole NTPsec policy of also
> > wanting POSIX conformance. POSIX very much defines how the clock is played
> > with.
>
> POSIX defines ways to access the clock, but only the simple functions like
It's Feature Freeze Friday. The window closes at 5PM, so get your
last-minute feature patches in now.
As previously noted, work should continue on tracker issues and reactive
bug fixes. We may accept two anticipated security-feature patches from
Daniel Franke. There may be a bit more slack aroun
On 9/15/17 12:16, Hal Murray via devel wrote:
My straw man is that we will support our current code in all versions of
major OSes that are supported by the vendor. But I haven't figured out what
"support" means. Does it include old versions? How old?
What happens to conservative organizations
Yo Eric!
On Fri, 15 Sep 2017 15:38:48 -0400 (EDT)
"Eric S. Raymond via devel" wrote:
> It's Feature Freeze Friday. The window closes at 5PM, so get your
> last-minute feature patches in now.
I got none, except maybe the register thing (#388), if you think that
could/should go in.
> As previou
Hal Murray via devel writes:
> If we have a security fix that requires rebuilding the code every 5 years,
> the code will keep working over GPS rollovers without any explicit action on
> our part.
That makes the assumption that the old program running gets actually
replaced by the new build.
If
devel@ntpsec.org said:
> It's Feature Freeze Friday. The window closes at 5PM, so get your
> last-minute feature patches in now.
I think you should revert the long double change and wait until post-release
to clean up that area - not just the precision part but the whole clock
adjusting area.
I've got a case where top shows ntpd is using 60-70% of the CPU. I noticed
because the fan on the box is cycling on/off.
Has anybody seen anything like that recently?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.or
Yo Hal!
On Fri, 15 Sep 2017 12:58:32 -0700
Hal Murray via devel wrote:
> devel@ntpsec.org said:
> > It's Feature Freeze Friday. The window closes at 5PM, so get your
> > last-minute feature patches in now.
>
> I think you should revert the long double change and wait until
> post-release to
On Thu, 14 Sep 2017, Hal Murray wrote:
> > The basic problem is that python2.7-config --ldflags includes "-lpython2.7"
> > but no "-L" to say where to find it. On most platforms, a suitable "-L" is
> > included.
>
> I don't know anything about that area, but your "most platforms" seems
> optimis
On Fri, 15 Sep 2017, Fred Wright via devel wrote:
> On Thu, 14 Sep 2017, Hal Murray wrote:
>
> > > The basic problem is that python2.7-config --ldflags includes
> > > "-lpython2.7"
> > > but no "-L" to say where to find it. On most platforms, a suitable "-L"
> > > is
> > > included.
> >
> > I d
Yo Hal!
On Fri, 15 Sep 2017 13:04:16 -0700
Hal Murray via devel wrote:
> I've got a case where top shows ntpd is using 60-70% of the CPU. I
> noticed because the fan on the box is cycling on/off.
>
> Has anybody seen anything like that recently?
Nope. Which driver? That is in your ntp.conf?
Gary E. Miller via devel :
> Hal Murray via devel wrote:
> > I think you should revert the long double change and wait until
> > post-release to clean up that area - not just the precision part but
> > the whole clock adjusting area.
>
> Oh, please, no. It is stable, except for the NetBSD 6 thin
Hal Murray via devel :
>
> I've got a case where top shows ntpd is using 60-70% of the CPU. I noticed
> because the fan on the box is cycling on/off.
>
> Has anybody seen anything like that recently?
No. It's well down in the noise right now on snark.
First thing to suspect on seeing that sy
devel@ntpsec.org said:
> First thing to suspect on seeing that symptom, in ntpd or gpsd, is that
> somebody's tty layer is reacting badly to the unusual ways we use ioctls.
> I've seen this before multiple times.
Thanks. That's the hint I needed.
It's working normally after a reboot. I had do
devel@ntpsec.org said:
> Reverting it would be exacly the kind of poke-the-possible-hornet's-nest
> change that we should be avoiding.
That's the part I don't understand.
The new code didn't fix any real problem. It's only been running for a few
months. We have many years on the old code.
T
>> I think you should revert the long double change and wait until
>> post-release to clean up that area - not just the precision part but
>> the whole clock adjusting area.
> It fixed a bunch of issues and starting over could take weeks.
What problems did it fix?
Do you think we need more than
Yo Hal!
On Fri, 15 Sep 2017 15:21:32 -0700
Hal Murray wrote:
> >> I think you should revert the long double change and wait until
> >> post-release to clean up that area - not just the precision part
> >> but the whole clock adjusting area.
>
> > It fixed a bunch of issues and starting over c
Hal Murray :
>
> devel@ntpsec.org said:
> > First thing to suspect on seeing that symptom, in ntpd or gpsd, is that
> > somebody's tty layer is reacting badly to the unusual ways we use ioctls.
> > I've seen this before multiple times.
>
> Thanks. That's the hint I needed.
One of the more unf
31 matches
Mail list logo
