32 Bit Emulation
You may remember my last entry where I cursed the wine interface software and was grumbling about how it didn't compile. Well, I also noticed that my chroot trick that I used to compile software for my laptop, netbook, and VPS wasn't working anymore either (the kernel refused to execute any 32-bit executables).
I couldn't believe that Windows 7 could do this and Linux couldn't, and that accidental thought turned me to looking at my kernel configuration. Wouldn't you know, the kernel has an option that allows 32-bit executables to be used, all that was needed was to check the option. This is not in a very obvious place -- it isn't under "Processor type and features" but rather "Executable file formats / Emulations" as "IA32 Emulation." On second thought, that seems rather obvious, and could probably be more attributed to operator error. In any case, the description of this option says it all:
Include code to run 32-bit programs under a 64-bit kernel. You should likely turn this on, unless you're 100% sure that you don't have any 32-bit programs left.
So be forewarned ... don't forget to configure your kernel accordingly!
That fixed, my complaints in the last entry are
Before I found the magic kernel parameter above, I thought perhaps I would run a 32-bit Gentoo Linux installation in a virtual machine, like I said in my last posting. That was not the right thing to do. I started recompiling the base system as I usually do after loading the "stage 3" tarball. What normally takes no more than an hour or two on a reasonably fast system took more than 5 hours (with all 4 processor cores assigned). I say "more than" with a bit of hesitation since I never let it finish, and it didn't even recompile gcc yet. This was one of the primary motivations for finding a way to run 32-bit executables under the 64-bit kernel, because at the rate this was going I was about to wipe out my 64-bit install and revert back to the old OS build.
Most of my experience with VM software of this kind has been with VMware. The reason I wanted to abandon VMware for VirtualBox is that VMware has become rather bloated, and lately it has been hit or miss when it comes to working with new kernel and/or browser versions (don't even get my started with the newer Firefox incompatibilities). On the other hand, VMware's performance has been overall fairly good and, if you can get it working, it is generally rock solid.
VirtualBox has gotten much better since the last time I used it (which ended up being a total failure), but in my opinion still is a bit behind VMware performance-wise (not entirely, but on some things...) and the way VMs are managed is kind of hokey. With VirtualBox, your VM is basically running through a user-mode graphical application that must remain running in order for your VM to stay alive. This isn't bad if you're just planning to boot Windows for a few minutes to do a specific thing, but if you want to start working on something and run into a task that has to run for a long time (such as a Gentoo build), then you'd like to be able to shut down your GUI and let the VM run in the background. The only way to do this is to anticipate that kind of application in advance and start-up the VM using a command-line tool called VBoxHeadless. The coordination between VM and GUI (console) at that point is clunky, and if you're trying to get to the VM before the boot CD starts-up, you're out of luck. VirtualBox's virtualized disk performance is great (seemed better than VMware), and they clearly have the upper hand on virtualizing network hardware. The CPU performance, though, seemed pitiful, particularly given the number of CPU cores and RAM I gave it.
I am likely going to continue using VirtualBox rather than VMware for those times I need to implement a VM for something. The reason why is the "bloat factor." VMware seems to be catering to the Windows crowd lately, and they seem to be of the Microsoft mentality that software bloat is okay. It wouldn't surprise me if I found something to make VirtualBox run faster if I look hard enough.
I'm not entirely sure whether I am seeing a noticeable improvement in the performance of the system or not. During compiles, my eyeball evaluation of how fast things are going tells me that going to 64-bit was a big win. However, I also replaced my disk drive as well, and the new disk has a better SATA transfer speed than the other "green" drive (yeah, my carbon footprint increased by a small fraction, yeah yeah yeah). So it was hard to tell whether it was my electricity-sucking new hard disk or the unleashing of the CPU's raw pent-up power. For average tasks, the system seems to be running much as it did before. At no time did I see a performance degradation. So I do believe this was a win overall.
My Upgrade Mantra
I have always been of the belief that a major upgrade by completely rebuilding a system is a necessary evil once in a while in order to clean up the results of lazy system management. I found loads of old bits of deprecated configuration files hanging around the system, and a few complete misconfigurations, and one or two things that I said, "What was I thinking?!" When you're forced to merge your configuration from an old OS install to a new one, you can't hide behind the "if I don't see it then it isn't there" mentality. I have a few notes to myself to make a few small changes to make ddclient (the DynDNS IP address updater script) run the way I want. The way I have been doing it is a hack, and while it does work, it is just the wrong way to do it. If I knew then what I know now...
Well, it has been an "interesting" project. So far, so good. While I did have some initial misgivings, I think that these were good lessons, and if anything my knowledge grew from the experience. Keeping up with computer technology is always a bit challenging. Doing it on my own system at home, where I can take a break for a bit, is better sometimes than learning while under deadlines at work.
I feel a bit more like a mad computer scientist again.