This week, we made a significant change in our computer configuration. Following up on my migration of my laptop from Debian Testing to Fedora 9 early this summer, we have now moved our desktop/VM host from Debian Etch to CentOS 5.2.

Part of this was motivated by being able to get Firefox 3 supported. Also, I have been quite pleased with my Fedora system, and Red Hat-based systems seem to have somewhat better formalized support by software providers. Debian’s recent security fiasco was also a contributing factor mentally (although no one is perfect, and they did handle it as well as anyone can expect). Also, though, Debian is community-driven. This has notable benefits — it is one of the most technically sophisticated distributions around and maintains a high standard of quality control. However, there is some comfort in running a distribution with a single organization behind it, willing to make decisions and cause things to happen.

At present, we have only migrated the host system. We are still running our old server virtual machine (a FreeBSD 6.2 installation). However, more changes are in the works (or at least desired, we’ll see how practical some of them are):

• A new CentOS-based web (and Jabber) server.
• A new FreeBSD 7.0-based mail server
• A new border VM (handling incoming external SSH connections), OS yet to be determined. Probably either CentOS or FreeBSD.
• Centralized authentication, file system, etc. (LDAP, NFS, IPsec to secure the latter)

These changes should be fairly transparent to the outside world — the old VM will remain in service until the new ones are prepared, and then it is but a simple matter of router configuration changes to switch the services over.

I do feel somewhat dirty about the configuration, as our host kernel is tainted by both the VMware module and the proprietary (blech) NVidia drivers. The latter bothers me more than the former; VMware has proven itself to be a reliable technology, but the NVidia drivers do have something of a propensity for instability, and I would really rather not have such in my kernel. Take X down if you want, but in the kernel they can disrupt the whole system. Alas, the open source drivers include with CentOS do not work well with our combination of an onboard GeForce chip and monitor. They do have the benefit, however, of actually working correctly when X doesn’t freeze (which has only happened once so far).

We do have some other minor remaining issues — I’m not sure how we’re going to handle MP3 playback in the KDE desktop, for one. We do have Java and Flash working (thanks to the inclusion of 32-bit Firefox).

Finally, there is one point that is confusing me: our host system is 64-bit, yet it includes 32-bit duplicates of far more packages than I would expect. Also, there seems to be no real installation of some of them. For example, both the 32- and 64-bit kdemultimedia packages are installed. The application binaries are 64-bit; how does this double installation work?

Anywho, so far we are pleased, we’ll see how well this thing works.