Re: Embedded OS

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Embedded OS

2017-11-04 Thread Hal Murray via devel
> 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

Re: Dumb ntpd server

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Dumping long double

2017-11-04 Thread Eric S. Raymond via devel
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 >

Re: Is it time to plan a move to Go?

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Embedded OS

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Dumping long double

2017-11-04 Thread Hal Murray via devel
>> 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

Re: Is it time to plan a move to Go?

2017-11-04 Thread Hal Murray via devel
>>> 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 >>

Re: Stable vs. devel releases

2017-11-04 Thread Hal Murray via devel
> 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

I'm still getting duplicate issue-closed messages

2017-11-04 Thread Hal Murray via devel
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:

Re: Is it time to plan a move to Go?

2017-11-04 Thread Eric S. Raymond via devel
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

Stable vs. devel releases

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Dumping long double

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Is it time to plan a move to Go?

2017-11-04 Thread Hal Murray via devel
> 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

Re: Getting things moving again

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Dumping long double

2017-11-04 Thread Hal Murray via devel
> 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

Re: Getting things moving again

2017-11-04 Thread Hal Murray via devel
> 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

Is it time to plan a move to Go?

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Getting things moving again

2017-11-04 Thread Eric S. Raymond via devel
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

Python library installation

2017-11-04 Thread Hal Murray via devel
> 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

Re: Mac OS X patches (Was: Re: Getting things moving again)

2017-11-04 Thread Hal Murray via devel
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

Re: Getting things moving again

2017-11-04 Thread Ian Bruene via devel
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

Re: Mac OS X patches (Was: Re: Getting things moving again)

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Mac OS X patches (Was: Re: Getting things moving again)

2017-11-04 Thread Hal Murray via devel
> 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

Mac OS X patches (Was: Re: Getting things moving again)

2017-11-04 Thread Eric S. Raymond via devel
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

Re: Getting things moving again

2017-11-04 Thread Gary E. Miller via devel
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

Re: Getting things moving again

2017-11-04 Thread Gary E. Miller via devel
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

Re: Getting things moving again

2017-11-04 Thread Mark Atwood via devel
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

Getting things moving again

2017-11-04 Thread 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