[gpsd-dev] New 0.5 draft of the SemPiTernal HOWTO

[Gary E. Miller]

Yo Eric!

On Thu, 5 May 2016 16:04:26 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> I'm familiar with all these arguments.  But sometimes the right
> short-term solution is opposite to the best thing in the long term.

I think we are mostly in agreement.  Short term we need #20, long term
it is cruft.

> It's not clear why refclock 20
> should survive thaat transition when gpsd is already better at
> adapting to weird sentence inventories than it is.

Here is our disagreement.  It is exactly the automagic adaptation that
can make gpsd perverse for the job of timekeeping.  For proveable
security and stability you sometimes prefer minimalism and to lock things
down, like baud rate, etc.  So much code to audit, not required for ntpd.

For example: I would hate to see someone fuzzing the serial input of gpsd!

Or maybe I would, just not me.  :-)

In the very long term, I'd like to see the gpsd NMEA parser as a module
that can be standalone for use with ntpd.

Or, maybe looking at in the inverse manner, have a gpsd that can be
stripped down to the bare minimum for ntpd use.

I see a trend in GPS to emit basic NMEA, and move the fun stuff into 
proprietary and binary.  Since ntpd only needs the basic NMEA it need
not have the bulk of gpsd's drivers.

Maybe call it gpsd-lite.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160505/048c46bd/attachment.bin>