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
04.29.06
Posted in Assorted Tinkering at 6:58 pm by Brooks
A few days ago, the front left turn signal in my wife’s Geo Metro stopped working, and so one of my chores today was to replace it. I went down to the garage with a pair of screwdrivers and the new bulb, expecting that it would be a pretty simple repair.
A 1997 Geo Metro is one of the cars with an integrated headlight-and-signal-light unit that’s accessed from the front corner of the engine compartment, so I popped the hood and went to work. The lens is held on by a couple of obvious clips, so I removed those. No luck; obviously there was something else that needed to be unfastened on the bottom, too. The next obvious thing to undo were a couple of large screws holding the entire light unit on. I removed those, and still no luck — there was something holding it on the outside bottom corner, which I couldn’t figure out how to get to.
This, I concluded, was the appropriate time to read the documentation, in the form of the owner’s manual. The owners manual explained that one didn’t actually remove the lens or the housing at all, but replaced the bulbs by reaching in behind the light housing, unfastening the socket, and pulling it out. It went on to say — and this is only a mild paraphrase — “Reaching the socket to unfasten it is actually physically impossible unless you are a leprechaun. You will want to take your car to the dealer and let them do it.” Back to plan A.
Some more investigation found the third screw holding the headlight unit in place, hidden in a cavity behind the bumper that I could either look into or reach into at any given time, but not both. So I removed that while contemplating the pipes running across the ceiling, and pulled out the headlight unit, and pulled the socket out of the now-accessible back of it, and discovered a small light bulb entirely unlike the one that the parts store had sold me to replace it.
A small light bulb which, to all appearances, seemed perfectly intact and functional.
Some further testing of the corresponding lights on the other side of the car informed me that what I had just gone to all of that effort to access was not, in fact, the turn signal light at all, but merely the parking light, which was just as functional as it appeared.
So, thus enlightened, I reassembled the headlight unit with only slightly less effort than had been required to disassemble it, and then replaced the actual turn signal bulb, which is in the middle of the front bumper behind a lens that’s held in place by two quite obvious and quite visible screws that are, as it turns out, entirely trivial to remove and replace.
Permalink
03.18.06
Posted in Assorted Tinkering at 1:48 pm by Brooks
(This is a slightly-edited repost of an article I wrote elsewhere, back in 2004.)
Some time ago, I posted a comment on This Is Broken, noting my frustration with motherboard-mounted AC power jacks on laptops, and noting that I had fixed a couple of them by following some online directions. Several people asked me to explain further, and I decided it would be useful to write up a more detailed explanation of how I did it.
First, the keywords: My experience is with a Compaq Presario 1210 laptop (which is very similar to the Compaq 1600 series), and a pair of HP Pavilion xf235 laptops, but this should apply to most similar laptops; the advice is mostly generic.
The problem, in short, is that most laptops have their AC power jacks hard-mounted to the motherboard just like any other soldered-on component, and for many of them this is the only structural connection. Unlike most other components, though, power jacks regularly get yanked on when someone steps on the power cord or such, and the solder joints (or the mounting tabs, which after all are pretty thin metal) start to fatigue, and eventually they crack. At this point, the laptop will only charge if the plug is twiddled “just so” (if at all), and doesn’t work reliably.
The official solution, of course, is to replace the motherboard — which fixes the symptom, but not the overall design problem. On a laptop with a street value of $300, this is also not an economical solution. But it does mean that you don’t really have anything to lose if you toast the motherboard trying to fix it yourself.
So. Enough preamble. Here’s how I fixed the problem.
Read the rest of this entry »
Permalink