Brian Gupta wrote:
> Why would you want them to coexist? To me this seems like a clear case > for replacement. > Co-existence would be desirable only during initial testing. At actual delivery time, we would definitely want to replace the existing xntpd package with the newer ntpd one. While the ntpd bits have a superset of the xntpd functionality and are very nearly backwards compatible, I am somewhat concerned about the ability of the ntpd daemon to interact with hardware refclocks on Solaris. This is the testing I am most interested in, since I have no way to test it myself and much of the refclock driver code has been replaced in ntpd. If ntpd works with refclocks on Solaris, then I think we are on track for a direct replacement. Otherwise we may need to deliver both. >> There are replacements for ntpdate, ntpq and ntptrace which have the >> same name, but >> they are pretty much backwards compatible. This is something I will be >> looking at >> more closely to see if there are any caveats. > > I may be reading the man pages incorrectly, but the internal working > of these three commands do not seem to be committed interfaces. Correct. > > Again my feeling is that unless there is a reason to keep both around, > I would definitely have ntpd replace xntpd. (My understanding is that > ntpd supports v4 of the NT, while xntpd only supports up to v3. ntpd > is as far as I can tell the official successor to xntpd. > > (Also it seems the BSDes have replaced xntpd with ntpd.) Its that one word: "unless". We have to assume guilty until proven innocent. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
