ntpmon now has some keystroke commands

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> > You can already do 'ntpq -c cv [associd]' with...ntpq.  Why do you
> > consider it's desirable to duplicate that function in ntpmon?
> 
> I don't dedire to duplicate.  I want to not break a long standing tool
> (ntpq) and help create a much improved new tool (ntpmon).
> 
> The ntpq way to dig out data is pain to use and painful to understand.
> Putting ALL the data related to an associd in one place, and formatting
> it in a pleasing manner will make the data much easier to use and
> understand.

That is true.  I don't think ntpmon is the right place for this improved
report, though.  One good reason is that it's not practically possible
to *pipeline* a TUI.  In order to preserve forward options, Unix principles
say you should put this kind of report generation in a CLI program that
can be scripted.  Recent practice would prefer reporting in JSON.

Thus, in this case, probably ntpq. Or possibly a freshly-designed CLI
tool if we find enough use cases to justify the effort.  (Possible,
but doubtful.)

Notice carefully the distinction between a TUI (or GUI) optimized for
reactive use by a human being and a CLI designed partly for eyeball
use and partly to be scripted. That is central here.  One needs to
think about how those design patterns fit (or don't fit) with
*particular* use cases.

> > I think you're in too much of a rush to load features on a new toy
> > and are failing to think about separation of function as you should.
> 
> Well, you did ask.

I did ask. And I've extracted something useful from your response: we
need a better detail-reporting mechanism for peers and clocks. The
assumption you made and failed to question was about where this
mechanism should live.  But we'll figure out something useful to
do about it.

I'm explaining my thought processes in detail because I think it is
never a bad idea for (a) programmers to get more clued in about the
system-architect perspective in general, and (b) developers on *this*
project to understand how tech lead thinks and where he might zig or
zag next.

>                The fact that some ntpq associations was broken for
> long jsut demonstrates the problems with ntpq that ntpmon can
> solve.

I've been meaning to brief you on what I found out about this.  It
turns out to be due to a fundamental problem in the Mode 6 data model,
not a contingent problem in ntpq (neither the C nor Python
versions). I'll explain in detail in a separate thread.

> > Well, "should" in an ideal world, anyway.  In the real world, you
> > have some excuse because defending the cleanliness of the
> > architecture against featuritis is my job.
> 
> OTOH, things like the sync distance can be broken for so long because
> of a lack of data transparency.

In theory you're absolutely right and I support your point.

In practice, the actual culprit in this particular (sync-distance)
case happened to be elsewhere.  Buttonhole me if you care; unlike the
data-model problem I just hinted at, it's a minor enough issue that
I'm not motivated to write about it.

> > The design intention of ntpmon is to provide a fast, near-real-time
> > view that warns you when some condition might be deviating from the
> > expected. If you want to drill down, that's what ntpq is for.
> 
> Well, sort of.  For historic reasons we do not want to change ntpw
> too much.
> 
> > Instead of trying to make ntpmon do things ntpq does well already,
> > you should be asking yourself what a TUI program like ntpmon can do
> > well that a CLI program like ntpq cannot.
> 
> I agree, with the caveat that ntpq does few thinsg well.

And here is another assumption you should have questioned.  (But,
again, in an ideal world.  In practice, it's *my* job to think about
this level of the design - it's helpful if you're good at that too and
I encourage people to get better at it, but it's not strictly
necessary.)

Am I afraid that changing ntpq will irredeemably piss off a lot of
time grognards?  Actually, no.  If I were to change the behavior of
*existing commands* incompatibly without an extremely good reason
that would be a thing to fear. But I'm not stupid enough to do that.

One of the advantages of a CLI over TUIs and GUIs is that it's
generally easier to add new features in such a way that they
don't get in veterans users' faces.

On top of that...to be honest I think we could break everything but
ntpq -p and less than 5% of the userbase would even notice. Not that
I'm going to actually *do* that, there's no need...but that evaluation
leaves us wiggle room.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161213/bc6e21e1/attachment.bin>