Techie

So my MacBook was just sitting on a desk, idle. It was showing a screen saver or something. I woke it up and was greeted with a spinning beachball of death. This seemed to be an unusually persistent hang, so I killed the power and rebooted. I get a flashing system folder, no OS found. I reboot from a Leopard DVD and run disk utility. My HD does not even appear on the SATA bus. Around this time I notice a very quiet repeated clicking coming from the HD and I get a bad feeling about the dreaded "click of death". I power off and reboot from an external drive, but still no sign of the internal one. It seems the drive is dead.
Now is the time to contemplate my backups. I have some recent enough Time Machine backups on an external drive, so I restore one of those onto the other external. That all works, but when I reboot into it and try to log in, I get an odd error about not being able to log in due to a FileVault problem, which I was indeed using. A bit of googling reveals the sad truth: Time Machine and FileVault do not play nicely together. Or more to the point, Time Machine just ignores everything protected by 'FailVault', that is to say if backs up everything except the bits that you actually want backed up. It turns out that it will back stuff up, but only if you log out. Hm. Logging out is for people that want to live without the instant-on we've come to love from Apple, and don't mind waiting 5 minutes to for their 10 apps to launch on login, i.e. those that don't have laptops.
So I extract the internal HD and ship it off to a data recovery company. After a day or so I get the bad news:

We regret to inform you that we have tried our very best to recover data from the faulty Hard Disk Drive you sent to us, unfortunately we were unable to recover any data.

Please accept our apologies for not bringing our services to your satisfaction, despite the fact that from a technical point of view, the damaged inflicted on HDD is beyond repair and it is absolutely impossible to recover any data as the HDD had suffered from severe internal mechanical failure accompanied by media damage, therefore the extreme nature of the damage made it impossible to recover any data.

Despite the usage of different components to get the HDD to spin, the internals were too damaged to read any data from the HDD. The effect of the media damage is immediate on the magnetic information stored on the drive, jeopardising the stored data files and the logical structures.

You can view the scratched area of the hard drive platter in the attached picture, it is the thick dark ring you see running around the inner part of the platter.

I've attached that very picture and you can see there is some fairly obvious mechanical damage to the drive - a great (for want of a better word) example of a head crash. The chances of a 50Gb encrypted volume file surviving that intact are pretty slim, as they say.
I'm pretty surprised that a modern, state-of-the-art hard drive can suffer spontaneous catastrophic damage like this without having experienced any physical shock. For those that want to know (so you know what to avoid), the drive was a 160Gb Seagate Momentus 5400.3, a bit under 2 years old. It's still under guarantee, but a fat lot of use that is now.
I need to reconsider my backup and encryption options...

I took a look at eBay's new page design, which they are currently previewing. Verdict: needs lots more work. Continue reading "eBay's new page design"

If you've just built and installed the new version 0.94 of ClamAV (because it reminded you that your current version was out of date), and you're using the experimental features, it exposes a rather dumb bug that results in these messages in your freshclam log:

@4000000048be74fd0687f57c Software version from DNS: 0.94
@4000000048be74fd0688245c WARNING: Your ClamAV installation is OUTDATED!
@4000000048be74fd06883014 WARNING: Local version: 0.94-exp Recommended version: 0.94

Apparently ClamAV's version comparison is not terribly clever, and the 'new feature' of marking experimental versions with '-exp' has tripped it up. I'm sure there are multiple workarounds, but I changed this in shared/misc.c:

#ifdef CL_EXPERIMENTAL
/*#define EXP_VER "-exp"*/
#define EXP_VER
#else
#define EXP_VER
#endif

as the EXP_VER string is what gets appended to the version number (apparently only for display purposes, but it does the trick). I then rebuilt it and now my log says:

@4000000048be848926da098c Software version from DNS: 0.94

Yay - no error!

I just grabbed the new update to the Safari 4 preview, and I have to say it's very zippy indeed. I ran SunSpider benchmarks on it and FireFox 3.0.1 on my Mac Pro. Safari 4 is on average 75% faster, but has many results that are in the 200 - 500% range.

This is only measuring javascript performance of course, but that, plus whatever other changes are in S4, translates to incredible speed in daily use. I use the SafariStand extension to remember my open tabs, and I can reopen about 40 tabs in 8 windows in about 3 seconds, including all their content! FF 3 was a huge improvement over 2, but Safari 4 is a different league. This is only a preview, so it will probably get faster still by release.

The integration of the JS debugger is very elegant (Drosera has been rolled in), but I'm still looking forward to the appearance of FireBug for Safari, which someone is doing as a Google SoC project (S4 adds some FireBug hooks too).

All the new CSS funkiness from recent webkit nightlies is there too, and I suspect many an iPhone and widget developer is drooling over them...

There's this enormous apache mod_rewrite bug that I ran into back in 2005, and to my dismay, it's still there. Long-standing bugs are usually small edge cases that don't affect many people, but this one is a monster that I suspects pretty much everyone that's using mod_rewrite, and they've just been lucky in avoiding it. The basic issue is this: if you match params that require URL encoding to be safe, mod_rewrite will not rewrite the back-reference (that's $1 below) correctly. So take this very simple redirect:

RewriteRule ^(.*)$ index.php?show=$1 [R]

so you hit http://www.example.com/a%2Fb and mod_rewrite neatly rewrites it as http://www.example.com/index.php?show=a/b! Notice that it has urldecoded the matched parameter in the replacement string.

Apache 2.2 introduced a new B flag to deal with this, but that apparently suffers the same problem! There are two workarounds I've used that are both horrible: double-encode the source string (if you are in control of both start and end points of the URLs) to survive the spurious urldecode, or base-64 encode (javascript flavour) it and do the decoding yourself. I did warn you they were horrible.

I'll bet that there are a zillion mod_rewrites out there that suffer from this fundamental problem and haven't even noticed. If a few people voted for this to be fixed, it would probably go away...

Recently I've had a problem with subversion commits returning a '200 OK' result, accompanied by a peculiar MERGE error (when I'm not doing a merge), but weirdly, the commit had actually made it into the repo. I'd googled for this a while ago with no success, but I had another try today and found this post. Thinking about it, I'd had this problem since updating to the very-very-long-awaited trac 0.11 release. So I tracked down the latest release of the trac-post-commit-hook script and installed that, and amazingly enough, it just works. Thank you UberGeek!

I updated my previous post on Sunspider benchmarks to include Safari 3.1, FireFox 3b4 and IE 8b1.

I somehow missed Microsoft's announcement that (in a complete U-turn from previous announcements) IE8 will support web standards mode by default, and thus any broken sites will have to enable IE7 mode by a meta tag. So finally, IE will cease to be the albatross around the neck of the internet, and developers the world over will at last be able to write standards-compliant sites that work in all major browsers.

I had real trouble believing that MS had convinced so many prominent web standards advocates (here and here) that the previous option was in some way a good thing, when it essentially meant that MS expected 99% of the web to change in order to support the 1% (almost entirely intranets and thus of no public interest) that are so badly written that they couldn't survive a browser update.

I'm very happy to see this change of heart, which was a really unexpected thing to see from MS. They don't normally give a stuff about such things, so they fully deserve the adulation that their announcement is getting in the comments. It also vindicates the slagging I gave the authors of those articles promoting the evil meta tag!

So, Thank you Microsoft! I look forward to not having to do anything special for IE - you probably just doubled the world's web development productivity rate! Who knows - one day IE might be as good as Firefox or Safari...