NTPsec is not quite a full rewrite
esr.ibiblio.org
esr.ibiblio.org
* strcpy, strncpy, strcat: Use strlcpy and strlcat instead.
* sprintf, vsprintf: use snprintf and vsnprintf instead.
* In scanf and friends, the %s format without length limit is banned.
* strtok: use strtok_r() or unroll this into the obvious loop.
* gets: Use fgets instead.
* gmtime(), localtime(), asctime(), ctime(): use the reentrant *_r variants.
* tmpnam() - use mkstemp() or tmpfile() instead.
* dirname() - the Linux version is re-entrant but this property is not portable.
And so, instead of competent systems code of 1995 vintage, we get ESR code of 1998 vintage.Presumably, someone else, somewhere else, is solving the problem that needs to be solved, which is to get an NTP implementation that is simple but complete enough for the 98% use case deployed based either on thoroughly modern C code (which looks nothing like a heap of strlcats and snprintfs) or a safer language, like Rust or Go.
Maybe that's ntimed, maybe it's something else. It's not this, whatever the hell this is going to turn out to be.
It's very hard to quantify or even make specific rules about quality. These rules are just the basics. The strlcpy rule in particular is simplified, there are times when you need to use strncpy: when the source string might not be terminated (but openbsd guys say they use memcpy in that case ... anyway, it takes some thought).
2004 vintage C code is the sweet spot for portable systems software right now IMHO. But the real difference in quality can't be identified by any simplistic rule or attribute.
In particular, would you recommend to do string handling with some string library (e.g. glib has one?), or just use the mem*() functions and manually keep track of the lengths, or what?
Yes: do string handling with high-level string abstractions. No, don't try to freelance it with the mem-() functions.
esr on 2015-10-09 at 09:22:05 said:
>Eric, what do you think of ntimed and their goal of replacing ntpd?
PHK is a bright guy with many clues. I respect him a lot, and I say this despite the fact that he’s hostile to me because he thinks my open-source advocacy has encouraged crappy programming. I have not looked closely at ntimed but I have little doubt it is high-quality work, probably as good as anything I am capable of producing, possibly better.
That said, I think ntimed is going nowhere. A clean-sheet design was the right thing from a technical point of view, but it’s not what the time-service userbase wants. Large time-service users are intensely conservative and risk-averse; what they want, and what NTPsec will deliver, is not radical innovation but a cleaned-up and hardened version of what they know.
The only active GitHub ntimed fork is for the Amiga/AROS version, and phk's GitHub visible work as of late seems to be mostly on Varnish Cache.
Ok, that is just precious. =) One is a kernel hacker and time-nuts regular with one of the world's most precise clocks in his home, and the other recently wrote:
> There’s a longstanding legend that only Dave Mills ever really understood the Byzantine time-synchronization algorithms at NTP’s heart, but I used to be a mathematician and I think I already get most of it outside of a few arcana about statistical filtering of noisy signals.
From a purely technical standpoint, I know who I'd bet my money on.
By the way, phk recently mentioned that he was getting back into ntimed, so fingers crossed that we get two safe and correct NTP alternatives in the observable future.
And it bears mentioning that ESR has been working on GPSD for more than a decade (a daemon to extract accurate time from GPS receivers), and he sure sounds math literate to my not entirely untutored ears in various discussions over the years.
Given the well known curse of total rewrites, which I've experienced myself, I too know who I'd bet my money on.
This is the standard ESR parlor trick. Eric took several courses in math and philosophy at the University of Pennsylvania.
http://poynder.blogspot.com/2006/03/interview-with-eric-raym... "As a freshman at the University of Pennsylvania Raymond was immediately marked out as a potential math prodigy. Having found school insufficiently stretching for his above average talents, however, he lacked the necessary discipline or emotional maturity to cope with the demands of an undergraduate course, and after suffering a "math burnout" left without a degree."
I'd put my money on phk. Every. Time.
Timekeeping and location calculation is very easy to do clean sheet. That is, until you start to hit corner cases and exceptions and the realities of physical real world inputs like jitter and offset and dispersion (and those are just the grit that ntpq tells you about) and all the crud humans made up like leap seconds and calendrical calculations.
My money's on the guy who's been blowing the grit out of the machine.
Sure, ESR is kind of silly, but I don't understand the animus here on HN. ISTM he isn't making anything worse. Somebody wanted NTP "Classic" improved, and they decided to pay ESR to do it. It's not as though his patches or those of his collaborators would have been incorporated into ntimed anyway. Maybe some people think that work like this should only be done by a PhD with the approval of a committee of PhDs. ESR has been pretty consistent in all his voluminous writings, that he does not agree with that development philosophy.
However I sympathize with everyone in this thread who runs ntpdc on his Lisp machine.
But the man's writing - and that statement in particular - is just so pompous. And here of all cases we have two opposites colliding. One is a world-class expert on the topic in question, NTP, and the other is a world-class self promoter. So when esr says that Kamp might `possibly produce something better` than him while working on an ntpd successor, I can't help but smile. =)
Seriously? More precise than the clocks in national labs that contribute to the derivation of UTC? (USNO, NRL, NIST, NPL, NRC, etc) I don't think that is a claim phk has ever made and I am not sure why you are making it for him.
This particular PRS10 is GPS referenced _and_ drives one of his GPS referenced NTP servers.
He also has (or had) an array of 10 Motorola Oncore UT+ or M12+T GPS receivers sitting on a row 20cm apart, mounted on a shed roof.
UTC(USNO) is provided by the USNO Reference System #2 (Master Clock #2), which is a Datum Inc. hydrogen maser http://tycho.usno.navy.mil/maser.html
The frequency stability "sigma" of MC #2 has been < 2 x 10-15 during the last year.
NIST-F1, the nation's primary time and frequency standard, is a cesium fountain atomic clock developed at the NIST laboratories. The uncertainty of NIST-F1 is continually improving. In 2000 the uncertainty was about 1 x 10-15, but as of January 2013, the uncertainty has been reduced to about 3 x 10-16
So, no, not "more precise" than the clocks you list, but how many of us have a Rubidium standard in our home?
(And when compared to the large number of clocks in the world, yes, I think that the PRS10 is "one of the most precise".)
https://queue.acm.org/detail.cfm?id=2716278 (Ctrl-F 'precise')
https://queue.acm.org/detail.cfm?id=2349257
Pull quote:
"That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution. (Sic transit gloria mundi, etc.)"
I lean more toward PHK given FOSS model has never produced a high assurance system while proprietary and core team models have done many:
https://www.schneier.com/blog/archives/2014/04/reverse_heart...
Recently I've been redefining the situation to try to find a model that balances the benefits of open-source against the ability to pay a competent team to ensure it's a cathedral. Start of that is here:
https://www.schneier.com/blog/archives/2014/05/friday_squid_...
> A couple of stories by Charles Babcock and (my coincidentally old friend) Steven J. Vaughan-Nichols have mentioned the existence of an ‘NTPsec’ project being funded by the Core Infrastructure Initiative as an alternative and perhaps eventual replacement for the reference implementation of Network Time Protocol maintained by Harlan Stenn and the Network Time Foundation.
I confirm that NTPsec does exist, and that I am deeply involved in it.
https://www.coreinfrastructure.org/faq
> The Core Infrastructure Initiative is a multi-million dollar project to fund and support critical elements of the global information infrastructure. It is organized by The Linux Foundation and supported by Amazon Web Services, Adobe, Bloomberg, Cisco, Dell, Facebook, Fujitsu, Google, Hitachi, HP, Huawei, IBM, Intel, Microsoft, NetApp, NEC, Qualcomm, RackSpace, salesforce.com, and VMware.
I'm looking at the list of tests done in current ntpd.
* Checking whether compiler accepts -g * Checking whether compiler supports C89 * Checking if stdlib.h exists * Check if compiler supports -o * Hunts for just about every command line tool, sed, awk, ln, grep * Is size_t a type?
There are dozens of checks that could be replaced with "Checking for OS = Windows".
There are specific code paths for Digital Unix 4.0, a fix specific to AIX 4.3 with the comment "hopefully adding ... fixing this without breaking any other platform", Ultrix, winnt3.5?,
How many NTP developers routinely test new code against all these platforms?
However it's done, more big name programs need to move on from this.
There's some work done on ntp security [1], I hope we'll see this implemented soon.
[1] https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp
Throw in tech like Code Pointer Integrity or Softbound on client side for extra measure. Or reimplement it in an inherently safer language.