Updated: August 21, 2009
Note: I say, this is probably the longest review you'll have ever read! If you want to know what's ahead of you, you may want to skip to Agenda, just for a quick, overwhelming view of what I've got prepared for you today. Now, read on.
CentOS is not your everyday Linux. It's a server distribution, meant to be used in production environment where users do not care about what applications they have installed. It's a distro that you will most likely run without any GUI, reboot once every other year or so, if that, and upgrade only when you really must, since the inclusion of even simplest binaries could be dreadfully risky for your setup.
CentOS is a distribution that deals in long-term stability and security. Branched off as a free version of the vastly popular RedHat Enterprise Linux (RHEL), CentOS is everything the most important server distribution is, except the expensive, official support from the vendor. Speaking of support, CentOS 5.x versions, which are all based on RHEL5.x versions, are going to be supported until 2014, a total of seven years since the major release launch in 2007.
Essentially, CentOS will be your virtualization server, your mail server, your DNS, FTP, LDAP, and who knows what else. It will probably never play any music or videos or interface with Windows machines. No fancy Flash, camera support or anything of that kind. Essentially, that is. Until someone like me decides to break the rules. What I'm going to do today is a sort of a capital sin. I'm going to try to test what is essentially a pure server distribution as an everyday desktop!
CentOS, worthy of desktop?
This is a very difficult, very tricky question. CentOS is not meant to be used as a desktop. Which means that any such effort will be more difficult than with, say Ubuntu or Fedora. There is a number of things you need to take into consideration before you start your adventure, some good, some bad.
First, the drawbacks
CentOS 5 has been released in 2007. This means that the level of usability will be approx. that of your average Linux in 2007. For people who are used to working with latest distributions, the notion of going to back to 2007 will be difficult. If you've now grown past command line and somewhat archaic command-line hacks of getting your services working properly, CentOS is a good way of refreshing them. Or getting frustrated, depends how you look at it.
Then, as a server distro, CentOS does not aim to please Youtube fans or gamers. CentOS will not help you in your MP3 struggle. You won't get any helpful hints how to resolve issues with your graphic card. Therefore, if you do not have the time, skill or will to tame CentOS into submission, you should give it a pass.
Now, the reasons why you should consider CentOS
The chief among them is rock-solid stability and an extremely long patch cycle. The idea of having an utterly stable distro with security patches all the way through 2014 sounds quite alluring. While most distributions have a rather short, annoying six-month cycle and offer patches for just a few short years, CentOS promises peace of mind and proven stability. In general, computer users do not like to upgrade their operating systems, except a small selection of geeks. For them, the knowledge the old, familiar setup they know will not change in many years to come is a great reassurance.
Another reason is the install base. RedHat is probably running on every second server in the world. Then, there's Fedora, the maverick child of the RedHat family and one of the more popular desktop distributions. What works for Fedora will, in most cases, work also for CentOS. You will have a plenty of sources to refer to in trying to solve your problems, often quickly and success. Don't expect Ubuntusque 5-min miracles, but you will not be left moaning for help. Most of the things you need will take just a few click in Google.
Yes or no?
It's a tie, then. The real question is, what really happens when you put CentOS to test? Well, if I were a no-man, I would have given up and never known the answer. Luckily for you, I'm a yes-man, so I've decided to take the challenge of getting CentOS running on my desktop.
We will try everything we normally do - from Wireless via Samba sharing to MP3 playback - and then some. I will test four times: two laptops and two installations, one 32-bit and 64-bit. And check everything in KDE and Gnome. This is probably the most extensive test I have done yet. We will practically do everything, from scratch. So not only is this a review, it's a full blown tutorial to turning your CentOS into a superb desktop. Some of the stuff waiting you just a few mouse scrolls below:
- Live CD checks on two laptops
- Wireless, Bluetooth, Web camera, NTFS support
- Installation of a 32-bit edition
- Installation of a 64-bit edition
- Solving screen resolution issues
- Installing VMware Tools in VMware Server and ESXi
- Configuring startup programs in the session
- Configuring proxy
- Solving update problems via proxy
- Samba sharing
- Adding extra repositories
- Flash Player 10 on 32-bit and 64-bit machines
- MP3, Windows video playback
- Installing cool software -VLC, Skype, others
- Making CentOS pretty
And more ... until your eyes water from sweet exhaustion. It shall definitely be intriguing. So follow me. Spare an hour or two and have a lovely read.
Live CD experience
CentOS also comes as a live CD, since version 5.1. This allows you to test the distribution before installing. Which is what I did. I burned the latest release, 5.3 and let it boot on my T42 with 1.5GB RAM. Later, I also tested the live CD in a virtual machine. The GRUB menu is stylish, with familiar blue-white RedHat/CentOS color scheme.
An alarming message will pop up, but you can safely disregard it. I've not explored in great depth, but I think it's related to Kdump functionality.
After a relatively long boot, you'll reach a simple Gnome desktop, with a slightly archaic look that dates back to RedHat 9. The distro correctly detected my screen resolution.
Wireless & Bluetooth
The first I did was check for Wireless and Bluetooth connectivity.
Bluetooth was working, but the Wireless network adapter was not recognized. I then tried to manually configure a new Wireless connection.
However, when I tried to activate the device, the attempt failed:
Surprisingly, this one worked without any issues. I configured a user account in Ekiga and tested the web camera integration. Worked like a charm. P.S. I've distorted the image on purpose lest you see my kitchen!
Today, I did pay this one special attention, as CentOS was not the typical desktop operating system. CentOS did not disappoint me, though. It mounted the 2GB USB drive formatted with FAT32 without any problems.
I then challenged it with a 250GB WD Passport formatted with NTFS. No luck here:
Suspend & Hibernate
Again, this is not something I often check in my reviews either, as I've rarely encountered problems with resuming the sessions after suspend or hibernate, but I felt it necessary to check it with CentOS. I must say I was quite pleased, as both functions worked flawlessly, even in live session.
Apart from the few tests I did, there was little else to do. CentOS did not ship with any proprietary codecs for video and music, so this aspect of usability had to wait after the installation. One thing I did notice was the fact CentOS 5.3 could not be installed from the live session. To install, I had to separately download the installable version, a 4GB DVD or 6 CDs.
On a side note, I learned about the (lack of) hard drive install function the official CentOS wiki. Unfortunately, the site uses an expired self-signed certificate, which is not the best way to gain security with your readers.
I did something rather unusual here. I installed CentOS twice, once as a 32-bit guest in VMware Server with humble 512MB RAM and standard laptop hardware and once as a 64-bit guest in ESXi with hefty 4GB RAM, plus an infinitely more powerful CPU and much faster disks. We will talk later about the delicate differences between the 32-bit and 64-bit versions, as well as compare impressions on both ends of the performance spectrum.
The installation procedure is typical RedHat, simple and straightforward. It's virtually identical to what I did with Fedora 10, Fedora 11 or Foresight Linux. If you've seen one, you've seen them. The boot menu in the installable version is less appealing than the live CD. Here too, you will get the crash kernel memory allocation error.
You will have the option to check the media for defects and errors before installing. Not a bad idea, in general.
After a short while, the installation will begin.
You'll have to go through a number of fairly routine steps, like language and keyboard. Notice that all languages are detected correctly - and compare to Foresight, which had some issues with certain language fonts.
Partitioning takes some attention, but again, it's identical to what we've seen before with Fedora.
Inside one of the virtual machines, a previous Ubuntu installation with a RAID configuration already existed. CentOS detected it without any problems. However, I decided to make a different layout.
Choosing the default layout created the LVM setup that I do not really like. So I chose custom layout and created root and swap on the first disk and home on the second, previous occupied by Ubuntu 8.10 stripe and mirror RAID devices.
This is the final result:
Next was the bootloader:
After that came the network and time zone settings, followed by the root password and selection of packages. I decided to install both the KDE and Gnome desktops, just for fun.
I confirmed the installation and let it run. I took approx. 25 minutes to complete in the 64-bit virtual machine with 4GB RAM and twice as long in the 32-bit guest with the modest 512MB setting.
After the first reboot, I had to configure a number of security settings, configure the time and users, and perform a few more checks. Regarding the firewall (iptables), I recommend you turn it on, but you should configure it to allow traffic for running services. SELinux can be problematic for less experienced users, so disabling it may be the best option if you're not a geek. Besides, in a home environment, the added value of system hardening is very low.
Next, I had to set the date and time, which seems kind of surplus, since we've already configured the time zone earlier.
An interesting touch is the sound card test. CentOS allows to test your audio devices to make sure they are configured properly. There were no issues here.
You can also install additional software if you want at this stage. This is mainly useful for people installing from CDs rather than the full DVD, as most of the extra programs are contained on high-numbered discs.
The installation was now finally over. Following yet another reboot to get the SELinux rules updated, I was looking at the very stylish, soft login session, with lovely colors and beautiful, round RedHat fonts.
And I was logged into the Gnome desktop. The installation was now complete.
Desktop installed, real fun begins
Now comes the fun part - getting things to work. It was time to see whether CentOS could become your household pet. The installation has completed smoothly and without problems, a rather pretty straightforward deal. The live session could be much improved, with better support for hardware devices. But that's long-term stability for you.
As you know, I've installed CentOS twice, for which you should be immensely grateful. The reason is, this gives you a rather unique opportunity to witness the pros and cons of each platform and the delicate differences in configuring 32-bit and 64-bit desktops. While most things are identical, some do require special handling.
In each of the sections below, I will separately address the success/failure of each step for the 32-bit machine and the 64-bit machine, emphasizing the specific tweaks required for this or that architecture/setup. This will give you a very good indication of what to expect from a desktopized CentOS, whichever edition you choose.
Change screen resolution
First task, rather trivial ... or is it? The default CentOS resolution after the installation was just 800x600, quite impractical for most purposes. I wanted a larger, more comfortable workspace, so the first thing on my agenda was to change the desktop resolution. This is a rather simple configuration and should not take much effort. I would like to emphasize the word should, as it turned out to be a little more difficult than I anticipated.
Anyhow, please do not skip this section. If you're installing CentOS on a real, physical host, you may disregard screen resolution issues as virtualization-specific issues that should never concern you. But this is not true.
If the operating system has no drivers to support your monitor and the graphic card, you may end up with a limited set of available resolutions, just like I did. In this case, you will have to download and install drivers for your graphic card. On modern systems, like Ubuntu or openSUSE 11, you will be able to do this via the repositories, without manually compiling and installing the drivers. On CentOS, you will be forced to do it the old way, from runlevel 3. Therefore, the example below, while it deals with VMware Tools, which are specific to VMware products, applies equally well to installing graphic drivers.
Like I've mentioned above, the 32-bit machine was a guest operating system running inside a virtual machine in VMware Server. The simplest way of changing the desktop resolution is to install the VMware Tools, which offer improved performance, seamless integration between the host and the guess and better drivers for the mouse and monitor. Therefore, our first step was to install the VMware Tools.
The installation of VMware ToolsTo be able to compile, you will require a number of packages, including gcc, make, kernel headers, and the kernel source. This is true for graphic drivers, network drivers, sound drivers, VMware Tools and just about any other program/utility that installs its own drivers. So, our first first task was in fact to get the compilation tools.
Install compilation tools
You can search for these packages using the Pirut Package Manager or you from the command line. I recommend you use the command line interface. The reason is very simple. Searching for packages using the GUI can be confusing. See example below:
As you can see, there are many gcc packages available. Why one to choose? On the other hand, when you work on the command line, you can specify generic package names. The right package will be chosen for you and the dependencies automatically solved. This means that you need not worry about the exact name of the program/tool you're looking for.
This is also true for Ubuntu, as well. Similarly, the simplest way to install the compilation-necessary packages on Ubuntu is via the command line interface. Just execute sudo apt-get install build-essential, and the generic package build-essential will install the necessary bundle of tools required, including gcc, make, kernel sources, and others. I have already demonstrated this in the VMware Tools tutorial. Therefore, we want to install the compilation-necessary packages using the yum utility:
yum install gcc make kernel-devel
On CentOS and RedHat-based systems in general, the kernel sources (kernel-source) package is referred to as kernel-devel.
After installing these packages, you should be able to compile, i.e. install VMware Tools. Well, almost ... You should make sure the running kernel version and the newly installed kernel sources match. I've already shown you this problem when we reviewed Fedora 10. The exact same issue arose then, which is not surprising, considering the family lineage. To test, run the following command:
rpm -q kernel-devel
If the two do not match, you will have to upgrade them:
After the upgrade and a reboot, you should be able to install VMware Tools. Indeed, I did this, without any problems. However, after the reboot, the desktop would not come up. The xorg.conf configuration file was corrupted. CentOS complained about unknown vmware entries. To get my desktop back, I had to restore the old configuration file before the VMware Tools installation. Luckily, an automatic backup is created for you whenever you invoke the VMware Tools installation script. In general, backing up critical system files before making any changes is a healthy practice. I was then able to login into the desktop, but the resolution issue remained.
I found the solution in the Display Settings menu. I fooled CentOS into thinking I had a different kind of monitor, supporting larger resolutions. Please note that this is not a healthy practice if you have CRT monitors, as setting up wrong resolutions and refresh rates may damage them.
This required a restart of the X session for the changes to take effect. I was then able to select a more comfortable setting, but again, I had to restart the X session. However, this was the end of the long and arduous journey. I had successfully changed the resolution.
Let us recap what we did here:
- We decided to install VMware Tools (equivalent to graphics card driver installation).
- Before we could do that, we installed the tools necessary for compilation, namely gcc, make, kernel headers, and kernel sources.
- We made sure our running kernel version and the kernel sources matched; because they did not, we had to upgrade them.
- We installed the VMware Tools and ended up with a corrupt configuration file.
- We restored the backup file and resumed our desktop session, without improving the screen resolution.
- We tricked the operating system into thinking we had a different kind of monitor that supports larger resolutions.
- We restarted the X session (using Ctrl + Alt + Backspace) for the changes to take effect.
Believe it or not, this could happen to you. It used to happen to me, back in 2006 and 2007 when I installed different distributions on my real machines. I did not have to install VMware Tools, but I had to fight quite a bit with graphics cards. CentOS pretty much fits into the 2007 generation when it comes to hardware support, therefore this example is a perfect exercise.
Tidying up ...
The last thing that was left was to add the VMware Tools (/usr/bin/vmware-toolbox) to the desktop session so they would run every time I logged into the desktop. You can do this either in the KDE or Gnome session, the Toolbox will run in both regardless of which one you choose for the setup. In Gnome, you can find the right menu under Preferences > Sessions > Startup Programs.
On the 4GB 64-bit machine, things were a little different. I installed the VMware Tools unattended, rebooted and was instantly able to enjoy normal screen resolutions and all other benefits of the VMware Tools. The major difference between this attempt and the previous one is that ESXi is a more powerful (commercial) product, with a more powerful set of Tools, designed to speed and automate the system administration. VMware Server, being a poor man's propaganda child of the ESX flagship, does not offer such luxury.
An analogy to this problem could be a comparison between CRT and LCD monitors. If you have the former, you'll very much dislike your Linux until you install graphic drivers. On LCD monitors, you won't really care.
Once you solve the issues, you will have a number of screen resolutions available to choose from. In Gnome, you can set them via System > Preferences > Display. In KDE, you have a very handy tool called krandtray.
CentOS turned out to dislike proxies. The problem had many facets. The first was that I could not configure the proxy during the installation, like I could, on say, SUSE. This meant that the first time I logged into the desktop and tried to run the Package Manager, it failed to start, complaining about other instances already running. Pirut makes a very bad, uneducated guess about the Internet connectivity, whether it's down or blocked by misconfigured proxy. Instead of failing after a few unsuccessful attempts, it gets stuck in an infinite loop, waiting for a reply from servers. The only way to stop the broken update is to kill the pirut/update processes, which is quite radical.
I killed Pirut and its friends. Then, I opened Network proxy menu and setup the proxy. For good measure, I also logged out of the session for the changes to take effect. Back into the session, I tried to run the Package Manager again. And once more, when I manually launched Pirut, it started without any errors about previous runs, but the GUI froze for good, forcing me to perform another ungraceful kill.
I then resorted to the command line and tried to run yum. It failed with a rather ugly message: TypeError: iterable argument required. Plus a ton of junk about errors in different Python scripts. Very bad coding practices, I say.
It seemed that CentOS did not really care about proxies. I tried to debug the problem in both KDE and Gnome desktops. Same result. I even rebooted. Nothing. At this stage, I decided I had to use the power of Google to solve the problem. I launched Firefox. Nothing. Even though system proxy was selected under Network settings, it could not connect. After I manually entered the same proxy values, I was able to enjoy the Internet.
A few moments spent searching for the error code provided me with a plenty of solution. Basically, I had to edit the /etc/yum.conf configuration file and add a proxy entry. I found seven different ways of doing it, with or without quotes, with or without the trailing slash after the port number, tweaks for BASH and TCSH, exporting directly on the command line. To cut the long story short, here's the version that actually works:
Pirut was finally working!
I was getting along, slowly, but the experience was far from pleasant. Combine VMware Tools (or graphic drivers) and proxy issues together and you get a nasty picture.
Package Management & Updates
Once I had Internet connectivity, I was able to start using the Package Manager. At the end of the day, I was using yum rather than Pirut. While the GUI was friendly, yum was faster and more accurate. It simply did the job better.
Before I could enjoy music and video I had to connect to a Windows host, or connect from a Windows host to CentOS and copy the test files. I decided to do it the hard way and see how simple it would be to create a share on CentOS.Modern distros are quite friendly in this regard. You right-click on a folder and open its Properties dialog box. Under the Sharing tab, you choose the type of sharing you wish, NFS or Samba. Missing packages are automatically downloaded. And Bob's your uncle! In CentOS, this did not work.
First obstacle was the firewall. No easy way around this. You will have to manage the iptables using the command line. The best solution is to temporarily disable the iptables service until you can afford the time to learn how to use iptables.
I had to manually download the Samba server package and install it, then configure the new Samba user on the command line with smbpasswd command and edit the Samba configuration file (/etc/samba/smb.conf) to create browsable and writable shares. Then, after restarting the Samba service, I was able to get into CentOS from Windows hosts on the LAN. Your first step: grab the Samba server package.
Steps 2-4: Work through Samba configuration using command line and text editors. There was no easy, GUI way to achieve this. Very much 2007, indeed. Still, eventually, it was done. P.S. If you're wondering how you can do this, please check this handy tutorial.
The keywords here are: additional repositories. Once you enable extra repositories, your problems will be solved, MP3, Flash, you name it. Without them, your CentOS will be a nice relic.
Enable extra repositories
Reading a little online, I discovered RPMForge, a great site where all your RedHat problems will be solved. All you need to do is add this repository to your list and start enjoy a multitude of great stuff. There are several ways of enabling the repositories, here's one of them:
rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/ ->
rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/ ->
You can read information under FAQ. Basically, though, that's it. You're good to go.
I went to Youtube and tried to play favorite clip. Youtube gracefully pointed me to Adobe site where I downloaded the Flash Player in .tar.gz format. The installation is pretty simple and straightforward. You may want to check my tutorial on the subject.
After this, Flash was successfully installed and I could enjoy Youtube.
BTW, do not attempt to install Flash Player as root. In fact, CentOS will get confused if you try and will not succeed ...
On the 64-bit installation, this did not work. Installing Flash from Adobe did nothing. Instead of Flash, I had a gray rectangle staring at me. But hey, what did we enable those extra repositories for? Indeed, your first lead should always be RPMForge. Just install flash-plugin.
yum install flash-plugin
And this time, Bob is really your uncle!
Surprisingly, CentOS has no issues with this one.
This one did not work, as expected.
But with RPMForge repository configured, you just need to install two packages: gstreamer-plugins-bad and gstreamer-plugins-ugly.
yum install gstreamer-plugins-bad gstreamer-plugins-ugly
And that solves the problem:
CentOS looks a little spartan, a little out of touch with modern times. So I also decided to pimp it up a little. Here's the summary of a humble 23-minute attempt, both in Gnome and KDE. Here are the two default desktops:
And here they are, after coming out of Dedoimedo beauty saloon.
I did not have to work too hard. Lovely wallpapers were available with the distro and pimping up the default KDE 3.5 theme was quite simple. I merely played a bit with windows decorations and colors.
Gnome a little more spartan when it came to available themes, so I downloaded a few and tried them. Clearlooks with a Cherry seems like the best option. Although you may also want to use Black or Vista (go figure).
And the final desktop:
I also made my Firefox prettier with Mac-OSX and Black Steel themes.
At the end of the day, even though it was still early afternoon, CentOS was made to look as sharp and smart as any other, modern, sleek 2009-era distro. It took a few mouse clicks, but the combination of beautiful, round and clear RedHat fonts and a few interesting touches of color was a real winner.
The default installation is balanced, if spartan. You get the classic set of programs for office work, but not that much more than that. You'll have Firefox, OpenOffice and a few more standard, staple items.
Of course, some of the applications will definitely be less than their most current version. For instance, OpenOffice shipping with CentOS is only at version 2.3.
Still you can find a few interesting items like KAudioCreator, KGhostView, Kopete, Rhythmbox, Ekiga, and others. It's the default Linux basket through and through.
But with the unleashed power of extra repositories, you'll be able to install anything you need. We've already seen VLC above. Then, you may also want to use MPlayer:
Or maybe Skype:
And anything else you may want or desire ...
Comparing a 32-bit machine with 512MB RAM and one with 4GB RAM and 64-bit architecture is hardly fair, but necessary in our case. On the low end machine, CentOS ran well. It did not spring, but it did not crawl either. It was a reasonable performance, expectable from what it had to work with. The boot was a little long, with almost three minutes to reach the desktop.
The 4GB machine was definitely faster - and by all means, if you can afford it, go for it - but the difference was not anywhere near 8 times faster. The major boost was in the responsiveness of the package manager. KDE also liked the bigger RAM better; Gnome was comfortable with either. The boot time was shorter, but still rather long compared to average desktops, at around 2 minutes.
Comparing the two ends of the spectrum, I think CentOS will crunch along nicely with 1GB RAM, dedicating the rest of the computing power to doing the actual work. In home setups, you won't feel a marked difference once you start counting those GBs. This means that you can happily dedicate CentOS even to older hardware, without major worries about performance.
Of course, if you intend to use CentOS for video editing or maybe compilations, then you should go for as many cores and as much RAM as possible. To say nothing of having a 64-bit processor available.
Summary of pain and pleasure
Let's recap what we did so far ... The good and the bad.
Good stuffLive CD, allowed us a peek into the world on free RedHat. Web camera and Bluetooth were working out of the box. The installation was quite easy. Windows video played without any problems. The distro was stable without any crashes.
Bad stuffNo wireless or NTFS support. Samba sharing had to be done the old way. Proxy issues caused big errors with the package manager. Screen resolution was not easy to fix. Compilation was long and tedious, mainly due to kernel versions mismatch. Flash on 32-bit and 64-bit platforms requires different approach.
As you can see, CentOS won't fawn over you. Certain areas are particularly tricky to sort, a well-known ailment of the RedHat family. While compilation is rarely something average home users will do, it's beyond the skill of most average home users. Not surprising, considering that CentOS is a server distro. Proxy issues also smell of bad coding practices and weak algorithms.
That's it. The longest review ever is coming to an end. My Print Preview option in Firefox shows it's 48 pages long should I decide to commit it to paper, one and a half times longer any other review I've written so far. But I think it's worth it.
We have learned a fearful lot of stuff here. First and the most important one, CentOS can be used as a desktop. A solid, stable desktop that will see you through almost a decade of support.
You will be able to have almost everything you need. Following a crash course in CentOS tweaking and taming, we learned the difference in behavior and setup of 32-bit versus 64-bit hosts, we learned how to compile, how to solve problems with kernel versions, overcome screen resolution issues, configure proxy support and get updates, configure Samba sharing, install multimedia codecs, and get our CentOS to look pretty.
There's a price to pay though. Approx. 4 hours to get everything sorted out, after the installation. If you're experienced and have done this before, you may cut it down to approx. 2 hours, which is still less than average Windows installation requires to get into usable form. New users will probably be frustrated - and take much longer to figure things out. Plus, in some areas, CentOS is still lacking, like Wireless and NTFS support.
Which is why I do not recommend CentOS for Linux newbies. CentOS is a serious Linux for serious people. It will reward you with stable, predictable behavior once you get the hang of its quirks. If you don't like upgrading your Linux every 6 months and are more of a conservative type, who may care less for games, the latest gadgets or the coolest desktop effects, CentOS sounds like a very sensible solution for you.
CentOS is like a very big ship. It takes time to get going. Once on the way, you'll love the massive power it emanates. And it's a fun ship too. You'll have your music and other humble sins, if you need.
Bottom line, CentOS is a very interesting project. It's also an excellent opportunity to learn the basics in enslaving operating systems to your needs. For aspiring Linux users, CentOS is a superb proving ground. For veterans and connoisseurs, it's good ole school all the way. That would be all for today. Feel free to send me emails of eternal gratitude for long hours taken to prepare and write this review.