Red Hat 8.0 for KDE Users (and Newbies)

I know what you’re thinking, but don’t worry. This article isn’t ‘Yet Another Red Hat 8.0 Review’. This article is primarily about using Red Hat 8.0 if you happen to be a newbie, but it’s also about using Red Hat 8.0 if you happen to be a KDE user. Why? I happen to be a KDE user, so it makes sense I’d focus more on what I know the most about. Plus, I still remember the frustration of staring with something akin to terror at a blank command line with lots of ideas about what I’d like to do and very little knowledge of how to do it.

Again, KDE is the desktop environment I know the most about and feel most comfortable with: my focusing on it is not an attempt to pour gasoline on the Red Hat & GNOME vs KDE debates. If you are a newbie who prefers the GNOME desktop, Red Hat’s default, then you might still come away from this article having learned something since several of the topics discussed apply to users of both desktops.

At the end of this article, after the good stuff, I offer my opinion on the state of KDE (among other things) in Psyche. Feel free to skip it or not, as you see fit. That being said, let’s get started. This article will show you, among other things, how to add the following to Red Hat 8.0:

• Official
  nVidia Reference Drivers

  
  

• Your
  Windows (or other) fonts for use with OpenOffice.org and KDE

  
  

• XMMS
  MP3 Functionality

  
  

• DVD
  decoding / viewing functionality

  
  

• APT4RPM
  and SynAPTic, the excellent GUI frontend to apt

  
  

• Installing
  Java and Flash plugins for Mozilla

  
  

A general discussion on using KDE with Psyche is included after the topics mentioned above. This section includes tips for undoing certain Red Hat changes to the way KDE behaves and for customizing KDE using tools provided by Red Hat as well as those freely available on the Internet. This section also includes information on theming GDM, the default and wonderfully configurable login manager.

If you have an nVidia graphics card and intend to do any 3D gaming or rendering that benefit from hardware acceleration, you might want to
switch over to the latest official nVidia reference drivers. If you do not explicitly need this 3D functionality there is no need to make the switch. In that case you would probably be better served by the default drivers, since those provided by nVidia are widely reported to be less stable than the admittedly less functional drivers XFree86 ships with. That isn’t to say that the nVidia drivers are unstable, merely that they introduce extra layers of complexity to your system, and with all such things you should only make changes that serve a vital purpose.

nVidia has yet to provide pre-built drivers for Psyche, so we’ll have to build them from source packages. If that sounds intimidating, don’t
worry, it’s actually a fairly trivial matter. First, visit the Linux section of the nVidia driver download area and get the following
two files:

NVIDIA_GLX-1.0-3123.src.rpm (at top of page)
NVIDIA_kernel-1.0-3123.src.rpm (at bottom of page)

Save these files to your machine. Now, open up a terminal (konsole, gnome-terminal) and become root (also called superuser). Change to the directory containing the packages and install them with:

cd /path/to/packages

