Hal Murray :
>
> > However, the Go developers have stated that this is one of their major aims,
> > and it is easy to believe they will be funded to do this because the
> > business case for moving a lot of Google's Android devevelopment is *quite*
> > clear.
>
> I
> However, the Go developers have stated that this is one of their major aims,
> and it is easy to believe they will be funded to do this because the
> business case for moving a lot of Google's Android devevelopment is *quite*
> clear.
I thought Android is/was derived from Linux. Has it
Hal Murray :
>
> >> Write a dumb NTP server in Go. The idea is to move ntpd
> >> to a different port number so the new code can answer
> >> client requests. This assumes that a server can get all the
> >> info it needs from the kernel. That may be bogus, but
> >> I
Hal Murray :
>
> >> We ran for years without long doubles. There were no destabilizing
> >> problems.
>
> > No, but changing the code *back* before 1.0 was a thing I didn't want to do.
>
> I was surprised you put that change in that close to 1.0. Taking it back
>
Hal Murray :
> >>> libntp
> >> Why do we need a python extension? Can't we convert ntpclients to Go?
> > Yeah, that'd be be kind of a mess. ...
>
> Then we leave that chunk of libntp available for Python. It won't be very
> big.
>
>
> >> Maybe that would be a good
Hal Murray :
> >> Is Go well supported on ARM? (how about powerpc which is other-endian?)
> > According to the Go documentation, both are fully supported.
>
> How about embedded OSes?
>
> Has anybody managed to get ntpsec running on an embedded OS? Where is that
> on
>> We ran for years without long doubles. There were no destabilizing
>> problems.
> No, but changing the code *back* before 1.0 was a thing I didn't want to do.
I was surprised you put that change in that close to 1.0. Taking it back
should have been a simple revert.
> I rememenber now
>>> libntp
>> Why do we need a python extension? Can't we convert ntpclients to Go?
> Yeah, that'd be be kind of a mess. ...
Then we leave that chunk of libntp available for Python. It won't be very
big.
>> Maybe that would be a good time to split the refclocks out to separate
>>
> I have become opposed to forking stable releases ...
Even if we don't fork, we need the same structure in version numbers to
handle backporting of bug fixes.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
Delivery-date: Sat Nov 4 17:56:59 2017
Message-id:
Subject: Re: ntpsec | ntpd build fails: undefined reference to
`addr_from_typeunit' (#406)
From: "Eric S. Raymond"
Date: Sun, 05 Nov 2017 00:41:50 +
To:
Hal Murray :
> > Thoughts?
>
> Is Go well supported on ARM? (how about powerpc which is other-endian?)
According to the Go documentation, both are fully supported.
> > * libntp is a problem - ideally we want to have the Python extension
> > that wraps it call compile
Hal Murray :
> >From devel/hacking.txt
> > When the minor number is even, it refers to a "stable" release, and when the
> > minor number is odd, it refers to a "development" release. New releases on
> > "stable" are generally bugfixes that are backported from it's matching
Hal Murray :
>
> > Dropping long double opened a can of worms about overflow/precision problems
> > and how to redo the pivot logic that I didn't want to broach while were
> > trying to avoid destabilizing changes.
>
> We ran for years without long doubles. There were
> Thoughts?
Is Go well supported on ARM? (how about powerpc which is other-endian?)
> * libntp is a problem - ideally we want to have the Python extension
> that wraps it call compile Go rather than C, but that could be
> difficult to arrange.
Why do we need a python extension? Can't we
Hal Murray :
> Would you please fix the VERSION string and update the text in
> devel/hacking.txt to clarify what should get bumped after a release. Should
> it go to 1.0.1 or 1.1.1?
I set it at 1.0.1. I'm expecting 1.1 to be the next minoe release.
> The release
> Dropping long double opened a can of worms about overflow/precision problems
> and how to redo the pivot logic that I didn't want to broach while were
> trying to avoid destabilizing changes.
We ran for years without long doubles. There were no destabilizing problems.
> Now would be a
> We have some loose ends from 1.0 to clean up. I took care of a few of them
> today;
Would you please fix the VERSION string and update the text in
devel/hacking.txt to clarify what should get bumped after a release. Should
it go to 1.0.1 or 1.1.1?
The release recipe should also get
Here's my big question about the next year of development: should we
be moving the codebase out of C to Go?
I think the project is feasible and the potential gains are large, but
I don't want to start anything without being sure our senior devs are
happy with the idea. This means everybody's
Ian Bruene via devel :
> Current tasks that I see are:
>
> * Filling out the MIB.
>
> * Implementing the rest of the packet types.
>
> * "UI", aka. allowing the daemon to use different communication channels
> with the master agent, expanded logging, etc.
>
> I believe it is
> As it is now, the OS installed version of ntpd will conflict with a source
> installed version. Not good. FHS compliance would be nice.
I think it would be really helpful if somebody would write up something that
covered this whole area.
I don't understand this area well enough to explain
devel@ntpsec.org said:
> I thought that was still under some discussion when we shipped. Remind me
> what the patch was?
I got the impression that you pretty much vetoed it and/or weren't interested
in more discussion. I could easily have misread whatever you said.
I think we should dump
On 11/04/2017 04:54 PM, Eric S. Raymond via devel wrote:
* I would like us to plan on a short-cycle 1.1, to land early January,
with SNMP support as the big new feature. Ian: is this a realistic
timeframe?
Current tasks that I see are:
* Filling out the MIB.
* Implementing the rest
Hal Murray :
>
> > Remember, without this patches we still have support for the *current* Mac
> > OS X, just not far back into older ones. I think that is a sufficient
> > gesture for our purposes.
>
> > Opinions of other solicited.
>
> We decided not to put in a
> Remember, without this patches we still have support for the *current* Mac
> OS X, just not far back into older ones. I think that is a sufficient
> gesture for our purposes.
> Opinions of other solicited.
We decided not to put in a trivial patch that would make things work for
older
Mark Atwood :
> I'm inclined to say yes to the MacOS patches, but I want to hear the
> discussion, and read the patches myself.
I'm inclined to say no, though it's not a hill I'd die on. (1) I want to
stand strong about platform standandards conformance lest we get
Yo Eric!
On Sat, 4 Nov 2017 17:54:13 -0400 (EDT)
"Eric S. Raymond via devel" wrote:
> * Fred and Gary need to have, and resolve, their argument about what
> to do to the build recipe around Python library installation. For
> concreteness, this should probably start with a
Yo Mark!
On Sat, 04 Nov 2017 22:20:01 +
Mark Atwood via devel wrote:
> I'm also interested in the status of the latest NTP Internet Drafts.
> Are they solid enough for implementation?
I look at it the other way around. IETF used to be about running code
before
I'm also interested in the status of the latest NTP Internet Drafts. Are
they solid enough for implementation?
I'm inclined to say yes to the MacOS patches, but I want to hear the
discussion, and read the patches myself.
..m
On Sat, Nov 4, 2017, 2:54 PM Eric S. Raymond via devel
Apologies to all for having been rather invisible recently. What
happened was I got an emergency call for help from a project we rely on -
GNUPLOT. (Perhaps not everyone knows this is the graphics engine we use
in ntpviz, which is one of our sexier new features.)
It seems that SourceForge, where
29 matches
Mail list logo