Red Hat Slips off a Curve

By Timothy R. Butler | Posted at 6:55 PM

In the third part of our Penguin Shootout series, Timothy R. Butler considers the latest distribution from the best-known name in the sector - Red Hat. With its much hyped and attacked BlueCurve interface and various other improvements, will 8 be the Shadowman's ticket to victory in our challenge? Read on to find out.



When I first heard about what was called “Nullization” at the time, I was less than enthusiastic, needless to say. A better word for my reaction might have been disgust. Red Hat seemed to be at it again — finding new ways to promote GNOME at the expense of KDE. Yet, many people praised the move, and my stance softened somewhat since the distribution was released back in October.



In fact, I was actually rather excited as I popped in the first disc of Red Hat 8. With fans claiming it presented a “just works” desktop, a term I only usually hear from staunch Macintosh supporters, I was looking forward to seeing how far Red Hat had come in the last year.



The boot up sequence for the installer went smoothly enough, and while I skipped it to save time, it even offered a nice little tool to verify your CD's to insure they weren't corrupted. Once the main part of the Anaconda installer started, things looked pretty familiar. While the interface was now GTK2 based, meaning slick anti-aliased fonts, the overall layout of the setup system is much the same as it has been for some time.



Red Hat's installer is rather similar to SuSE's YaST in layout, with the upside of being free software, and there really isn't much to say about it that hasn't already said before. None of its features are particularly notable, but some of its missing functionality is most definitely worth mentioning again for those who might not have caught previous reviews covering Anaconda



