[ntp:questions] Re: uk pool problem

Harlan Stenn stenn at ntp.isc.org
Sun Sep 3 02:05:48 UTC 2006

>>> In article <edcja5$129$1 at hedeland.org>, per at hedeland.org (Per Hedeland) writes:

Per> In article <ywn9y7t2hngo.fsf at ntp1.isc.org> Harlan Stenn
Per> <stenn at ntp.isc.org> writes:

Per> So is it deprecated or not? If it is, it would seem very strange to
Per> consider enhancements (which was the point of my tongue-in-cheek
Per> question earlier). Or are you saying that the *only* reason it is
Per> deprecated is that there is no maintainer? That would certainly be
Per> news...

We looked for a maintainer for a Long Time and nobody stepped forward.

Dave looked at the problems with ntpdate and decided he could address the
majority of them with new features to ntpd (things like -q, -g, and iburst,
to name just a few).

Therefore we decided to deprecate ntpdate since the vast majority of the
functionality existed elsewhere (and nobody was stepping up to fix ntpdate).

I created http://ntp.isc.org/Dev/DeprecatingNtpdate over a year ago so we
could have a place to collect discussion on this matter.

I do not remember how long it has been that we have been telling folks that
ntpdate is broken and nobody wants to fix it.

ntpdate was written before there even was an sntp, and I have been telling
folks for a long time that after we had a working sntp we would, to the best
of my knowledge, have complete replacment functionality for ntpdate with the
combination of ntpd and sntp.

It has only been recently that anybody has asked for the -u option.

Per> FWIW, I can see several objectively valid reasons to deprecate ntpdate,
Per> and even a subjective one like "we don't like it" would have to be
Per> considered valid - obviously no one can *demand* that you support some
Per> particular piece of software (at least not without handing over money).


Per> The problem that I see, and that leads to this tiresome re-hashing, is
Per> that the arguments brought forward by those that want to have ntpdate
Per> deprecated are almost uniformly bogus - like the absurd suggestion in
Per> this thread that even though ntpdate allows you to specify multiple
Per> servers, it wouldn't "do anything special" if one of them was 6 years
Per> behind the others. This of course leaves you wondering if the desire to
Per> deprecate ntpdate is actually based on nothing but ignorance.

The last time I checked, both ntpdate and sntp will believe the first answer
they get back.  I bet this is not *strictly* true, but I recall it was
good enough.

Per> Now you are saying that ntpdate has lots of problems - I can't really
Per> deny that, but that's at least in part because I don't know what you're
Per> refering to.

Me either.  The problems with ntpdate have probably not been put into
bugzilla because we have been telling folks for a long time now that we're
gonna deprecate it and they should either:

- use sntp if they want to set the time quickly even if the time is wrong,
  just like ntpdate
- use 'ntpd -g' with a good drift file and with 'iburst' if they want the
  system time set correctly with the clock sync'd and ready to go (in about
  11 seconds' time)

Per> If it's just those listed on bugzilla, I'll have to say
Per> that I couldn't find anything significant in need of a fix there (I can
Per> elaborate if wanted). But maybe you're thinking of other problems?

Yes, and I have way better things to do than to dig thru the archives
looking for problems with ntpdate.

So to summarize:

- I have the belief that ntpdate is broken
- Dave says that ntpdate is not needed anymore (and may, too, believe
  ntpdate is broken)
- nobody has offered to be the maintainer for ntpdate
- we believe we have the needed functionality to do the things ntpdate
  is *supposed* to do, and do it as well or better

and therefore I believe the following are reasonably possibilities:

- somebody can step up and take over the care/feeding of ntpdate
  (this *might* be 'sufficient' to avoid the deprecation, but it is
  certainly 'necessary')
- - I suspect it will be much better to have the "next" ntpdate be a
    shell script that calls either ntpdate or sntp with the needed args
- somebody can tell us (open a bugzilla item, please) about something
  that ntpdate does that the current ntpd/sntp combo does not do.


More information about the questions mailing list