Bruce Marshall wrote:
On Wednesday 23 August 2006 02:28, John Andersen wrote:
Why would you reply to someone telling the proper method to do this (and, by the way, a method fully supported in YAST) and suggest a hack that no one will remember and which takes more effort to set up anyway?
Well gee.... now we have people nitpicking the solutions others try to provide.
While I agree that the way he worded this could be much less aggressive, I still think ntpd is the proper way for a server to adjust the time.
1) I use this method myself and it works very well.
2) It uses very little system resources as opposed to NTP
3) Based on the traffic on this very list of the problems people have with setting up NTP, it is a much simpler solution.
Much simpler, I agree. So, have you ever wondered why people would still want to use ntp instead of the simple ntpdate?
People - - - be aware that from now on you will need to submit justification for any solutions or help you try to provide. Full HOW-TO's of the absolute *best* way to accomplish any task (even tho there may be 10 best ways to do it) will be required.
Perhaps I should then justify, why I prefer ntpd? The difference between ntpdate and ntpd is that ntpdate will adjust the time in one big step, setting the time backwards or forward to the necessary value. ntpd on the other hand does its best to avoid such a step and strives to adjust the clock speed instead to approach the correct time in small incremental steps, while the system time will not make any strange jumps. On a desktop you don't need to concern yourself with system time. On a server there might be applications that rely on the system time to provide continuous time stamps for critical processes. Is any other novell (netware) engineer here flinching in reflex also, when he hears "synthetical time"? Another example would be transaction based databases where the timestamp is used. You might know today that the time might jump around on your system, but if you leave the company in a year for another job, does you successor who is asked to set up a dbms on the system also know this?
Geesh..... Another reason why I may ditch this list. It has lost its effectiveness.
As with fighting spam, sometimes the most effective means are not the best means for every one and every situation. Please bear with us stupid oldtimers, sometimes we might even have reasons for doing things not the most effective way... Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com