The biggest feature that is missing from Red Hat's installer is a method to resize partitions. Virtually all of the major distributions now support the ability to resize Windows and GNU/Linux partitions without losing any data. Unfortunately Red Hat doesn't, which means you will still have to fork out $50 for a partitioning tool if you want an easy to use partition resizer (for its defense, with Windows XP defaulting to NTFS, all GNU/Linux distributions besides Xandros lack the ability to resize partitions on the latest PC's).



With that inconvenience out of the way, the rest of the installation procedure is rather eventless. For the most part, everything is clear and concise, and I particularly liked the way the package selection screen was laid out. The “Details” link to micromanage a particular package group was nicer than other distributions where you are provided with the choice to either select groups or to select individual packages, but you can't easily just jump to one category that requires extra tweaking. Not a big deal, but a nice touch that shows Red Hat is serious about working out details; or so I thought.



After the basic installation finished, the system rebooted, and the GRUB boot manager loaded. Oddly enough, Red Hat mislabeled a Windows XP install as “DOS” — this is something other distributions don't have trouble with (or at least, they get a closer guess) and, while this is a small detail, it is one that may very well puzzle a new user. Another thing that was disappointing right off the bat was the fact that Red Hat failed to provide any kind of “graphical” boot process. Much like all GNU/Linux distributions a few years back, Red Hat still sticks to a standard text-based boot messages that look very peculiar to new users. We would like to see the company at least make the process seem a little friendlier with something like SuSE and Mandrake's “bootsplash” which “frames” the messages with a nice logo and possibly a progress bar or animation.



After booting into the GUI, the setup program came back up to finish some details. Our SoundBlaster Live! was properly configured, although a second, non-supported soundcard we had in our system also appeared to be configured due to an oversight that caused the test sound to play through the supported soundcard and not the one we had selected. Red Hat Network launched all right, but for some reason Red Hat didn't add its “key” to the OpenPGP/GPG key ring to begin with and so an error box popped up requiring attention before RHN would work. While everything worked, something very important was not included in the setup process — the printer. That's a very big oversight, and one that I find very disappointing.



However, other than those issues, things went pretty smoothly up to that point, and at the end of the installation, I had a system that was very nice looking and I thought might just be good enough to let me stick with Red Hat for a few days as my default desktop. The old saying says that looks can be deceiving, and they most certainly were in this case.



After testing the default setup for a little while, I decided it was time to install KDE and see how the “Nullization” process had changed it. But it wouldn't install. The problem wasn't with the packages, but with the CD-ROM drive auto-mounting tool. For whatever reason, when Red Hat 8 starts up, its mounting tool claims it fails, but when you then try to mount a disk in KDE or GNOME, it is, in reality, double mounting it. This makes it impossible to unmount without shutting down the system. Since the drive wouldn't unmount, I couldn't eject the CD-ROM drive to even insert the CD containing KDE (CD 2).



After rebooting KDE did install, but the CD experience, and the fact that I found out afterwards that this is a commonplace problem, was definitely disappointing. So much for the “just works” desktop.



With KDE set up, I logged into it to see what it was like. As others have reported earlier, it looks just like… Gnome. Indeed, many of the applications that KDE includes, such as Konqueror and KMail, were ignored in favor of Mozilla and Evolution. Many people know by now that Konqueror isn't just a small browser unworthy to compete with Mozilla, if it was, Apple surely would not have skipped over Mozilla for it as the engine for the new Safari browser on Mac OS X. I'm certainly not saying that Apple is always right (most long time readers will remember my many Apple criticisms), but I do think it odd that the browser is good enough for Apple but, in Red Hat's opinion, isn't good enough in its native environment.



Okay, but other distributions do that too, so I moved on and started peering deeper into the KDE environment provided by Red Hat. Little of it impressed me. The KDE Control Center had been made messier with some icons — such as the Palm Sync tool one — being placed with the categories rather than under the proper part of the hierarchy of utilities. Worse, Red Hat's preference to default to GTK/Gnome applications continued in the Control Center. In fact, the aforementioned Palm Sync tool wasn't even KDE's venerable KPilot but GnomePilot!



While it is true that this kind of mixing of software isn't very noticeable with the default BlueCurve theme, it becomes very obvious if you decide to change the color scheme of your system. Unlike the much-hailed Geramik theme for GTK, BlueCurve GTK does not attempt to keep a common color scheme with BlueCurve Qt. Thus, you must choose between matching applications and choosing your own color preferences — we can only hope this improves in Red Hat 8.1.



Many have suggested that KDE supporters should just be happy that Red Hat includes the project's desktop. However, it is OfB Labs opinion that perhaps both Red Hat and KDE would benefit by a parting of ways. Right now, Red Hat is faced with supporting a desktop it still has very little interest in, and its adjustments to KDE could potentially do harm to the desktop project as well. It is the opinion of many informed observers that if they had their first experience with KDE on Red Hat, they would be unlikely to try KDE again.



According to former KDE Core Team member Daniel “Mosfet” Duley, “The issue is [that] they also made several changes to the KDE libraries and programs, some of which cause breakage, incompatibilities, or reduce functionality. In some cases changing code wasn't even needed but RH didn't know better because all the people working on their customized fork never coded KDE before.” Duley continues by pointing out that KDE will appear measurably slower than Gnome for the simple reason that its native utilities have been passed over for Gnome ones. Shawn Gordon, the founder and president of software developer theKompany.com, seemed to be of the same opinion as Duley in an interview at The Age, remarking that “[We] know for a fact that Red Hat sufficiently modified Xft, the Qt libraries and KDE to essentially make RedHat 8 an unsupported platform for Qt.”



In addition, a number of other smaller issues crept out as we continued to use our Red Hat installation. For instance, we had an intermittent problem, possibly related to the auto-mounting problem, that caused the CD burner not to appear when attempting to burn a CD. This was a rather annoying issue, although better than some distributions that didn't recognize the drive at all. On a side note, we also found it frustrating that you had to enter the root password to use the CD burning software, something that could have been solved much more elegantly by having a small “setup wizard” that disabled that login prompt if the root user authorized others to burn CD's.



Another small issue is the Red Hat Network. Unlike MandrakeSoft or SuSE's update utilities, RHN keeps a profile of your system to decide what updates you need. Besides the fact that Red Hat ends up knowing a lot about your system (you can opt out of giving various information), this also means that Red Hat doesn't allow you to have multiple systems hooked up to RHN without additional fees. While I can certainly understand why, after all, it takes a lot of space to store all of that information, Red Hat could avoid both the problem and the cause by simply having the RHN utility decide on the client side what needs updates rather than on the server side.



In the end, Red Hat Linux 8.0 provides a worthy attempt to make an attractive desktop environment, but has far too many small issues to make it a reasonable replacement for more established desktop distributions such as Mandrake Linux or SuSE Linux. This, coupled with the arrogant behavior we noted above concerning KDE, causes us to suggest choosing other solutions for your desktop. It is our hope that the upcoming release of Red Hat 8.1 solves some of these issues, especially in the areas of small bugs and KDE compatibility. If the company can accomplish this, it may have a good contender on its hands.




Summary of Red Hat 8.0



Overall:
A B C D F
Installation:
A B C D F
Functionality:
A B C D F
User Interface:
A B C D F
Upgradability:
A B C D F
Total Cost of Ownership:
A B C D F
Deploy:
YES NO MAYBE
UPSIDE: Red Hat's first foray into a serious GNU/Linux desktop distribution in a number of years shows promise but has serious issues that make it a product we cannot recommend at the present time.
($39.95, www.redhat.com).






Timothy R. Butler is Editor-in-Chief of Open for Business. You can reach him at tbutler@uninetsolutions. com.