self, camphone, eye

Ouij's Board

The immutable system engenders rot

End of an era
self, camphone, eye
[info]ouij
I have seen the end of 32-bit addressing, my friends, and let me tell you, it's not pretty.

My default e-mail client, Evolution, is great, but it keeps my incoming mail in a single mbox file. (for you *nix nerds, by default this is at ~/.evolution/mail/local/).

Over the years, as I've migrated from computer to computer, I have brought my archived e-mails with me in various mbox files. As of last night, that represented a little under six years' of e-mail correspondence. I'd simply folded the mbox files into each other, allowing me to have a single mbox file that I could search--not that I did all that much grepping through my old logs, but I do go poking into my old correspondence every so often.

But there was a problem lurking here. On IA32, the Linux kernel can only handle files smaller than two gigabytes. It simply can't address anything bigger. After years of folding mboxes into each other, my Inbox file finally got so huge that the kernel just couldn't deal with it any more--Evolution spat an error about the file being too large, and there I was.

Now I know what the Paleolithic inhabitants of the cave at Zhoukoudian/Choukoutien felt like, as they were slowly squeezed out by the ashes of their continuously-tended fires.

I spent most of late last night/early this morning installing the AMD64 build of Ubuntu. Just as expected, the 64-bit kernel addressed the huge 2 GB file with no problem, and I set to work moving older files in the mbox to a series of archives (by year).

Sadly, this hasn't yet shrunk the file by nearly enough to make it addressable by my 32-bit Ubuntu install. Evo spits out a "file too large for data type" error--and, sure enough, the software reports an mbox file over two gigabytes big.

Most of the prolbem comes from my ISP: about a year ago, their POP3 server started acting weird; occasionally resetting the "read" status on messages. Since I download local copies of all the data on the remote server, this could be bad news: every time the ISP hiccups, I'm obliged to download the past however many months of messages all at once. I've tried to deal with it as best I can, but I probably have a metric shitload of redundant copies in that mbox file alone. Thanks, guys. I'll need to install a plugin or run a script to get rid of the redundancies.

Or I could just bite the bullet and migrate to a 64-bit kernel. But I'm so dependent on WINE and various non-free codecs that are avalable only on IA32 that migrating to the new architecture would be a real pain in the ass.

Kernel bloopers
self, camphone, eye
[info]ouij
After a bit of googling about, it seems that I'm affected by Ubuntu Bug #111375, which itself seems to be kernel bug #8423. According to kernel.org's bugzilla, this has been fixed, but a new Ubuntu kernel hasn't been compiled yet.

This puts me in a bit of a bind. I could, conceivably, apply the kernel patch myself--but then that would leave me up a creek with the nvidia drivers. Or I could just wait until the patched kernel shows up in the repos, and just live with the fact that I don't get speed-stepping. I'm opting for the latter. That way, I could probably just run a 32-bit kernel and not have to worry about the various workarounds for flash and java.

So, while I'm waiting--c'mon Ubuntu team!--here's some entertainment:


unforeseen glitches
self, camphone, eye
[info]ouij
While sputnik runs well enough on a 32-bit 'generic' kernel, I am tempted to try an AMD64 kernel to see if I can get CPUfreq to work properly. It's not that big a deal for me, since I haven't put anything on this host anyway.

Home