On Mon, Mar 28, 2011 at 5:02 PM, Dave Reisner
My hangup (which I should have mentioned in my previous email), is that the popular use case will always be to set the hwclock as we do right now. This changes default behavior without any fallback. The majority of users are inconvenienced and need to pick up on this change. I'll have to read up on pm-utils hooks to see if there's another approach that would also be suitable.
Thanks for the clarification Dave. I think you pinpoint the important issue. If you are right that enabling hwclock will be the common setup, then I agree with you. However, after discussing and thinking about this I think most people should NOT enable hwclock. These are the pros and cons of enabling hwclock: pro: relatively accurate system time even with no internet connection (but why should anyone care about accurate system time if they are not connected to other computers that they need to be in sync with? In that case, the only purpose of the systemtime is to work as a glorified wall clock.) con: if dual-boot, or ntpd is used hwclock will give a much less reliable time than the user might assume (ntpd+hwclock is worse than ntpd alone and worse than hwclock alone), and if localtime (so DST) is used we might get total havoc. In other words, the only people who should enable the hwclock daemon are the ones who need system time to be more accurate than a regular wall clock and who do not have a network connection so cannot use ntpd. I guess that leaves people who want to use their hwclock as a time source for an ntpd server on their local network where the local network is not connected to the internet, and where they do not have a proper time source. I guess that many people are in a situation where they really should not be stepping the hwclock without realising they are, so this change would fix some weird issues for them. For the (hopefully few) who genuinely need to use hwclock we'll have to write an announcement of course. Please let me know if anyone disagrees with my analysis, or if I have overlooked something important. If my assumption that using hwclock should be relatively rare, then I think it would make sense to move it into a daemon for three reasons: 1) simplifies rc.sysinit 2) in general I think anything that does not need to be in rc.sysinit should not be there (simpler the better) 3) given the choice, I'd rather we did not add more variables to rc.conf, as removing them again in the future is a hassle What do you think? Tom