03.14.07
Posted in Assorted Tinkering at 9:37 pm by Brooks
I just found out today, when I turned my laptop on, that Microsoft’s “Windows Update” updates for Windows 2000 do not include a fix to make it compatible with the new version of Daylight Saving Time. (And, yes, apparently “Saving” is correct and “Savings” incorrect. I didn’t know that before.) Apparently since it’s not a security issue, they feel no need to actually do anything much about it.
There are, however, solutions. First, there’s the semi-official Microsoft solution, which involves some really hairy poking around in the system registry. (And, by “really hairy”, I mean that it looks signficantly more so than poking around in the system registry usually is.)
There’s also a handy little freeware utility that does those changes for you automatically, created by the fellow who runs IntelliAdmin.com. His blog post describing it is here, and the actual download is here. I tried it out, and as far as I can tell it worked perfectly (aside from not actually closing the window when done). He suggests setting your clock ahead to November to watch the time flip over to see if it worked, but it’s easier just to go into the “Time” control panel that you get from right-clicking on the clock and selecting “Adjust Date/Time”, and looking at the “Time Zone” panel to make sure it says “Pacific Daylight Time” (or whatever) rather than “Pacific Standard Time” for the time zone.
For those of you still running Windows 98, he also wrote a fix for that, even though there isn’t an official Microsoft solution at all. The blog post about that one is here, and the download is here.
It’s an interesting observation on advertising, too. It probably took him a day or so to code up this program and test it, and he’s now got a first-page Google hit for people looking for a solution to one of the bigger problems of the month — and people like me are passing around links to his blog, too. You just can’t buy advertising that good.
(The rest of his blog looks fairly interesting, too, if you’re doing Windows administration. This little trick for automatically putting the current date in a filename is particularly neat, for instance.)
Permalink
03.07.07
Posted in Assorted Tinkering at 1:11 am by Brooks
For a lot of the GCC and GNU Fortran development work that I’m doing, it’s much more convenient to work on a GNU/Linux box — the compilation process is set up in a way that is rather slow on Windows (even under Cygwin), and so testing changes is much quicker under Linux. On the other hand, my main computer runs Windows, and I don’t want to be running two computers all the time, much less be rebooting all the time. Thus, I’m running a GNU/Linux installation — Debian stable, to be precise — in a VMWare virtual machine. I can access the files on it via Samba and Windows file sharing almost as easily as files directly on my disk, and PuTTY is one of the nicest terminal windows I’ve used, and it generally is quite a nice way to do things.
One particularly nice feature is that, since all of the GNU/Linux stuff is operating in a single process on the Windows side, it’s easy to set the whole thing to a priority of BelowNormal, and thus even when I’ve got a compilation running and taking up as much CPU as it can hog, it doesn’t slow down anything else I’m doing at all. And it turns out that there’s enough slack in the system that this doesn’t give it any noticable lag in the terminals, even.
The one problem with that is that it completely confuses the software clock on the operating system in the virtual machine, though. When I’ve been using the CPU heavily on the Windows side of things, I’ve seen the GNU/Linux time lose 10 minutes out of 15! VMWare does a nice job of keeping the hardware clock up-to-date, but Debian is set up so that everything depends on the software clock, which only gets synchronized to the hardware clock on bootup. It’s not a critical problem, really, but it’s somewhat annoying to have to remember that a file date of three days ago (or whatever) means “a minute ago”.
The right solution to this is not ntpdate or some other NTP solution. The Windows clock is already synchronized over the network, and the VMWare virtual hardware clock is synchronized to that (I presume), and so there’s no need for adding extra traffic to the network. (Especially since it’s dialup, and disconnected from the internet and any NTP servers half the time.) Nor is the solution something like adjtimex, which tweaks the speed of the software clock; the time skew is a function of Windows-side computer load, and thus quite random, and a static speed tweak is not much of an improvement.
Instead, a better solution is hwclock --hctosys, which synchronizes the software clock to the hardware clock. Because the skew is quite large and needs correction quite often (and because cron is using the skewed software clock for timing, and thus loses time), I added the following to my root crontab:
* * * * * /sbin/hwclock --hctosys
So far, it seems to be working beautifully.
Permalink