Using a Non-Default GUI (in RHEL and kin)
GUI is an acronym for Graphical User Interface. You can choose your GUI in Linux. The working title for this topic was Non-Standard GUI Desktops, but two things are true: First, choice is sometimes good. Second, in many people's minds, "Non-Standard" often implies sub-standard. Nothing can be further from the truth.
In most other popular operating systems, the GUI is both mandatory and relatively fixed. In Microsoft Windows®, you have... well, Windows. You can apply themes and styles, and make a few changes to appearances, but the system is designed to run only in the provided graphical interface. You can't really change out the Windows interface for some third-party layer. Apple Computer is, as far as I know, much the same way, with its new Aqua® desktop GUI over the top of OS X® (I will admit complete ignorance of the Apple way. It's entirely possible that Aqua is just a window manager running on top of the X server running as an application over the Mach-derived core, but I don't know the first thing about it).
Rick Moen comments: Aqua is actually the name of the look and feel effect, resulting from running a proprietary "Display PDF"-oriented 2D display engine named Quartz (as well as 3D extensions dubbed "Quartz Extreme") — a direct descendant of NeXTStep's Display PostScript engine. There are only a limited number of third-party tweaks one can make to the Quartz framework. E.g., a friend has retrofitted one to restore the ability he enjoys in Linux to have virtual desktops. The important thing to remember is that Quartz is not X11 at all, though recent versions have added the ability to seamlessly image X11 applications using an integrated copy of XFree86 for PPC. (I believe this bundle starts something called "quartz-wm" as default display manager, but that you can change it.) I'm not 100% clear on details, because I run my iBook almost entirely in Ubuntu Linux, instead. Note: Because the term "X" is such an overloaded term in the Mac OS X context, the Unix-standard X Windows System is most often referred to as X11 to disambiguate it, despite the extremely small amount of inaccuracy entailed.
When it comes to the GUI, Linux really is different. Display servers provide the interface between the GUI and the hardware (video card). Then there are window managers and desktop environments that are the graphical presentation layer within which applications run. There are many choices for each of these categories. Let me guide you through these options, before we talk about changing the way you work in the GUI.
Display Servers
A display server performs the basic functions of working with the video display hardware, as well as pointing devices (mice, touchscreens, tablets, etc.) and keyboards. It encompasses both the operating system interface and drivers necessary to talk to specific video hardware. Linux display servers are variants of the X Window System (X), which originated at MIT in 1984, long before Linux itself. X has spawned many children, some open source and some proprietary. The most popular X server software for Linux, through the first quarter of 2004, was the XFree86 server (http://www.xfree86.org/). Due to a licensing change and developer conflicts, most Linux distributions (including Fedora Core 2) at this writing are migrating to the X.org server (http://www.x.org/), an open source fork of the XFree86 codebase. I strongly recommend that you stay with the vendor-recommended X server software for your distribution: Migrating to a new display server is not for the faint of heart.
Way back in the late 1990s, it was taken for granted that Linux would not run the latest, fastest, hottest video cards. It would take 6 to 12 months for some dedicated soul to engineer a driver to use the special functions of a new video card, usually without any help whatever from the card manufacturer. As Moore's Law trebled itself in the video card arena, two things changed: First, video chipsets gained capabilities so quickly that open source developers couldn't keep pace. Second, the field of manufacturers narrowed dramatically. Skip forward to today. There are two main players: Nvidia and ATI. Both provide capable video cards, and, more wonderfully, both provide drivers that work with current kernels and display servers to interface Linux to almost all of the hottest new cards. These binary-only drivers have compiled interfaces that allow the drivers to be used with current kernels and X servers. In addition, both manufacturers appear to be working with open source coders to provide stronger support for cards that are no longer top of the line (thus avoiding perceived competitive disadvantage).
Window Managers
A window manager (WM) provides basic services for GUI applications running on a display. An application window is framed and usually has a title bar with widgets for opening, closing, minimizing, and what-not. Windows have focus (to be typed into) and other attributes as well. Finally, a WM provides application menus of some kind, and settings for such things as themes, styles, and backgrounds. Some window managers handle more capabilities, like tabbed windows, or extreme customizability, desktop icons, taskbars, and even scripting capabilities. At the "low end" there is the minimalist window manager, which is said to provide a place to display multiple xterms, and use the mouse to point at the one to type in. Blackbox, Fluxbox, and OpenBox all fit into this end of the pool, as does TWM, the first X window manager. The most extreme light WM I know of is called RatPoison, and is designed to be used keyboard-only. The best advantage of light window managers is that they add very little load to the system for the services that are provided, both in terms of CPU and memory usage. Speed is good.
In the middle bit of the pool are such window managers as IceWM, AfterStep, and WindowMaker. These are variously similar to interfaces provided on other operating systems, and are more customizable, while staying lean and trim with regards to system resources. The single most powerful WM I've experienced is FVWM2. It is agile, mutable, scriptable, and overall a real joy to work in, once I've wrapped my head around it properly. But when I'm not experimenting with other options, I come home to Fluxbox.
Desktop Environments
Also known as an Integrated Desktop Environment (IDE), these are the Galaxy-class workspaces for the Linux GUI. Not nimble, and desirous of as much processor and memory as you can throw at them, IDEs provide capabilities similar to that of the latest Windows and Apple operating environments. There are two players in this space: KDE and Gnome. Okay, Gnome and KDE! I've said it with BOTH first, in order to keep the flamage to a minimum. Asking the "Gnome or KDE?" question on the wrong mailing list is a bit like asking "vi or Emacs?", and nothing at all like asking "cake or ice cream?"
The correct answer to that last question is, of course, "Both!"
KDE was the first of the IDE projects. Based upon a widget toolkit called Qt, KDE 1.0 was the first look at the future of Linux desktops, and many people liked what they saw. But some people saw a dark cloud around that silver lining: At the time, the Qt libraries weren't "free" in the open source (aka Free Speech) sense. This problem lead to the creation and fast ascendence of the GNOME Project, an alternative IDE build upon the underpinnings of the GTK+ toolkit, free and powerful. After some heavy competition on capabilities and equally heavy flame-wars on a number of mailing lists, blogs, and other fronts, an important event took place: TrollTech, the creators of Qt, made Qt available under the OSI-certified QPL license. Had this taken place earlier, GNOME would never have been. But the race between them has benefitted both, by many measures (although some commentators have noted that the sheer energy of duplicated effort might have been better spent elsewhere). Today, with some noisy exceptions, there is considerable work going on to integrate the deep ends of both environments, so that applications created for one can participate more easily in the other.
KDE and GNOME each provide a lot of features. These start at the surface, with lots of eye candy like translucent menus, tooltips, desktop file managers, and deeply extreme customization. Under the surface, both GNOME and KDE offer variations on CORBA/DCOM-type capabilities. This permits inter-application communications and control, application and document embedding, and many other features. If your goal is to come up to speed as quickly as possible in Linux, when you've already had lots of time in front of Windows machines, then either KDE or GNOME will suit you fairly well, with possibly the lowest of learning curves.
Of course, almost every distribution has "chosen sides", and preferentially load one or the other IDE as default. Red Hat, in both the commercial and open versions, offers up GNOME by default, themed with a package called Blue Curve. Optionally, you can install KDE and select it as your default desktop. Blue Curve is the default theme there, too. Debian leans towards GNOME, too, while SUSE, Mandrake, and others choose KDE as primary. In some cases, what makes a distribution special is coded explicitly for a particular environment: This is true of Xandros and its customization of KDE.
Making Changes
Now I'll show you the options you have for selecting GUI desktops other than GNOME, and how to install them in Fedora Core, the example Linux for this book. Briefly, at the end of this section, I'll discuss ways of installing alternate window managers and desktops in a few other distributions. For the purposes of this discussion, I'm using a clean install of Fedora Core 2, Workstation configuration. I'll grant you the desire for a GUI on a server, but not the need to spend time mucking around with alternatives there: Use the RH GNOME and associated tools, there. They are designed for and work best in that environment, and best emulate the experience you'll have if you use the RHEL family of products.
KDE
Installing KDE in Fedora is a snap, in a couple of different ways. First, of course, you can easily select it during the installation. First, after the package configuration step, select the option to customize your package selections. Then continue to the Package Group Selection dialog, as shown in illustration 1.
Illustration 1
Select KDE during Fedora installation
Then, once the installation is complete, KDE is one of the options from the initial login screen (in the list of available sessions). But that's assuming that you're doing a clean install of Fedora Core. What if you've already installed, and now you want to add KDE?
Log in to Fedora as your normal user. Click on the menu icon in the task bar (by default, that distinctive red Fedora), then choose System Settings, then Add/Remove Applications. After filling in the password prompt box to get administrative access, the Add/Remove Applications dialog box appears, looking virtually identical to the Package Group Selection dialog shown above. From there, check the KDE box, and have a look at the Details link to see if you want to add the KDE Administrative Tools. They're omitted from the defaults, but I recommend it. Continue with the installation, and a set of packages for KDE and supporting cast are installed. My only gripe was having to swap twice: First disc 2, then disc 1, then back to disc 2. When all is said and done, log out, then back in again. This time, before putting in the password, look at the options revealed by clicking on the Sessions link at the bottom of the login screen. There's KDE, ready to be selected. Do so, then login. Spend some time spelunking around in the interface and through the menu trees. Observe the differences, and the similarities. Of all the Linux distributions, Red Hat puts the most effort into making KDE and GNOME as nearly alike as possible, on the surface, anyway. Now let's have a look at something from the Atkins-friendly side of the menu....
Xfce4
I can hear it now. "That isn't one of the window managers he wrote about a couple of pages back!" Yup, you're right. But it is the only other one that is included with Fedora Core 2, besides GNOME and KDE. So instead of using the Application manager to try to find and install it, I'll drop down to the command line and use the tools that underpin the network updates and application package management for Fedora Core: yum.
Note: Yum is short for Yellow Dog Updater, Modified, originally
from the Yellow Dog PowerPC Linux distribution. Yum adds a layer of
dependency checking and a number of other handy tools atop the RPM
package layer. Type man yum at any
command prompt to learn more.
[root@gael root]# yum install xffm\* xfwm4\* xfce\* xfdesktop Gathering header information file(s) from server(s) . . . .Dependencies resolved I will do the following: . . . Is this ok [y/N]: Y
Then the appropriate packages are downloaded from the official Fedora mirror sites, checked, and installed without further ado. A note of thanks: I picked up the yum shorthand for this particular installation from an article on FedoraNews.org. Two files need to be created, for the login session manager to pick up XFCE. Use your favorite text editor.
In /etc/X11/dm/Sessions/xfce.desktop:
[Desktop Entry] Encoding=UTF-8 Name=XFCE4 Comment=This session logs you into XFCE4 Exec=startxfce4 Icon= Type=Application
In /etc/X11/gdm/Sessions/XFCE:
#!/bin/bash exec /etc/X11/xdm/Xsession XFCE4
Both files need to have their permissions set properly:
[root@gael /]# chmod 755 /etc/X11/gdm/Sessions/XFCE [root@gael /]# chmod 755 /etc/X11/dm/Sessions/xfce.desktop
This sets read/write/execute for the file owner (root), and read/execute for everyone else. Then you can log out, and select XFCE from the Session manager during login. It loads much more quickly than the two desktop environments, so what's missing? Well, all of the Fedora-specific menus, for one. To use this on a daily basis, I'll need to heavily customize the menu system to match what I need from the installed Red Hat administrative utilities. But there's more good news!
What a difference a lighter WM makes! Just after reboot and login each time, with one terminal window and one SSH session running, here are the respective memory usages for the three choices we have:
| WM vs. Mem | Gnome | KDE | Xfce4 |
| MemTotal | 257072 kB | 257072 kB | 257072 kB |
| MemFree | 2284 kB | 3852 kB | 56480 kB |
| Buffers | 21316 kB | 22404 kB | 20804 kB |
In a 256 MB environment, both KDE and GNOME fill things right up. That's not all of the available data, of course: There wouldn't be room to write any more prose on the topic if I duplicated the memory and CPU data to demonstrate full load characteristics. But clearly, Xfce4 uses less memory for the desktop, leaving more room for running applications before resorting to swap. In a severely memory constrained machine, I'd seriously consider not running X at all (in the /etc/inittab file, this line: "id:5:initdefault:", change the '5' to a '3', and reboot) to conserve resources. When I tested this, I came up with 181 MB of free RAM. Of course, the better choice there is to get a more powerful machine, or at least more RAM. How do you value your time?
IceWM
Why one more window manager? The best reason is that this one is
compiled from external sources, built locally, and installed using
the package manager for ease of future updating. So it's a great
example for lots of concepts. First, go to the home page for IceWM
(http://www.icewm.org/) and
follow the links to pull down the latest stable source file for the
product. At this writing, the stable revision is 1.2.14. Put the
file into /tmp, open a terminal window, type
su - and the right password to become
the root user. Then use these commands:
[root@gael root]# cd /tmp [root@gael tmp]# rpmbuild -ta icewm-1.2.14.tar.gz . . .
Feign an unconcerned demeanor, as warnings and apparent compile errors fly past your eyes. It only matters that the job completes — most of the warnings are put there by the program's author to remind him of places in the code that still need work. This step can take quite a few minutes, depending on processor and available RAM. When it's done, the last few lines of the job tell you where the RPM files were written. That's where we're going next, to install the freshly built RPMS.
[root@gael tmp]# cd /usr/src/redhat/RPMS/i386/ [root@gael i386]# rpm -ivh icewm*
How did I know that was going to work...? Usually there are dependency problems, no? I knew that the packages built to completion, so they must have built in the context of the required other software being present. Otherwise, the compile would have failed with a hopefully useful message telling me what was missing. There was no problem this time. Next, again, we have to create and set permissions for the following files:
In /etc/X11/dm/Sessions/icewm.desktop:
[Desktop Entry] Encoding=UTF-8 Name=IceWM Comment=This session logs you into IceWM Exec=/usr/bin/icewm Icon= Type=Application
In /etc/X11/gdm/Sessions/ICEWM:
#!/bin/bash exec /etc/X11/xdm/Xsession IceWM
The results I see after a reboot and login are a clear improvement even over Xfce4, nearly 20 MB more free. But the same issue with Red Hat menu integration exists.
Pros and Cons
The real upside for many people in installing a non-default GUI on their machine is about control. It has been said many times that Linux is about choice, and people who run and live in Linux like making those choices for themselves. Additionally, a large number of users don't want all of the eye candy and other "features" that seem to stand between them and getting the job done. If the CPU is bouncing a little deforming icon up and down, then it's not hard at work starting your application, is it? That brings up the other big advantage of light window managers: loading speed. If you're in and out of the box all day, the time spent waiting for the GNOME and/or KDE environments to completely initialize can be excruciating. Light == Fast == Good.
The downside is that most distributions, and the Red Hat / Fedora ones in particular, heavily customize the preferred environments to match and support the GUI management tools they've implemented. A perfect example of this lies in the Xfce4 implementation. Yes, it ships on the disks with the rest of Fedora Core 2. But it doesn't have any of the menu customizations that give easy access to the administrative tools. They're not hard to discover independently, by looking into the menus for KDE or GNOME, but you're on your own.
Other distributions like Debian and Gentoo are much more desktop-agnostic than the big commercial distributions. There, it's easy to install so many desktops, window managers, IDEs and things to work with them, that it is hard to get any work done at all if you're not careful. While it is relatively easy and fun to experiment with adding desktops and associated utilities, it's important to remember that you're working with a tool for getting a job done. It doesn't matter what the paint job on the delivery van looks like each day: If four hours of each day is spent repainting part of the van, then it's not out making money or doing anything productive during that time. Balance is important. Experiment for yourself, make a decision, and stick to it... for a while, at least!
Brian Bilbrey is thoroughly Californicated, being the third generation
born in that state of unreality in 1961. The Kennedy assasination rumors
aren't true - there was no stroller on the grassy knoll that fateful day,
and besides, he was in a completely different time zone. Growing up in the
San Francisco Bay Area, Brian became a voracious reader, as well as a Star
Trek and Monty Python fan. He first got into programming with an early TI
calculater. His first "real" computer was an IMSAI 8080, although he was
never able to contact WOPR in Cheyenne Mountain with it. After a checkered career in college (mostly at the lovely yet dangerous
UC Santa Cruz campus), Brian started working in assorted technical fields,
and gravitated naturally into Systems Administration and other
computer-assisted fields such as CAD and CAE. He and his spice, Marcia,
committed a rightward move in 2002, landing in Bowie, Maryland, just
outside the Washington DC beltway. His current employment is at
(nfr)(security) as SysAdmin for a collection of Linux, OpenBSD and Windows
boxen. Brian has been using Linux since early Yggdrasil days. He
currently runs Gentoo Linux on his main home workstation, Xandros Linux on
the laptop, Debian Linux on the home file server, White Box Enterprise
Linux on the backup server, and OpenBSD on the test hardware. That isn't
obsessive, is it?
Brian is a SysAdmin and Author, occasionally human, and a recent convert
to the Church of TAG.
