CentOS is a free Linux distro built up from the source packages used for making the commercial RedHat Enterprise Linux distro. RedHat doesn’t actually sell the Linux software, but sells the support services to keep it all running for businesses and governments. Like every other Linux distro, RedHat takes the raw code which goes into an operating system, packages it to suit their philosophy, in this case to meet their business plan. Because of the GPL copyright system, and a long history of engaging the Open Source community, RedHat makes available the pre-packaged sources for free. This allows other Linux projects to use those sources to build a distro very much like RedHat’s, but without the copyrighted logos and other branding. However good and stable is the RedHat Enterprise version of Linux, CentOS is the same thing without the expensive support tied to it. Further, the RedHat bug fixes and the 5-year code support is also copied.
Obviously, the whole system tilts in favor of enterprise use, not home desktop use. That doesn’t mean you can’t make it work the way you like. However, the emphasis on stability means you’re not going to have cutting-edge features. You can get some of them, but it’s more work. Those of us with some experience, willingness to do the work, and knowing whom and how to ask for advice, can tame this industrial grade operating system for home use. What follows is an example of things you might have to do.
First was the on-board sound chips on my nVidia MCP61 motherboard. While the kernel supports this, the bundled version of Alsa did a poor job of detecting and configuring it. I got a good sound test during installation, but it never got setup properly. In this case, the solution was picking up the alsa-lib-1.0.16 source RPM set (alsa-libs, alsa-utils) from Fedora 9. Since Fedora is the user community test bed for RedHat’s commercial releases, most of the source RPMs are packaged in a way they can be built on just about any RedHat derived distro. Keeping in mind FC6 is roughly the same as CentOS 5.x, we can still find plenty of SRPMs from later releases which still work. In this case, no tweaks were necessary. I already had most of the development tools for CentOS. Once the SRPMs were installed, it was a simple matter of rpmbuild -bb alsa-lib.spec. It required using --force to install that over the earlier version, but it was necessary to build the alsa-utils package. Once installed, it took only a reboot for me to have sound.
Second, I wanted my Logitech Quickcam Messenger to work. Research showed me my particular model was supported by the SPCA driver project. In this case, most of the work had already been done. It was necessary to add a third-party repository, but the packages were already built. CentOS has a good tutorial on their wiki. They also cover the preferred methods for adding kernel modules, in this case the Dynamic Kernel Module Support (DKMS). It was a simple matter to install the gspca support using yum, the favored commandline package management: yum install dkms dkms-gspca. A quick modprobe gspca and the webcam was working fine.
Most Linux users by now are familiar with chasing down the nVidia driver to enable full graphical acceleration. The CentOS project assumes you are competent to find the drivers and compile them yourself, but still offers a wiki page with effective instructions on getting it done. Not too long ago, nVidia began offering a driver for the 64-bit systems in Linux, and it works fine. You may also have heard of the freetype bytecode rendering issue. The recipe isn’t that hard to find, but in this case it required knowing freetype was recently updated, so I had to draw my SRPM from the updated repository. Then, I had to edit the freetype.spec to make sure it labeled the resulting RPMs with later numbers so the automatic updater didn’t try to replace it with the standard packages without the bytecode hinting, for which we went through all this hassle in the first place.
Other issues are simply a matter of what I like to use. Installing Cream on top of gvim makes it actually useful, and Elinks, using the latest unstable release (0.12pre2) finally provides a display free of ghost text artifacts. Nedit is my favorite for handling large text files in need of significant reformatting. The problem with Nedit is finding a package for 64-bit, then getting past the display issues. I found a decent RPM from the FC6 archives, but it crashed on my 32-bit color display. The authoritative answer is to ensure Nedit is called with a modified command to make it ignore a conflict between the X server and the Motif libraries. While some have recommended turning off the composite extension in the xorg.conf file, this affects too many other applications. The better options are to use either of these two modifications:
nedit -xrm '*visualID: default'
or
XLIB_SKIP_ARGB_VISUALS=1 nedit
This seems to solve the problem. I edited the GNOME menu to reflect the former arguments when starting Nedit, making sure to put the whole thing inside double quotation marks.
It’s been mine, and the experience of several others, that sound and video play on 64-bit, with 64-bit drivers and applications, can be much better than running the same hardware under 32-bit. I notice the sound is cleaner and fuller. Since RPMForge offers Mplayer and ffmpeg for CentOS, it’s a cinch to install them. The Mplayer project has lately been producing modified codecs for 64-bit which seem to work quite well on my system. The only other item I’ve felt a need for was a MIDI player. Since the Linux sound fonts aren’t provided by the hardware manufacture, there are work-arounds. I decided to build TiMidity++ from source, then install the eawpats sound files to support it.
There may be other issues and work-arounds necessary, related to the somewhat older packages on CentOS. Still, I am finding it so far worth the hassle. If you find these directions too hard to follow, or simply need a degree of hand-holding, feel free to ask for clarification.
