I've been working off and on for a month getting my new laptop set up. It's an
Asus Z92T that is equipped with a Turion64 X2 TL-64 (2.2GHz dual core), 2GB DDR2/667 RAM, a 160GB IDE hard drive, and a Intel Pro Wireless 2915. It's an odd laptop, since it isn't an old model, but it comes with IDE and Cardbus instead of SATA and ExpressCard. Still, it's reasonably Linux-friendly, and with the evil proprietary NVIDIA drivers installed, it plays Quake 4 at 1280x800 at a completely respectable frame rate.
The laptop runs Fedora 7 fine, except it occasionally seems to lock up. After messing with it a bit, I think I figured out that the network flakes out, and X (possibly as a result of the network going away, but probably not) stops responding. Alt-SysRq-K gets me back to a console though. Now that I've figured all that out, maybe I'll be able to debug what's happening. Then again, I seem to have a ton of updates to install, so maybe everything will just work after that...
On a related note, I was running my linkdups script (functionally the same as the hardlink program that comes with Fedora, but I wrote my script a long time ago, so it's what I use), and I noticed it was chewing through files a little slower than I thought it should on the new laptop. After some debugging, I noticed the script was running /bin/pwd a lot. Obviously that didn't come from my code, so I traced it down to File::Spec::Unix::_cwd(), which seems to get called for every file opened by IO::File (and by extension FileHandle, which is what I was actually using). File::Spec::Unix::_cwd() looks like this:
sub _cwd {
require Cwd;
Cwd::cwd();
}
Cwd::cwd() then runs /bin/pwd for some reason I really don't understand. In any case, changing that to Cwd::getcwd() made a
huge improvement in the speed of my linkdups script. The original code would md5sum around 600 files per second. With _cwd() redefined, it was checking almost 3000 files/sec.
I reported this as a bug
upstream and
with Fedora.
While working with an image of a customer's hard drive, I finally figured out how to handle partitions in a disk image:
losetup /dev/loop0 file
kpartx -a /dev/loop0
After that, the partitions will show up as /dev/mapper/loop0p
n. When you are done:
kpartx -d /dev/loop0
losetup -d /dev/loop0
Just make sure the device-mapper-multipath package is installed if you want to try this out.
On the Fedora front, I updated perl-Pugs-Compiler-Rule, amavisd-new, tuxpaint, tuxpaint-stamps, and perl-Test-Base in rawhide over the weekend.
There was probably more, but that's all I can think of at the moment...
