<div dir="auto">I suspect we'll be stuck for with serial interfaces to GPS hardware for quite some time due to the NMEA-0183 "standardization".  Many systems use gpsd to talk to actual hardware and supply a processed feed on a network port, quite often on a loopback address for internal use only, e.g. Android and other mobile devices. See <a href="http://gpsd.io">gpsd.io</a><div dir="auto"><br><div dir="auto">NTPsec is a project to modernize and improve the security of NTP that has been running since 2016: they say they've slimmed down the code base to a quarter of what they forked from NTP.  See <a href="http://ntpsec.org">ntpsec.org</a></div><div dir="auto"><br></div><div dir="auto">Sam Paik</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 2, 2023, 2:49 AM Matthew Dillon <<a href="mailto:dillon@backplane.com">dillon@backplane.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The last time I looked at time sources, they were basically serial interfaces.  That was like 20 years ago though.   When I wrote dntpd I explicitly wrote it as a client-only.  So any DFly support for being a time server is going to be whatever support the open-source time daemons like ntpd have and I don't think anyone here has used their non-network time-sourcing features in ages.<div><br></div><div>I would kinda expect that modern time sources would be little GPS gadgets that vampire off the GPS timestamps and then have an ethernet interface or something, but I don't know what is typical these days.  Is serial still a thing?  I don't know.</div><div><br></div><div>-Matt</div></div>
</blockquote></div>