On Wednesday 23 August 2006 13:34, Sandy Drobic wrote:
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 who have more stringent needs for time control than just a desktop would probably want something better. Yes. But given a twice a day update, I can't see that there would be much difference. And yes, I used to run ntpd and it worked just fine. Just don't think I need the resource usage required.
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.
If you keep the time updated and your system (clock) is working properly, there shouldn't be any 'big' changes.
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.
See above.
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...
I'll bet I'm more of an oldtimer than you are.... but let's leave that alone. :-)
List replies only please!
A *very* good sigline.......