Steak and sizzle

[Eric S. Raymond]

Gary had a very good idea yesterday.  He suggested that the infrastructure
I'm creating for the Python port of ntpq could be used to create an
analog of gpsmon, the GPS monitor app in GPSD.

For those of you who've never seen it, gpsmon is pretty simple in
concept.  It's a curses program that watches a GPS in real time,
responding to each packet from the device by modifying an upper display
panel that contains breakdowns of the fields.  The lower panel is
simply a scrolling history of packets emitted.

Gary's thought was "gpsmon - the ntpq peers display updating every second
or so, continuously."  With maybe some use of color - reach-zero
servers turning red, that sort of thing.

I liked the concept immediately.  I think it solves a problem that's
been niggling at the back of my brain; where's our sizzle?

I'm extremely pleased with the state of the NTPsec codebase.  Took two
years of work, but it is now clean, lean, mean, and hardened (with one
big grotty blob left, C ntpq, that I am about to eliminate). Pretty well
tested too, with zero crashes or unexplained anomalies over many
months of operation.  In a rational world, system operators would be
falling all over themselves to buy in as fast as the word about it
gets out.

But there's a time-honored maximum that people buy the sizzle, not
the stake.  They react more to WANT! than to what they need. So, I've
been wondering; where's our sizzle?  Where's our big visible feature
that will make people *want* it?

I think ntpmon might be it.  "Look! Real-time status updates! Color!
Animation!" OK, animation only in the crudest possible sense, but
human beings undeniably do respond to this sort of thing.

Arguably ntpviz is prettier - actually, it's not arguable at all,
ntpviz is certainly prettier.  But ntpviz looks back at history; it
doesn't convey the same sense of immediacy and instant gratification
than a properly-designed ntpmon will.

I've taken a step towards this already. I've factored the code that
generates the peers display into a generator class that can be re-used
outside ntpq.  Dropping this into a fairly thin wrapper of ncurses
calls should produce an ntpmon prototype with little effort.

One reason I'm talking about this now is than on a typical 80x25
terminal emulation, a dozen or so lines of peer data is going to leave
screen space left over.  So...what else would it be interesting to
watch and update in real time?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The Bible is not my book, and Christianity is not my religion.  I could never
give assent to the long, complicated statements of Christian dogma.
	-- Abraham Lincoln