"Father Time" Gets Another Year At NTP From Linux Foundation
dkatana writes: Harlan Stenn, Father Time to some and beleaguered maintainer of the Network Time Protocol (NTP) to others, will stay working for the NTP another year. But there is concern that support will decline as more people believe that NTP works just fine and doesn't need any supervision. NTP is the preeminent time synchronization system for Macs, Windows, and Linux computers and most servers on networks. According to IW, for the last three-and-a-half years, Stenn said he's worked 100-plus hours a week answering emails, accepting patches, rewriting patches to work across multiple operating systems, piecing together new releases, and administering the NTP mailing list. If NTP should get hacked or for some reason stop functioning, hundreds of thousands of systems would feel the consequences. "If that happened, all the critics would say, 'See, you can't trust open source code,'" said Stenn.
Nor can you trust closed-source code.
But while "open source makes all bugs shallow" is demonstrably a fallacy, at least you CAN see the source if you need to. (Good luck understanding it, though - says this pretty good C developer who just about shit when he had to look at OpenSSL/SSH code...)
With all due to respect to Harlan Stenn, and working under the assumption that he will choose to continue to maintain NTP for the good of everyone who uses it, the biggest donation that could possibly be given to the NTP project would be to increase its bus factor. Basically, we need at least another small handful of people -- ideally distributed throughout the world -- who have the same level of knowledge and expertise as Harlan in the area of network time, and can thus take his place if, for any reason whatsoever Harlan can't continue to work on the NTP project.
Getting Harlan to continue working on it is a short-term solution, but the sustainable future is to ensure that we have maintainers who can take his place -- ideally, paid ones.
So what we need is for a company like Red Hat or IBM or Microsoft or Canonical to bankroll a developer who has at least strong fundamentals that would enable them to quickly pick up advanced knowledge of network time, and then spend most of their working hours acquiring more knowledge about it so that it can be maintained going forward. This would probably involve a lot of ML posts with Harlan (or reading his previous ones), as well as any other developers/maintainers working on pieces of the code.
If Harlan is absolutely instrumental to the project as it stands now, the solution is to have a backup or two, who ideally are being paid a living wage to ensure the continuity of knowledge and expertise if Harlan willingly or unwillingly stopped contributing.
Projects with a bus factor of 1 that are widely relied upon need to be identified and highlighted every now and again -- not to make a case to shower the developer in money, but to get other developers to work in the same space and increase the bus factor to at least 3.
I got news for you; if NTP was non-free, it never would have been used outside of the lab where it was created. There would be 1000 competing network time sync strategies, Microsoft would blithely tell the whole world theirs is the best and universally compatible, while not actually being universally compatible with anything other than third-party malware, and it would be damned-near impossible for anyone without a Master's and 20 years of industry experience to succeed at establishing time synchronization across networks of machines supplied by a heterogeneous mix of OS and hardware vendors. You really want to take NTP and throw it in the same playpen where file-sharing and web-markup language standards got mangled? Really?
BSD NTP client - 3K lines of code. Linux NTP client - 192K lines of code. Guess which has fewer bugs.
I'm assuming the 'BSD NTP client' is OpenNTPd. The 'Linux NTP client' is NTPd that we all know and is not linux specific.
Primary differences between the two:
OpenNTPd just cares about getting the local clock close to the remote NTP's supplied time. Nothing more.
NTPd wants to get the local clock as closely as possible to actual time as well as disciplining the local timesource such that 1 second is accurately 1 second, while weeding out faulty or maliciously bad sources of time. It also can act as a server, or as a peer in a server group. It can also directly interact with multiple reference clocks.
In short, you're comparing a simple client that just looks at the time on the wall vs something that's trying to be accurate and can act as the server side of the equation.
It's been able to do 10ms accuracy for around the last year after they added the ability to adjust the kernel tick rate.
Let's be clear here - we are talking about one particular software package - albeit a very popular one - and not the underlying protocol (which itself is subject to errata, some of which are still under discussion).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.