Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
e...@thyrsus.com said: >> CSV is readable by eye without a lot of effort. JSON is close to encrypted. > Say *what*? Uh, I can only conjecture that you don't have a lot of actual > experience with JSON. I admit that "encrypted" is an exaggeration, but the signal-noise is pretty low. Yes, if

Re: ntpq: cruft/doc

2016-10-16 Thread Gary E. Miller
Yo Hal! On Sun, 16 Oct 2016 13:50:28 -0700 Hal Murray wrote: > g...@rellim.com said: > > I was unaware of RFC 4180, and it mandates CRLF as line ending, not > > the \n that I used. I just pushed a fix to this. Someone familiar > > with RFC4180 should check the format is correct. > > My gue

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
g...@rellim.com said: > And I can't count the number of times people have asked me what the units > are because they can't figure it out. You should not have to read pages of > docc to find the current units. But I shouldn't have to waste valuable screen real estate to tell you what the units a

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
g...@rellim.com said: > I was unaware of RFC 4180, and it mandates CRLF as line ending, not the \n > that I used. I just pushed a fix to this. Someone familiar with RFC4180 > should check the format is correct. My guess is that's for network traffic rather than local files. If you make a loc

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Gary E. Miller : > And I can't count the number of times people have asked me what the > units are because they can't figure it out. You should not have to read > pages of docc to find the current units. > > Check out chronyc, they do a lot of things much better than ntpq. I readily believe both

Re: ntpq: cruft/doc

2016-10-16 Thread Gary E. Miller
Yo Hal! On Sun, 16 Oct 2016 03:27:54 -0700 Hal Murray wrote: > I think it's nice if the columns line up. The only time that I > remember recently when the current stuff didn't work is that you > can't see what's going on when the offset is less than a microsecond. Yeah, it is nice when they li

Re: Progress on pyntpq

2016-10-16 Thread Eric S. Raymond
Hal Murray : > > e...@thyrsus.com said: > > I don't have any pressing things to do right now ... > > What about the broken shared-key crypto? > > What about peer not working? Those are both fallout from Daniel's refactoring of the protocol machine. Daniel told me over Signal a few days ago tha

Re: ntpq: cruft/doc

2016-10-16 Thread Gary E. Miller
Yo Eric! On Sun, 16 Oct 2016 15:14:19 -0400 "Eric S. Raymond" wrote: > > Many CSV files have a comment line on top with the field names. > > Good idea. Gonna be *mandatory* for anybody generating CSV in our > pond. Also strict conformance to RFC4180, at pain of my extreme > displeasure. Data

Re: Progress on pyntpq

2016-10-16 Thread Hal Murray
e...@thyrsus.com said: > I don't have any pressing things to do right now ... What about the broken shared-key crypto? What about peer not working? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntps

Progress on pyntpq

2016-10-16 Thread Eric S. Raymond
Hal and Gary talking about improving ntpq refocused my attention. I don't have any pressing things to do right now (that's good - that means our hard work has brought the code close to a 1.0 state) so I took another whack at adding some capabilities to pyntpq in order to scope the job of turning i

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Hal Murray : > > >> The first question is What does "mobilize" mean? > > Is that a rhetorical question? > > No, unfortunately, that's a serious question. I think it has some fine-print > meaning that I don't yet understand. Damn, I was afraid you were going to say that. Because I share your s

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Hal Murray : > > e...@thyrsus.com said: > > About CSV, while I'm not opposed to it we have a practice guideline to use > > JSON for machine-parseable output. One reason is that JSON is better at > > being self-describing - the field names give you clues that CSV doesn't. > > CSV is readable by e

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
>> The first question is What does "mobilize" mean? > Is that a rhetorical question? No, unfortunately, that's a serious question. I think it has some fine-print meaning that I don't yet understand. If it wasn't for this discussion, I would assume it meant something like create a peer struct,

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
e...@thyrsus.com said: > About CSV, while I'm not opposed to it we have a practice guideline to use > JSON for machine-parseable output. One reason is that JSON is better at > being self-describing - the field names give you clues that CSV doesn't. CSV is readable by eye without a lot of effort.

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Hal Murray : > The first question is What does "mobilize" mean? Is that a rhetorical question? If you know the answer, it should go in the documentation. If you don't, you should dig up the answer and then it should go in the documentation. > Nit: there are some typos in docs/includes/ntpq-body

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Gary E. Miller : > > The other is the UI? Do you prefer fancy click-around GUIs, or > > dumb/simple CLI with text output? > > I'm for a nice little text output CLI tool. Mostly for quick data > visualization on very dummb servers. Maybe with an optional csv output > so it can be used in a tool

Re: no_sys_peer

2016-10-16 Thread Achim Gratz
Hal Murray writes: > I'm seeing things like this: > remote refid st t when poll reach delay offset jitter > == > 0.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.001 > 1.u

Re: Build broken on NetBSD and FreeBSD

2016-10-16 Thread Eric S. Raymond
Hal Murray : > ../../libntp/machines.c:92:5: error: 'struct timex' has no member named 'time' > ../../libntp/machines.c:101:5: error: 'struct timex' has no member named > 'time' Fixed, I think. I don't have a *BSD test system. Sorry about the belated response, my meatspace life has been sistrac

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
g...@rellim.com said: >> If you were starting over, what would you do? I think there are two >> parts to that question. One is the on-wire API. > I think we are stuck with that part. RFC's right? There is nothing that says we can't add new stuff. I've been happy with the shift from mode 7 (b