>>> In article <[EMAIL PROTECTED]>, Unruh <[EMAIL PROTECTED]> writes:
Unruh> Harlan Stenn <[EMAIL PROTECTED]> writes: >>>>> In article <[EMAIL PROTECTED]>, Unruh >>>>> <[EMAIL PROTECTED]> writes: Unruh> But with ntpdate, the server is under your control. So this is hardly Unruh> something I would call "broken". Harlan insists that it is broken-- Unruh> mentioned it twice-- but never said how and why it is broken. What he Unruh> calls broken may be a feature other people never use. >> Yawn. >> As a troll attempt, that was pretty lame. And there are enough trolls. Unruh> It was NOT a troll attempt. It was an attempt to learn what you Unruh> consider the flaws in ntpdate are, so that users can make up their Unruh> own mind whether or not to use it. I understand that there is a long Unruh> long long running desire to get rid of it ( which has apparently Unruh> failed), but I do not understand what the flaws are. I do not choose to investigate the archives to find even a portion of the "evidence". For folks who have "been around", I believe it is just accepted that we remember that ntpdate has serious flaws and nobody wants to fix it, especially now that ntpd has most of the needed functionality and sntp has the rest. The only thing left before we "pull the trigger" is to finish sntp and perhaps write a script called ntpdate to drop in for folks who just don't care to make a more conscious choice. At one time, ntpd and ntpdate contained duplicate code. If ntpdate was given a single hostname, it sent the packet, got the response, and set the time. If it was given more than one hostname it sent the request to each host and originally ran the same algorithms as ntpd to set the time from the "best" choice. Over the years, many bugs were found and many improvements were made to the selection algorithms and even the time-setting code in ntpd that were *not* made to ntpdate. It also became clear that there were at least two populations who used ntpdate, and they had conflicting goals. One wanted the time set ASAP, with "less" consideration for the quality of the time. The other wanted the time set *well*, with "less" consideration for the speed with which that was done. Each of these groups wanted to do this before ntpd, because in most cases they wanted to start ntpd after the time was set (because we didn't have enough knobs to offer the variety of policy choices users wanted in ntpd alone). The best solution to this mess was to deprecate ntpdate, once there was a way to provide all of the intended *and assumed* functionality of ntpdate by some other way. The first set was removing the need to set the time with ntpdate before starting ntpd. The solution to this problem is -g, and perhaps calling ntp-wait (which actually implemented a missing feature that had been needed before). The next step was to decide which was more important for local policy, setting the time, once, well (ntpd -q) or setting the time, once, quickly (sntp). If people think the current ntpdate is working well I would bet (and I believe I'd win the bet) that they are not getting the behavior they think they are getting, and they are oblivious to the (occasional?) problems they are having. >> Believe me or not, your choice. Unruh> I thought were were talking about facts, not beliefs. It has been my experience that any "link" between facts->beliefs is heavily tainted with ... hallucination. But things mostly work out anyway. Mostly. As Samuel Johnson said: Subsequence does not imply consequence. >> I recommend searching the archives - the status of ntpdate is pretty old >> news, and predates the support twiki (as I recall), and the decision to >> deprecate ntpdate may even predate our use of bugzilla. Unruh> Yes, it is old, and has apparently failed to have any effect. ntpdate Unruh> is still there, and thousands still rely on it. There will be a script called "ntpdate" for those folks who want to keep running a program by that name. But I don't see how your point relates to the underlying issue. I think the biggest reason ntpdate has stuck around is we have not forced the issue. When we remove the old code and include a new script, I bet most folks will simply not notice. The ones who *do* notice will be the ones who (think they) care enough to make a choice and override whatever behavior they do not like. >> I'm probably done with this thread. Unruh> Ok, that is of course your choice. I would still like to know what Unruh> the flaws are. I'm not sure I have answered to your satisfaction, but I hope this is at least a sufficient step in the right direction. -- Harlan Stenn <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
