Yo Eric! On Thu, 5 May 2016 16:04:26 -0400 "Eric S. Raymond" <e...@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
g...@rellim.com Tel:+1 541 382 8588
pgpDTFuCfYiPc.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