rpm
-i NVIDIA* (or rpm -ivh NVIDIA* for verbose output
and to print hash marks [#] indicating installation progress)

Since
these are only source packages, we haven’t actually installed any
drivers yet, we’ve just placed the necessary files onto the system to
get us started. To verify that everything is where it should be,
issue the command:

ls
/usr/src/redhat/SPECS/

You
should see two files listed: NVIDIA_GLX.spec and
NVIDIA_kernel.spec These two files simply tell RPM how to
create packages using the source files. These source files were
installed into /usr/src/redhat/SOURCES. Once you’re satisfied
everything went according to plan:

cd
/usr/src/redhat/SPECS

This
is the directory the source packages were installed into. /usr/src
also contains the source code for the Linux kernel itself (assuming
it was selected when you installed Psyche). Once inside the
/usr/src/redhat directory, you might want to take a look
around and see if you can get a feel for what the various directories
are for. If you aren’t comfortable with that, don’t worry, it’s not
necessary. Next, the hard part (if you’ve been exploring, before you
proceed make sure your working directory is /usr/src/redhat/SPECS
– you can use the pwd command to display this for
you):

rpmbuild
-bb NVIDIA* (“rpmbuild” should be self-explanatory, the bb
means “build binary” — man rpmbuild at the console or
#rpmbuild into Konqueror’s address bar or a command box for
more information)

It
should only take a few minutes for the two packages to be built.
You’ll see information scrolling by as your request is carried out.
Don’t worry if you don’t know what any of it means, since not many
people do. Once the build process finishes, you’re almost there. Now,
to install the packages we just built:

cd
/usr/src/redhat/RPMS/i386/ (this is where rpmbuild puts
the packages after they are ready)

rpm
-Uvh NVIDIA*

RPM
will process for a moment, indicating its progress with hash marks
and by displaying a percentage. If all has gone well, you should see
both packages install and then be returned to a command prompt. At
this point, I would suggest you view the README located on nVidia’s
website, as it contains a great deal of information about using,
troubleshooting and customizing the nVidia drivers. For the
impatient, I’ll include here the minimum changes you need to make to
your system to get the drivers working.

At
this point the drivers themselves are installed and ready to go. Now
all we have to do is tell XFree86 we want to use them instead of its
own drivers. Since this requires making changes to the (vitally
important!) XFree86 configuration file, we’ll make a backup copy of
it before going any further. This is extremely important!
Without a clean working copy of this file, you will not be able to
access your desktop.

cp
/etc/X11/XF86Config /etc/X11/XF86Config-original

Now
if you manage to mangle XF86Config you can copy
XF86Config-original to XF86Config and start over with a
known-good configuration. For those of us who aren’t vi or emacs
aficionados, Red Hat has included an excellent screen-based text
editor called pico. Considering the number of capable and
friendly GUI-based editors included with modern Linux distributions,
you might question the need for using or even being aware of
console-based alternatives — until, like now, you’re doing something
that has the potential to render your GUI unavailable. As a general
rule, you should always have a familiar console-based editor
available for just such times. There are few things more frustrating
than needing to make a simple change to a configuration file and
being stumped because you have no idea how to do so from the command
line. That being said, still as root user, issue the command:

pico
-w /etc/X11/XF86Config (always use the -w switch with
configuration files, since it prevents pico from applying any line
wrapping and thus mangling the file)

Locate
the line containing Driver “nv” and replace it with
Driver “nvidia”. To search in pico you press
CTRL+W and enter the search term (shortcuts are displayed at the
bottom of the interface). Now, find the section called Module and
make sure Load “glx” is one of the entries. If not,
add it to the list. Also in the Module section, remove or
comment out any lines that contain Load “dri” and
Load “GLcore”. (You comment out a line by prefacing
it with a hash mark, as in #Load “GLcore”.)

That’s
it! You should be ready to go. Save all your work, and press
CTRL-ALT-BACKSPACE to restart the X server. If all went well, you
should see the nVidia splash screen pop up briefly and then be
presented with the standard GDM login screen. Once your desktop has
loaded, press ALT+F2 to bring up a command box and type in tuxracer
(this assumes TuxRacer is installed, of course) to test your new
drivers. If something has gone wrong along the way, make sure the
nVidia packages are installed correctly and that your changes to
XF86Config are correct (now you’ll see why I pointed out the
need for a backup file and an easy-to-use editor!).

rpm
-qa |grep NVIDIA will query the RPM database for any installed
package with “NVIDIA” in its name (as always, case
matters). If you don’t see both packages listed, something has gone
wrong. Back up to the section that explains building the packages and
try again.

Without
question, font rendering in Psyche is the most beautiful I’ve ever
seen in a Linux distribution. Of course, I’m sure everyone knows
opinions on such things are quite subjective. That said, in my own
subjective opinion, Psyche’s font rendering on my desktop machine is
easily the equal of Windows XP; on my laptop Psyche is the hands-down
winner. This makes it all the more irritating that Red Hat hasn’t
provided a GUI tool for installing new fonts. The excellent KDE Font
Installer is not in evidence for Psyche. I’m assuming this is because
it couldn’t be reconciled with the nonstandard (but visually
superior) way Psyche handles fonts. Thanks to the inclusion of a
little-documented feature, however, this isn’t the glaring omission
it might at first seem, especially if you’re a KDE user (and how’s
that for irony?).

If
you have a Windows installation, installing your Windows fonts is
quite easy. First, create a directory to hold the fonts in your own
home directory (you should be logged in as a regular user, not root,
when you create this directory to ensure that you “own” it).

mkdir
~/.fonts (note the dot, which will make the directory a hidden
one, and the fact that this directory must be named exactly as
shown!)

Now,
all you have to do is copy whatever fonts you want to use into that
folder. For instance, locate your Windows installation’s Fonts folder
and:

cp
*.ttf ~/.fonts/ (the ~ is a shortcut for specifying the
current user’s home directory, such as /home/foo; if you’re
working as root ~ refers to root’s home, which is /root;
note that your prompt ends with $ when you’re a simple
user, and changes to # when you become root)

Note
that it may be necessary to become root to access the Windows
partition the fonts are stored on. In that case, copy the fonts to
your .fonts directory as root (substituting ~ in the
pathname with the actual pathname, since ~ now points to
root’s home, not your own). Once the fonts are copied they’ll
be owned by root, which isn’t what we want. To change this, issue the
command chown -R user:user /home/user/.fonts/* where
user is your
regular login name.

After
restarting the X server, KDE will see the fonts and KDE and its apps
(such as KOffice and Konqueror) will be able to use the fonts without
any further intervention on your part. On a side note, if you haven’t
used the latest incarnation of KOffice, you should definitely check
it out. Version 1.2 is an impressive update to a solid set of tools.
Aside from standard KDE applications, the fonts will also be
accessible as options in KDE Control Center -> Look And Feel ->
Fonts. AbiWord, by default, will not see the new fonts. I have
not investigated a workaround for this (or even whether it affects
all other GTK apps). AbiWord suffers from an apparently obscure bug
on my machine (in several distributions and across several minor
versions of AbiWord) which renders it unusable and for which I
haven’t been able to find a workaround.

If
you don’t have a Windows installation available, you can find the
Microsoft core fonts (used in many web pages) on Sourceforge.
The installation procedure is nontrivial but not difficult and is
outlined clearly on the download page.

Unfortunately,
OpenOffice.org also won’t see the new fonts without a bit of
intervention. Fortunately, OO.o includes an excellent utility that
will have you up and running with the new fonts in no time. If you
haven’t yet fired up the version of OO.o included with Pscyhe, what
are you waiting for? You’ll be in for a pleasant surprise. The
horrible, jagged font rendering of the past is gone. Even the user
interface font is nicely rendered. It seems OpenOffice.org’s last
usability barrier (at least for me) has finally been lifted. It’s not
that I’m extremely picky, just that I use my laptop for most of my
word processing chores, and LCD screens tend to exacerbate even
slight font problems. All that being said, the greatest font
rendering in the world is useless without fonts to render, so let’s
fix that. Open a terminal and become root user. From there, issue the
command:

oopadmin

After
a short wait, the OpenOffice.org administration tool should pop up on
your desktop. At the bottom of the dialog, click on the button
labeled “Fonts …” and point the resulting dialog to the
.fonts directory beneath your home directory. A few more
clicks and you should be able to fire up Writer and have all your new
fonts available. This tool can also be accessed via the system menus
under Office -> OpenOffice.org Printer Setup. Note that the
first method (as root) makes the fonts available to all users.
Starting it as a regular user will only make the fonts available to
that single user.

Any
time Linux package management is discussed, the often overstated
horrors of “dependency hell” are a hotly debated topic. Any
time dependency hell is being debated, the resident Debian users will
invariably refer to Debian’s own apt-get install
simplicity. “Why use an RPM-based distribution when Debian’s
package management is so obviously superior?” the Debian
supporters will ask. “Why use Debian when the software is old
and out of date and you have to be a systems engineer just to install
it?” comes the reply. The discussion generally deteriorates from
there into the all-too-familiar “mine is bigger” vein that,
well, all such discussions tend to deteriorate into.

With
Psyche, your options are a bit more open than in previous versions of
Red Hat Linux, where package management after the install was sorely
lacking. For the first time, Red Hat has included a GUI package
manager (separate from Red Hat Network) capable of adding and
removing packages intelligently from the installation CDs. You can
start it by opening up a command box and running
redhat-config-packages or by pointing to Start Here ->
System Settings -> Packages. For working with the packages on
the official Red Hat CDs, this is a convenient and powerful tool.
Once you step outside the box and start adding third-party packages,
things get a bit more complicated. Thankfully, the folks at FreshRPMS
have given us another option in the war against dependency hell: a
full Red Hat 8.0 apt repository, including some very interesting
custom packages created by FreshRPMS.

Setting
Psyche up to work with apt and the FreshRPMS repository is simplicity
itself. First, visit this
page and
click on the link for Red Hat 8.0. Grab the apt and apt-devel
packages (you don’t need the source [.src.rpm] rpm) and save them to
your machine. Then open a terminal, switch to root user, and install
the packages with:

rpm
-ivh apt*

Once
that’s done:

cat
/etc/apt/sources.list

You
should see the following:

#
Red Hat Linux 8.0

rpm
http://apt.freshrpms.net redhat/8.0/en/i386 os updates freshrpms

rpm-src
http://apt.freshrpms.net redhat/8.0/en/i386 os updates freshrpms

#
Red Hat Linux 7.3

#rpm
http://apt.freshrpms.net redhat/7.3/en/i386 os updates freshrpms

#rpm-src
http://apt.freshrpms.net redhat/7.3/en/i386 os updates freshrpms

If
everything looks good, we’re ready to update our sources (as root
user):

apt-get
update

It
should go without saying that this requires an active Internet
connection. After issuing this command you should see a variety of
messages scrolling past as apt connects to the FreshRPMS servers,
logs in, and takes a look around. Once you’re returned to the command
prompt, assuming there were no errors, the full power of apt is at
your disposal. (Be sure to type man apt or enter #apt
into a command box or Konqueror’s address bar to learn more about
this powerful tool.)

First,
let’s make sure our Psyche installation is correctly set up to use
apt. That is, we’ll ask apt to make sure there are no broken
dependencies or duplications in the RPM database that will keep apt
from working.

apt-get
-f install (think of the -f as fix)

As
you might have guessed, this tells apt to verify your RPM database.
It should do a bit of checking and exit with something similar to:

Reading
Package Lists… Done

Building
Dependency Tree… Done

0
packages upgraded, 0 newly installed, 0 removed and 3 not upgraded.

If
not, inspect the errors carefully and be very sure you know
what you’re doing before allowing apt to make any changes to your
system. Since both of my installs thus far haven’t produced any
errors at this stage, I’m going to assume your installation was
equally flawless.

With
8.0 Red Hat made the decision, based on murky patent issues, to strip
MP3 functionality from the distribution. While many have criticized
this move, I tend to agree with it. Thompson Multimedia, holders of
the patent in question, have not unilaterally stated that Linux
distributors are exempt from the licensing fees associated with
providing MP3 decoding functionality in a non-free product. While
XMMS and other players are free, Red Hat sells them as an
integral part of Red Hat Linux, thus leading to the confusion over
Red Hat’s licensing obligations (including one school of thought
which suggests free MP3 players can’t legally be placed under the
GPL, because they contain patented algorithms that aren’t freely
redistributable for all users all the time) . Without an unequivocal
statement from Thompson, this isn’t a chance Red Hat is willing to
take, for which one would imagine Red Hat stockholders (eager to
avoid lawsuits) and supporters of Ogg Vorbis (eager to overthrow MP3
as a standard) are grateful. Those of us stuck with a huge collection
of unplayable MP3s, on the other hand, are likely less enthusiastic
about the decision, pragmatic though it may be. It seems this would
be a good time to start taking advantage of the (arguably) superior
Ogg format for future audio encoding, since because of this licensing
issue the MP3 format can hardly be considered a truly open standard.
In the meantime, now that we have apt installed and configured we can
restore MP3 functionality to XMMS with a single command:

apt-get
install xmms-mp3

Once
that package is installed, XMMS will be ready to work with your MP3
collection. To find any other XMMS packages that might interest you,
issue the command:

apt-cache
search xmms

Inspect
the list this produces, and if something catches your eye a simple
apt-get install and you’ll be set.

Another
possibly vital bit of functionality not included by default is DVD
playback, since the commonly available tools for watching encrypted
DVDs under Linux are technically illegal (at least for users in the
United States). That is, watching a DVD you own under Linux,
while legal in and of itself, is illegal because the required
decoding libraries and algorithms violate the terms of the United
States’ DMCA. Bearing that in mind, if this isn’t illegal for you (or
if, like me, you are an American who doesn’t mind becoming a federal
criminal in your quest for digital entertainment that does not
involve stealing from anyone) issue the command:

apt-get
install ogle ogle_gui (specifiying multiple package names on a
single apt-get install command line is perfectly
acceptable)

Apt
will offer to install a few additional packages (including the
aforementioned felonious libraries) to resolve Ogle’s dependencies
for you. Say yes, and when you’re returned to the command prompt
you’ll be ready to go. Invoke Ogle with (you guessed it) the ogle
command. The GUI is logically organized, and assuming Red Hat
properly detected your DVD drive you should be watching DVDs in no
time.

Note
that in my case, since this laptop has a CD-RW/DVD combo drive which
uses SCSI emulation for the CD-RW portion, the DVD portion of the
drive isn’t recognized as such by Red Hat (or any other Linux
distribution, so far). This doesn’t mean the DVD drive doesn’t work
(that is, that you can’t mount DVDs) simply that Red Hat didn’t
create a special device file for it in the /dev directory.
That is easily remedied (as root):

ln
-s /dev/cdrom /dev/dvd (this assumes /dev/cdrom is your
CD-RW/DVD-ROM drive, which you can check by typing cat /etc/fstab
and noting the device assignments listed there)

Now
when you configure Ogle, you can simply point it at /dev/dvd for
playback.

What
follows is a rant you may safely ignore: In a recent
column Robert Cringely suggested that the best way to
defeat laws such as the Digital Millennium Copyright Act is to break
them, not singly but en masse. He further suggests that we
should then march in our thousands to the local police station and
turn ourselves in, demanding the jury trial that is our due. That is
by all accounts unlikely to happen. At the same time, something in
the idea resonated with me: I do not like the idea that my government
has enacted a law that turns me into a criminal for watching on my
own computer a movie I paid for unless I do so using an operating
system that same government acknowledges as an illegal monopoly (note
that I’m not bashing Microsoft, just pointing out the absurdity of
criminalizing me if I choose for moral reasons not to support a
criminal corporation). You see, there literally cannot be a legal
open source DVD player under current law, since providing the source
code necessary to decode an ecrypted DVD is illegal. In line with Mr.
Cringely’s idea, I’m confessing to a federal crime: I own several
DVDs and I have watched them using Linux. I own my computer and I
choose to use open source software. In my defense, I claim that using
“illegal” methods to decode DVDs I have purchased is in fact
covered by the “fair use” provisions of copyright law, and that
the DMCA as it stands is unconstitutional on its face. Laws like the
DMCA presume guilt and seek to preemptively prevent “criminal”
acts by certain members of society by restricting the rights of all
citizens. What happened to “innocent until proven guilty”?
Why should I surrender my rights to fair use because certain
of my peers abuse those rights? I choose not to be punished for the
actions of others. Nonetheless, under current law I should, no doubt,
be removed from the sight of decent law-abiding American citizens.
Mind you, I’ve never once watched a DVD (or other digitally stored
movie) I do not own, and I’ve never “ripped” a DVD at all. Still,
I am a criminal. I confess. Take me away, officer …

Now,
back to the topic at hand. At this point, all you GUI lovers are
probably thinking, This apt stuff is cool, I guess, but there
should really be a GUI…

There
is. Type:

apt-get
install synaptic

SynAPTic
is a simple GUI front-end for apt. After you install it with the
command above, it is available in the system menus or by typing
synaptic into a command box. Fire it up and have a look
around. You’ll find the GUI is straightforward and easy to navigate.
A link to SnyAPTic will also be added to Start Here -> System
Settings -> Synaptic.

If
you’ve been following the controversy surrounding the KDE
implementation in 8.0 but haven’t actually experienced it for
yourself, you probably have no real idea of just how modified
Red Hat’s KDE truly is. I’m not a software engineer. As a simple
user, I can state that aside from the beautiful font rendering and
the removal of certain things (such as KDE’s excellent font installer
and MP3 functionality from Noatun) the majority of the changes appear
to be only skin deep. The changes may in fact run much deeper than
that, but if so the effects are not immediately obvious to me. With
only a few minutes effort I was able to undo the changes I didn’t
like and bring my KDE desktop into line with my personal tastes. In
short: Yes, it’s modified, but it’s still KDE. This section will show
you how to get started with making Red Hat’s KDE your own.

You’ll
notice as you explore that there’s a small, seemingly useless blank
space in the KDE system tray. When you launch an application that
requires root privileges and successfully supply the root password,
this space will be filled with a small set of keys. The keys will
continue to display for a short while (I haven’t timed it), during
which time your user privileges remain escalated. This way you can
carry out several related tasks as superuser (such as working in the
Start Here folders) without having to repeatedly supply a
password. Always bear this in mind when making changes that effect
your entire system (or when walking away from your system in an
insecure environment!).

GDM

The
first component of Psyche’s desktop the user is confronted with is of
course the login manager, which in Psyche is GNOME 2’s GDM. The
default look is tasteful and attractive and, no offense to the KDE
developers, vastly superior from a purely aesthetic point of view to
KDE’s own KDM. Add to this that GDM is easily and fully themable and
KDM doesn’t stand a chance. From Kicker, you access the GDM
configuration tool by navigating to System Settings -> Login
Manager. From there you may choose among several options,
including automatically logging in a user at boot time or having a
user logged in automatically after a specified amount of time has
passed. You might also wish to configure XDMCP (for remote logins,
such as from your laptop to desktop) and login security settings as
your needs require. A small selection of themes (including the
infamous Bluecurve default) are included. To obtain more, a great
starting place is the Theme
Depot, which
also contains themes and skins for other popular tools such as
Mozilla and XMMS. You might also want to check out the list of
“Related Sites” on the front page, which provides links to other
theme-oriented destinations.

If
you find a theme that appeals to you, save it (it will most likely be
a gzipped tarball archive) to your machine. From the GDM
configuration applet’s Graphical Greeter tab, select “Install
New Theme” in the lower right-hand corner. In the resulting
dialog, point to the saved file and click OK. Your new theme should
now appear in the list. Select it and you’ll see a small preview.
Repeat this for any other themes you’ve downloaded. Note that in
accordance with the GNOME 2 human interface guide, the configuration
applet has no “Apply” button. The theme selected when you
close the applet is the theme that will be in use the next time GDM
is displayed.

THE
KDE CONTROL CENTER

Psyche’s
KDE Control Center will behave pretty much as you expect, with the
previously mentioned exception of the missing Font Installer. We’ll
start by doing away with some of the more GNOME-like changes to which
Red Hat’s KDE defaults. So, fire up Control Center and we’ll see how
bad the damage really is.

By
default, KDE will be set up to use double-click for activation. This
may be jarring to long-time KDE users (as well as people like me who
are just too lazy to click twice when once will do). The fix is
simple. Point to Peripherals -> Mouse and select “Single
click to open files and folders”. You might want to make other
changes, so have a look around and see what’s available. Clicking the
“Advanced” tab will allow you to change more esoteric
settings, such as pointer acceleration and the number of scroll lines
a single click of the mouse wheel generates.

If
you like having visual confirmation that the program you just started
is actually doing so, you should turn on “Busy Cursor” and
“Taskbar Notification” under Look And Feel -> Launch
Feedback. This is one of those features you don’t really notice
until it’s not there anymore. Being a KDE user, I was subconsciously
accustomed to watching the little hourglass spin in the taskbar and
having the blinking icon following the pointer around. Using Psyche
for the first time, I found myself wondering at times whether the
program was really starting – which sometimes led to
inadvertently starting multiple instances of a program (stop making
fun of me, you’ve done it too at some point!). It’s interesting how
such small psychological cues can have such a large impact on the
user experience.

One
of the first things I did after being dropped into my desktop was to
remove pretty much everything from the default panel and start fresh.
I then right-clicked and reset the size to “Normal”. You
may then add back any buttons and applets you want using the panel’s
right-click context menu. You use the panel a lot, so setting it up
efficiently for your computing style is worth a few minutes of your
time. You might also want to navigate to Look And Feel -> Panel
and on the “Look And Feel” tab select “Enable Icon
Zooming” (you’ll either find this feature is useless or that it
provides useful visual feedback when selecting a panel button). To
return the “KDE 3” image to your Kicker menu, click on the
“Menus” tab and select “Show Side Image”. At this
point, we’ve undone many of Red Hat’s modifications and a
familiar-looking KDE is beginning to emerge. Just a few more changes
to go.

Now
would probably be a good time to surf over to KDE-Look.org
and grab some new background images and icons. I suggest the
Conectiva Crystal Icons Beta 0.6 or higher, which contains Everaldo’s
excellent icon set (finally including a few of the animated variety).
The process for installing a new icon theme is nearly identical to
the process for theming GDM. Just download the archive, then select
it from inside Look And Feel -> Icons and click on “Install
New Theme”. Once you have the Crystal icons (or another set of
your choosing) installed, the default look of Red Hat’s KDE is nearly
gone.

Next,
select Look And Feel -> Window Decoration and choose one of
the alternate decorations Red Hat has provided. I suggest Keramik,
which seems to be fully functional here, even (thankfully) following
the system color scheme instead of overriding it with its own light
blue. Next, select Look And Feel -> Style and experiment
until you find a style you like. Again, I suggest Keramik. That done,
visit Look And Feel -> Colors and select (or create) a new
color scheme. At this point I suggest anything but Keramik.
You might like it — maybe I’m just allergic to light blue. I use a
slightly modified KDE Default.

Now,
stop for a moment and have a look around. The infamous Bluecurve is
no more, but there’s still lots of room for further tweaking. Finish
exploring the Control Center! There are lots of great little options,
such as Web Browsing -> Konqueror Browser -> Appearance. By
default, Konqueror is set up to display a minimum font size of 7.
Change this to 9 or 10 and you’ll be amazed at the difference in the
display of certain websites (such as DistroWatch).
While you’re exploring, check out Enhanced Browsing, where you
can set up search shortcuts for Konqueror. For instance, to query
Google with the search term “linux” you can type gg:linux
into Konqueror’s address bar or any command box (you might want
to add a command box to your panel by right-clicking it and selecting
Add -> Applet -> Application Launcher — it’s more than
the name implies, however, since you can also type in Internet
addresses, search queries, and requests for nicely formatted manual
pages).

KDE
is highly configurable, to say the least. I could go on and on, but I
feel I’ve given you a strong enough start that you can confidently
customize KDE to suit your personal tastes. As you can see, modified
or not, at its heart this is still KDE.

PLUGINS

The
download edition of Psyche doesn’t include the popular browser
plugins such as Java and Flash, but as you’ll see the situation is
relatively easy to rectify. We’ll start by getting Java up and
running in Mozilla and Konqueror. It is possible to install the Java
plugin from your normal user account by starting Mozilla as the root
user, but in both my attempts Mozilla would hang at the end of the
installation. So instead we’ll just break all the rules and log in
to root’s desktop. So, log out of your regular user account and at
the login screen, log in as root. Bear in mind that you never
want to do this in general, since it’s almost certain you’ll wreck
your system eventually!

Now
that you’re logged in, go ahead and fire up Mozilla. Point it to
this
page, where you will see information on “Java By Sun
Microsystems” with a link entitled “Click To Download”. Click
that link and it will offer to install Java for you. After it
finishes downloading, it will be automatically installed. Mozilla
will now load up Java applets nicely with no further work on your
part. To get Konqueror going, we have to do a bit more configuring.
Fire up Konqueror and from the main menu select Settings ->
Configure Konqueror and in the
dialog that pops up choose Konqueror Browser
and select the ‘Java’ tab and under ‘Global Settings’ click
‘Enable Java Globally’. In the lower right-hand corner you’ll see ‘Path to java executable, or ‘java’. In the text box, type
(or navigate to) the following:
/usr/lib/mozilla-1.0.1/plugins/java2/bin/java. Now
restart Konqueror and it should be ready to work with Java applets.
A word of warning: I found Konqueror to be significantly slower than
Mozilla at opening applets.

Next,
we’ll get Flash installed. Click
here to visit the download page. Save the player (it’s a gzipped
tarball) to your machine, then open up a terminal and change to the
directory you saved it to. Now we need to extract the files (you
don’t need to be root yet):

tar
xvzf flash_linux.tar.gz

cd
flash_linux (to switch into the
newly-created directory)

Now we’ll become root and copy
the plugin files to Mozilla’s plugins directory:

cp
libflashplayer.so ShockwaveFlash.class
/usr/lib/mozilla-1.0.1/plugins/

Mozilla should now be ready to
render Flash animations. Visit a Flash-enabled
website to test it. Unfortunately, I was unable to convince
Konqueror to use the Flash plugin. Due to time constraints, I have
not investigated this in detail.

There are also other
plugins available for Linux browsers that I have not tested with
Red Hat 8.0, but that you might find of interest.

You
might want to check out CodeWeavers’
Crossover Plugin,
which uses WINE
to integrate plugins (and other small utilities such as the Trillian
instant messaging software and various document viewers) designed for
Microsoft Windows into Linux. The Plugin will also install
Microsoft’s core fonts for you, which you can then copy into your own
~/.fonts/ directory as described above. A freely downloadable
and fully functional demo is available. Codeweavers uses the
excellent Loki installer and ample documentation is provided. While
fully functional, the demo does contain a small “nag
screen” urging you to purchase the product. The nag screen pops
up randomly during use, but as far as I can recall Crossover Plugin
has the only nag screens that have ever made me laugh out loud. It’s
definitely worth checking out.

As
of this writing, Macromedia
is conducting a beta test
of Flash 6.0. I haven’t personally checked into this, since Flash
functionality isn’t a priority for me, but you may find it worth
investigating.

Don’t
forget to log out of the root user’s desktop and return to your own.

At the beginning of this article, I stated that my purpose in this writing wasn’t political. The real meat of this article is everything above this point, and if that’s all you’re interested in you can safely stop reading now. There are no more tips or how-to’s beyond this point. That being said, I do have an opinion on the controversy surrounding this release. Again, this is my opinion
as a simple user of Red Hat and other Linux distributions. Am I wrong? Maybe so, but consider this: instead of flaming me, try to see where I’m coming from. Figure out why I feel this way, work back to the source of my assumptions, and focus your efforts at that point. If my views are both flawed and shared by many others,
it stands to reason the information on which those views are based is
flawed and that only by providing a logical alternate
foundation for such beliefs can those views be altered, presumably
for the better. I’m not a Red Hat supporter or a KDE supporter in the
sense that being one precludes the other: I refuse to accept that, in
the wake of Psyche, it’s an either-or proposition. Read on and you’ll
see why.

Free
software, its supporters are often eager to point out, is about
choice. This might be the choice to use KDE or GNOME, KWord or
AbiWord, vi or emacs; but that is only the tip of the iceberg. The
choice isn’t merely to use one tool in favor of another, but
to choose to modify that tool to whatever degree you deem
necessary to meet your needs. Red Hat has exercised this freedom with
Psyche in accordance with the licensing schemes of the affected
projects. If this seems particularly onerous to you, respond by
exercising your power of choice: do not bolster Red Hat’s
activities by supporting their product, and present your reasoning
for this decision to others in a reasonable, logical manner. Flaming
others in support of a certain viewpoint often does more damage than
good to the cause, after all. What kind of message do we as a
community send when we shout about freedom of choice from one side of
our collective mouth while condemning Red Hat (or anyone else) out
the other side for exercising that very freedom in a manner we find
personally objectionable?

Mandrake,
SuSE and many other distributions ship more or less unmodified KDE
packages. ELX, Lycoris, Lindows, and Xandros (and probably others)
ship versions of KDE with modifications ranging from slight to
sweeping depending on the distribution. Often, these “enhancements”
are marketed near the top of the list of “unique, must-have”
features. How many awful things have you heard about Lindows? How
many of those awful things centered specifically on the heavily
modified KDE that is the heart of Lindows’ desktop? How many times
have you heard Xandros criticized for continually letting shipping
dates slip? How many times have you heard it criticized for shipping
a modified KDE?

Red
Hat, of all the distribution producers, is seen by and large as “more
corporate” than the others (with the notable exception of the
much maligned Lindows). As such, Red Hat is often seen as somehow
more threatening than the others, leading to the obligatory shouting
by certain members of the community of: “Red Hat wants to be the
Microsoft of Linux! Resist! Resist before it’s too late!”
This is not the closed source world, where Microsoft (or any other
entity, such as Apple in the Macintosh world or Sun in the high-end
server arena) reigns from on high and does whatever it wants, safe in
the knowledge that users will fall in line simply because they have
no other choice. Apple’s legendary stability and ease of use stems
from its tight control of its products, for which it is generally
lauded by its users. Microsoft, by virtue of being orders of
magnitude larger (and subsequently more threatening) than Apple, is
widely condemned for attempting to exercise such control over every
aspect of the end user experience (such as driver signing, and
software and hardware certification). Arguably, this is why in a very
real sense the Macintosh user experience may be superior to the
Windows user experience: Microsoft is placed in the unenviable
position of having to support a nearly limitless array of PC
configurations, often using low-quality hardware, while Apple is not.
There’s a lesson in that, to be sure, but in the end it just doesn’t
matter when the topic at hand is Linux: the rules that govern the
closed source computing world simply do not apply to open source
projects such as Linux. There can be no monopoly in such a
system. The open source software model was carefully crafted from the
ground up specifically to prevent such an eventuality.

Red
Hat literally cannot become the “Microsoft of Linux”.
Microsoft’s source code is jealously guarded and fiercely protected,
Red Hat’s is available to anyone who wants it, not just for viewing
but for modification and reuse by anyone. Red Hat, should it
misbehave badly enough to anger a large enough faction, could be
undone with its own code. It bears repeating: the open source
world is not structured to tolerate a monopoly. Red Hat is a service
company, and as such its primary interest is in supporting its
Linux distribution. Any changes Red Hat makes to its distribution
must be viewed in this light. Suggesting that Red Hat is
intentionally including software in the form of a modified KDE
just to harm an open source project is suggesting that the
(allegedly) fearfully ambitious corporation that is Red Hat is run by
a gaggle of fools eager to commit financial suicide. Red Hat’s
primary interest is in supporting its distribution, remember.
One finds it hard to believe the company would ship an intentionally
broken or inferior product which would only serve the dual purpose of
increasing the burden of providing support and of alienating the
company’s paying customers — not you and I, but Red Hat’s real
customers, corporates with volume buying power and millions to spend
on software support contracts. Whatever the end result and
eventual outcome of these changes, you can rest assured that Red Hat
did not intentionally set out to ship bad software. Working
within the confines of the GPL, Red Hat set out to minimize support
needs and associated costs and to maximize user experience as they
see it for their target user base.

Open
source projects which chafe at Red Hat’s (or any other entity’s)
handling of their code within the legal — if not moral or
ethical, unquantifiable as such things are — confines of the
project’s licensing might wish to take a closer look at their choice
of licensing. Is it acceptable to claim a project is “free”
in all senses of the word — but only so long as:

1)
The exercise of those freedoms are “acceptable” (whatever
the consensus on that might be at any given time among the
project’s many developers) and

2)
so long as the entity making the changes is “friendly” with
the free software project in question (again, how does one quantify
this?)

Let
me point out here that I am not aiming criticism at the KDE
project or its developers, but at the large number of various people
who have condemned Red Hat (often based on wildly incorrect data and
vague rumors) for modifying KDE. The vast majority of these people
aren’t affiliated with KDE at all, except maybe as simple users. To
these people, I say this: A project is either free or it is not. The
GPL does not provide for the arbitrary picking and choosing of
entities “worthy” to participate in those freedoms. That is
just one among many of the checks and balances the elegant simplicity
of the GPL provides to prevent development stagnation (anyone can
fork a project and try to do a better job than those handling the
original) and to stop cold the ability of any one entity to summarily
take over a project (for the very same reason). The GPL, love it or
hate it, is the cornerstone of Linux development. So long as the GPL
remains effective neither Red Hat nor any other distributor will be
capable of — or sanely interested in — “taking over”
Linux in whole or in part. It seems that former Windows users,
accustomed to Microsoft’s (and others’) business tactics, are wary
perhaps to the point of paranoia about such things and immediately
suspect the worst whenever what appears to be purely corporate
interests are involved with their computing experience. The idea of a
takeover and the subsequent destruction of choice that would follow
is a legitimate fear in the closed source world, but attempting to
supply a rationale for it in the open source world depends on a
logical fallacy. Any entity attempting such a thing would be met with
failure and rejection. Odd that the most successful of all Linux
distributors should be accused of charting just such a course for
disaster on a such a regular basis, don’t you think?