>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Per Hedeland) writes:
Per> In article <[EMAIL PROTECTED]> Harlan Stenn Per> <[EMAIL PROTECTED]> 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. H _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
