I noticed this in the github pull requests for homebrew, and thought it looked interesting. We've all written a script that sends a command-line out to N hosts, right? Dancer's Shell looks like a nice way to automate that. It lets you place hosts in groups, and send commands to a group of hosts. The next time I need to work with a cluster, I'm planning to delve into this and see if it helps.
The D600 was very, very old for a laptop: in three years we replaced the motherboard twice, the hard drive twice, and the keyboard once. On the bright side, practically everything about the laptop actually worked under kubuntu dapper and edgy. Even the closed-source Broadcom wifi worked reasonably well, thanks to ndiswrapper (the open-source bcm44xx driver was never reliable for me). Hibernate and suspend-to-RAM both worked pretty well.
The new nc6400 looks very nice: from a distance you could mistake it for a Thinkpad. The screen is a downgrade (1280x800 instead of the D600's 1440x1050), but the laptop is noticeably lighter. The real reason to upgrade, though, was the CPU: it has a 2.0-GHz T7200 - one of Intel's new EM64T-capable "merom" or "Core 2 Duo" chips. EM64T is Intel's take on AMD's "AMD64" extensions: either branding extends the x86 instruction set to allow for 64-bit native mode.
If you've used MarkLogic Server, you know how much we like AMD Opteron CPUs. Yes, they're very fast - but the real reason is the 64-bit support. Now that Intel is shipping more EM64T chips, there's no excuse for 32-bit address spaces, anymore.
Except that... Windows hasn't caught up yet. And honestly, neither has linux. It's easy to run a 64-bit linux server, and only moderately harder to find all the 64-bit Windows drivers for your server hardware. But desktops are harder: Windows x64 might not support your sound card, for example.
Laptops? Only for the brave. The laptop makers seem to know this, and none of them are hyping their 64-bit support. My nc6400 came with Windows XP 32-bit pre-installed.
There's a good argument behind this. The laptop "only" has 2-GB of RAM, so you could argue that it would work fine in 32-bit mode. For MS Office or Firefox, that's absolutely true. But with MarkLogic Server, memory fragmentation turns out to be at least as important as memory size. In a 32-bit environment, it's pretty easy to chop up the 2-GB or 3-GB address space so badly that the software (or even the OS) has to be restarted. I've never seen this happen in 64-bit mode, simply because the address space is so huge.
So I unpacked the nc6400, booted from a recent kubuntu "edgy" CD for amd64, and got to work. I shrank the XP partition to 20-GB, on an 80-GB disk, and installed linux on the rest. Note to the unwary: ntfsresize rightly insists on a clean unmount of your NTFS partition, before it will do any resizing. Apparently XP doesn't cleanly unmount when it restarts: you must shut down XP, instead.
The install went pretty smoothly. The nc6400 has an Intel 3945 wifi card, so I don't need ndiswrapper anymore. I had some trouble with the widescreen resolution (1280x800), but that's to be expected right now.
So what's the bad news? Well, it looks like HP really messed up the bios (F.05) when they added support for the Core 2 Duo CPUs. I noticed this fairly quickly with my new linux install: the CPU temperatures, as reported by /proc/acpi/thermal_zone, were hitting 95-C. The fans seemed to run at three speeds: the medium-speed fan would run until the temp hit 95-C, then a higher-speed fan would take it down to 85-C, and then the temperature would start to climb again. This made the laptop uncomfortably hot, and very loud.
After more investigation, it appeared that the cpufreq module wouldn't load, so the CPU was running both cores at full speed. Naturally, this generates a lot of heat. Reports indicate that the last bios rev (F.03) work fine with cpufreq, but that older bios won't work with my T7200 CPU. So I'm stuck, until and unless HP fixes the problem in a future bios update.
Judging by other reports on the net, HP's round of merom-related BIOS releases removed the ACPI-based CPU frequency scaling tables from every laptop product that supports merom CPUs. The same change doesn't seem to affect Windows XP: apparently XP ships with its own CPU frequency scaling tables, instead of expecting the bios to supply them. Conspiracy theorists might ask if this was done on purpose, but I think it's just a bug. Time (and HP's next BIOS release) will tell: after all, my old D600 didn't hibernate properly with linux until Dell had released about 10 BIOS updates.
As a workaround, I used the BIOS setup screen to disable the CPU's second core. So I still don't have frequency scaling, and my laptop is only using half of its capacity, but at least it isn't overheating. The CPU temperature is fairly stable at 55-C. The battery life probably suffers, though: I'm only seeing about 90-min from the internal battery.