Linux System Administration for Researchers

Chapter 6: Introduction to X

Up until now we've talked about command-line things.

Now we'll take a look at a graphical interface.
There's no way we can thoroughly cover X in an hour,
so what I'm going to say will just skim very lightly
over the top of this enormous subject. I hope I can
at least show you where the seams are, so you an
go back later and pry it apart yourself, to look deeper
inside.

Part 1: What is X?

We're all used to graphical interfaces now. Most

people have never used a computer without one.
But think back to those days of yore (say, 1980)
when computers weren't graphical. Think about just
how weird it is to point at what you want, instead of
just telling the computer what to do. It's like being in
a foreign country where you don't speak the
language. All you can do is point to the visible
choices. If something's available, but not visible, you
can't select it.
Just like visiting a foreign country, a novice computer
user doesn't know the language. The advantage of a
graphical interface is that it lets the novice get work
done right away, without any special training.
Graphical interfaces made it possible for nontechnical people to start using computers in fairly
sophisticated ways.

What is X?:
X is a OS-agnostic, hardware-agnostic, network-transparent, clientserver system that provides a graphical user interface. It is highly
configurable:

X is the most common, and most powerful, graphical

interface used under Linux. X's configurability is
great, but challenging. As we'll see, desktop
environments like KDE and Gnome impose some
order on what might otherwise be a daunting system,
suitable only for computer geeks, and make it usable
by novices.

The History of X:
1981, Xerox PARC develops the Star
computer, with the first modern GUI.
1983, Apple releases the Lisa computer.
1984, X version 1 developed for the MIT
athena project. Development began as a port
of Stanford's W window system for the V
operating system.
1984, Apple releases the first Macintosh.
1987, Current version (11) released. X development overseen by the MIT X
Consortium, a collaboration between MIT and industry (DEC, HP, Sun, etc.)
1992, Volunteers begin working on XFree86, an X server for PC hardware, based
on the MIT X distribution.
1992, Microsoft releases Windows 3.1.
1993, X Development taken over by X Consortium, inc., a non-profit vendorcontrolled corporation. XFree86 continues to work in parallel.
1997, Taken over by The Open Group, another vendor group. Attempted
unsuccessfully to change X licensing. By this time, XFree86 is the most dynamic
part of the X world.
2004, X development taken over by the X.org Foundation, a community project
open to (and governed by) individuals and funded by corporate sponsors.
4

X development was almost dead for a long time during

the 90s. In recent years, since the x.org foundation
took over, development sped up considerably. The
new community model, with bright, enthusiastic
leaders like Keith Packard, brings frequent
improvement and innovation.
Also note that the mouse was actually around for a
long time before the folks at Xerox PARC started
using it. Here's a nifty demo of this new device from
1968:
http://www.youtube.com/watch?v=1MPJZ6M52dI

In the example above, an X client program (xterm, in

this case) is connected to a local X server. The
server sends keyboard and mouse input to the client,
and the client sends display commands to the server.
Note that the client doesn't need to care about what
hardware the computer has. It just talks to the X
server, and it's up to the X server to know how to
draw on the display or get input from the
mouse/keyboard.

X clients don't even have to be running on the same

computer as the X server. Clients can talk to the
server over a network connection. As far as the user
is concerned, things look just the same as if the
client program were running locally.

Advantages of X:
Clients can run anywhere, and display anywhere.
(Network transparency.)
Clients are don't need to care what type of video
hardware your computer has. (The X server takes
care of all that.)
Clients don't even need to be running on the same
type of operating system. (All X clients use the
same protocol, and can work together, no matter
whether they're running under Linux, OS X or
Windows.)
7

Part 2: Running X:

The X server is just a program called X. There are

many ways to start X, but it's usually started by a
display manager.

X Display Managers:
In /etc/inittab there will usually be a line like this:
# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon
This tells init to start running an X display manager. A display
manager is a program that has several purposes:
Start the X server, if it isn't already running.
Connect to the X server as a client, and show a
username/password dialog box on the X display.
Wait for a user to successfully log in, and then start an X
session (a predetermined set of X applications).
Hang around silently until the session ends, and then re-

display the username/password box.

The respawn flag in /etc/inittab tells init to re-start the display
manager if, for whatever reason, it dies.

There are many different display manager, but there

are only three that you're likely to encounter:
xdm. This is the original X display manager, written in
1988 by Keith Packard. Its main configuration file is
/etc/X11/xdm/xdm-config .
Kdm. This is the KDE display manager. Its
configuration file is /usr/share/config/kdm/kdmrc .
Gdm. This is the Gnome display manager. Its
configuration file is /usr/share/gdm/defaults.conf .
These configuration files tell the display managers how
to behave, and which other configuration files to use.

X Sessions:
An X session is just a set of X clients that get started up when you log in. Usually, the
display manager starts these by running a script named Xsession, which lives in /etc/X11
or /etc/X11/xinit. When the script finishes, the session is over and the display manager redisplays the login dialog box.

Display Manager

/etc/X11/xinit/Xsession
#!/bin/sh
# Start some applications:
# Terminal Windows:
/usr/bin/xterm &
/usr/bin/xterm &
/usr/bin/xterm &
# Misc:
/usr/bin/xclock &
/usr/bin/xcalc &
/usr/bin/exmh &

Note that most of these

are started in the
background. If they
weren't, the script would
stop at the first 'xterm'
command and wait there
until that xterm window
had been closed.

But this one isn't started

in the background. The
script will wait until it
finishes.

# Start the Window Manager:

/usr/bin/twm
10

Usually, there's one program in Xsession that acts like

a stopper, keeping the script from exiting until the
session is over. This can be done as above, by
putting this application at the end of the script, but
there are other ways to do it, too.
The Xsession script will typically be much more
complicated than this example. Usually, it will be
generalized so that the display manager can give the
user a choice of desktop environments. The user's
choice is then passed to Xsession as a commandline argument or environment variable.
By choosing a display manager and configuring its
Xsession script, you can have very great control over
how your computer's graphical environment
behaves.

Window Managers:
A window manager is a special X client that has the ability to add decorations to other X
clients, and to control them in various ways. For example, the window manager might let
you move windows around on the display, resize or iconify windows.

Here's what an xterm and

an xclock look like without
a window manager....

...and here's what they look

like when a window
manager is running. Note
the borders, banners and
buttons.

11

There are tons of window managers. The one shown

above is a lightweight window manager called
fluxbox. One of the earliest window managers was
twm, or Tom's Window Manager, written by Tom
LaStrange in 1987. Modern integrated desktop
suites like KDE and Gnome have their own window
managers.
Window managers interact with other X clients through
a set of standards known as the Inter-Client
Communication Conventions Manual, or ICCM.
Most modern window managers are ICCMcompliant, and so are to some degree drop-in
replacements for each other.

What Window Managers Do:

Decorate the windows displayed by other X

clients, by adding banners, borders, buttons, etc.

Allow the user to resize, move, iconify/deiconify

windows.

Provide the user with menus for configuring the

window manager's behavior or performing other
tasks.

12

X Resources:
While it's running, the X server stores a list of configuration
parameters in memory. This list is called the X Resource Database,
and individual parameters are called resources. Client programs
can look at the values of these resources. Here's an excerpt from the
list of resources, showing some that apply to the xterm application:
XTerm*loginShell:
true
XTerm*ttyModes:
erase ^?
xterm*background:
Black
xterm*cursorColor:
red
xterm*font:
fixed
xterm*foreground:
yellow
xterm*fullCursor:
true
xterm*reverseWrap:
true
xterm*scrollBar:
true
xterm*scrollKey:
on
xterm*scrollTtyOutput: off
xterm.SimpleMenu*background:
#efefef
xterm.SimpleMenu*foreground:
#000000
...

X Server

X Resources

X resource values are typically read from the files

13
/etc/X11/Xresources and the user's own ~/.Xresources file (if it exists)
when the user logs in.

Notice that X resources can include wildcards. When

a client asks for the value of a resource, the resource
that's the most exact match will be returned. For
example, if the X server has entries like:
*foreground: white
xterm*foreground: black
then the value black would be returned if a client
asked for the resource xterm.vt100.foreground.

The xrdb Command:

The xrdb command can be used to query or set values in
the X Resource Database.
~/demo> xrdb -query
*Box.background:
#efefef
*Box.foreground:
#000000
*Button.activeBackground:
#efefef
*Button.activeForeground:
#000000
*Button.background:
#efefef
*Button.foreground:
#000000
*Button.highlightBackground:
#efefef
*Button.highlightColor: #000000
...

The -merge switch can be used to ask xrdb to read in a list of

resources from a file and merge them with the existing
resources, already in the database:
~/demo> xrdb -merge ~/.Xresources

The Xsession script typically calls xrdb -merge one or more

times to initialize the database when the user starts a session.

14

If you leave off the -merge you'll wipe out the current
database and replace it with only the contents of
the .Xresources file!

The xdpyinfo Command:

The xdpyinfo command can be used to get information about a
running X server:
~/demo> xdpyinfo
name of display:
:0.0
version number:
11.0
vendor string:
The X.Org Foundation
vendor release number:
70101000
X.Org version: 7.1.1
...
screen #0:
dimensions:
1280x1024 pixels (401x302 millimeters)
resolution:
81x86 dots per inch
depths (7):
24, 1, 4, 8, 15, 16, 32
...
X uses the term display in a couple of different ways (unfortunately):
1. The thing on which I want to draw pictures.
2. A unique number (the display number) which identifies each X server process running on a
given computer.
Each X server process may control multiple physical monitors (screens). So, the name of the
display (in the first sense) is given as:

hostname:displaynumber.screennumber 15

Note that, when specifying display names, the

hostname and screen number are optional. If you're
referring to a display on the local host and there's
only one screen, you can just call it :0.

The xset Command:

The xset command can be used to query or set various switches that control a running X server.
~/demo> xset -q
Keyboard Control:
auto repeat: on
key click percent: 0
LED mask: 00000000
auto repeat delay: 250
repeat rate: 30
auto repeating keys: 00ffffffdffffbbf
fadfffdfffdfe5ef
ffffffffffffffff
ffffffffffffffff
bell percent: 50
bell pitch: 400
bell duration: 100
Pointer Control:
acceleration: 2/1
threshold: 4
Screen Saver:
prefer blanking: yes
allow exposures: yes
timeout: 310
cycle: 600
Colors:
default colormap: 0x20
BlackPixel: 0
WhitePixel: 16777215
Font Path:
unix/:7100,built-ins
Bug Mode: compatibility mode is disabled
DPMS (Energy Star):
Standby: 1200
Suspend: 1800
Off: 2400
DPMS is Disabled
Font cache:
Server does not have the FontCache Extension
File paths:
Config file: /etc/X11/xorg.conf
Modules path: /usr/lib/xorg/modules
Log file:
/var/log/Xorg.0.log

16

The xlsclients Command:

You can use the xlsclients command to list the X clients connected to an X server:
~/demo> xlsclients
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org
demo.mydomain.org

xterm -ls -T Demo1 -e

xterm -ls -T Demo2 -e
xosview
xterm -ls -T Demo3 -e
xterm -ls -T Demo4 -e
xterm -ls
xterm -ls
xterm -ls -T Demo5 -e
xterm -ls -T Demo6 -e
xterm -ls -T Demo7 -e
xterm -ls
xterm -ls -T Terminal
/usr/bin/exmh
kicker
firefox
seamonkey-bin

ssh demo1
ssh demo2
ssh demo3
ssh demo4
ssh demo5
ssh demo6
ssh demo7

17

Part 3: Security

18

This is the first time we've talked about programs that

use the network, so it's time to start thinking about
security. Any network-aware software can open your
computer up to abuse, if improperly used.
In the following, I'll mention a program called ssh,
which allows you to get command-line access to
another computer on the network. Don't worry about
the details of this right now. We'll talk more about it
at a later time. The main point is that ssh creates an
encrypted connection between the two computers,
so that nobody can snoop on your communications.

Security: Remote Clients:

Remote
Computer

The old, bad way...

X Client
(xterm)

X
Protocol
(unencrypted)

X Server

xhost + remotehost
setenv DISPLAY mypc:0

Remote
Computer

X Client
(xterm)

The new, good way...

Ssh Protocol
sshd

ssh

X Server

(encrypted)
Tunnelled X Protocol

19

In the bad old days we used to use X in the way shown

in the top picture. We'd use an xhost command on
the local computer to allow a specific remote
computer access to our X server, and then on the
remote computer we'd set the DISPLAY environment
variable to point to our local computer's X display.
This is insecure for a couple of reasons: (1) the X
protocol connection between the computers is
unencrypted, and (2) the xhost command allows
any process on the remote computer (which may not
be completely trustworthy) to read our local
keystrokes.
The better way to do it is shown in the bottom
illustration. Just let ssh set up an encrypted,
tunnelled X connection between the machines. This
is easy to do, and it Just Works.

Enabling X Tunnelling for Ssh:

With luck, the default settings for your ssh client will already be configured properly,
so that all you need to do is ssh into the remote host, and type xterm (or whatever X
application you want to run). If this doesn't work, take a look at your ssh client's
configuration:
OpenSSH (Linux and OS X):
Look in the file /etc/ssh/ssh_config or ~/.ssh/config and make sure it contains a line like:

ForwardX11 yes
You can also tell ssh explicitly to create an X tunnel by typing ssh -X instead of just ssh.
Putty (MS Windows):

SecureCRT (MS Windows):

20

Here's how to set up ssh so that it creates an

encrypted, tunnelled X connection between the local
and remote computers. Once the defaults are set
properly, you shouldn't need to do anything other
than ssh to the remote computer and start invoking X
applications.
Putty is a free program that you can download from
various web sites (just do a Google search for it).
SecureCRT is a commercial program that we have a
site license for.
OpenSSH is pre-installed on OS X computers and
most Linux computers.

Rules of Thumb for X Security:

1. If you ever come across any documentation that
tells you to set your DISPLAY environment
variable, discard it. This documentation is either
out of date, or written by somebody from whom
you shouldn't be taking advice. You should never
need to set the DISPLAY variable by hand.
2. The same advice applies to any documentation
that tells you to use the xhost command. You
should never need to use xhost.

21

If you don't remember anything else from this talk,

remember these two things.
The xhost warning is particularly important. One of the
most dangerous commands you can type is
xhost +, which allows any host in the world to
connect to your X server and read your keystrokes.
This used to be common practice. (Some X server
software for Windows even came pre-configured to
do this automatically.) A few years ago, this caused
a major security breach at our university. Please
don't do that!

Security: Remote Sessions:

The old, bad way...

Remote
Computer
xdm

XDMCP Protocol
(unencrypted)

X Client
X Client

X Server
X Protocol
(unencrypted)

X Client

The new, good way...

Virtual Frame Buffer

X Client
X Client

NX
Server

Ssh Protocol
sshd

ssh

nxclient

X Server

(encrypted)
22

X Client

Tunnelled NX Protocol

So, what if you want to start up a whole session running on a remote

computer? We used to do this from devices called X Terminals, which
were simple-minded computers that just knew how to talk to a remote
display manager, through a protocol called the X Display Manager Control
Protocol (XDMCP) and ask it to start up a session for us. The resulting X
applications would then display their windows locally. This has the same
security problems we discussed earlier.
The better way to do it is to use nxclient. Nxclient is a commercial product
that's free for you to use. You can download it from here:
http://www.nomachine.com/download.php
The nxclient program is available for Windows, Linux and OS X. It talks to a
remote NX server that maintains a local virtual display in memory, called a
Virtual Frame Buffer (VFB). The NX server starts up applications which
send their display information to the VFB. The VFB can then be displayed
locally by the nxclient application. All traffic between server and client is
tunnelled through an encrypted SSH connection.
NX has the added benefit that its NX protocol is a highly compressed version
of the X protocol, and will give fast performance even over a slow network
connection.

Rules of Thumb for X Security (cont'd):

3. If you need a remote session, use nxclient.

23

Part 4: Virtual Consoles

24

One of the simple advantages of a graphical interface

is that you can have several terminal windows open
at the same time. This can be very convenient if
you're working on several different things at once.
Under Linux, you can accomplish something similar
without a graphical interface, too. The Linux kernel
implements something called virtual consoles.
These allow one monitor and one keyboard to act
like several independent text-based terminals.

To understand how X works under Linux, it's useful to

understand Linux's idea of virtual consoles. A virtual
console is an abstraction, created by the kernel, that can be
connected to a real display and keyboard. The kernel
creates virtual consoles on demand (up to 64 of them).
Normally, the program getty is running on the first few
virtual consoles. The getty program is the thing that asks
you for your username and password, and spawns off a login
shell for you when you log in.
Even if you only have a text interface, you can still have
access to multiple simultaneous terminal sessions, through
virtual consoles.
When you're outside of X, you can switch to a different virtual
console by typing alt-Fn, but when you're inside X, you'll
need to type ctrl-alt-Fn, because X typically traps the altFn sequence for its own use.

When the X program starts, it takes over the first

unused virtual console. On most Red Hat-based
systems (including Red Hat Enterprise Linux, Fedora,
CentOS, etc.), this will be virtual console number 7.
On older Ubuntu systems this will be virtual console
number 3, or number 7 on newer systems.
While X is running, you can switch to another virtual
console by typing ctrl-alt-Fn, where n is the virtual
console number.

Part 5: Fonts

27

This is one of those things you seldom need to think

about, but you may someday find that you need to
debug a font problem, so let's take a quick look at
the two font systems commonly in use under Linux.

Server-Side Fonts (the old way):

Originally, X used server-side fonts. When an application wanted to
draw some text, it would send the text to the X server, and tell the
server the name of the font it should use to display the text.

This

Remote Computer

X Client

Write This, in Chancery

X Server

Fonts
Arial
Chancery
Helvetica...

28

The advantage of this is that very little data needs to

be passed across the network. This is important for
slow networks.
The disadvantage is that the server's fonts might not
exactly match what the client expects, and the client
can't control exactly what the displayed text really
looks like.

Configuring Server-Side Fonts:

Server-side fonts are usually implement through a font server, called xfs, started at boot
time. The font server supplies font information to the X server on demand. It's capable of
dealing with several different types of fonts, and translating them into a format that the X server
can use. The main xfs configuration file is usually /etc/X11/fs/config .
# allow a max of 10 clients to connect to this font server
client-limit = 10
# when a font server reaches its limit, start up a new one
clone-self = on
# where to look for fonts
catalogue = /usr/share/X11/fonts/misc:unscaled,
/usr/share/X11/fonts/75dpi:unscaled,
/usr/share/X11/fonts/100dpi:unscaled,
/usr/share/X11/fonts/Type1,
/usr/share/X11/fonts/TTF,
/usr/share/X11/fonts/OTF,
/usr/share/fonts/default/Type1,
...
# in 12 points, decipoints
default-point-size = 120
# 75 x 75 and 100 x 100
default-resolutions = 75,75,100,100

To add a font, it should generally be sufficient to drop the font file

into one of the catalogue directories and restart xfs.

29

Listing Server-Side Fonts:

The xlsfonts command will give you a list of all the fonts known
to the X server:
~/demo> xlsfonts
-adobe-courier-bold-o-normal--0-0-100-100-m-0-iso8859-2
-adobe-courier-bold-o-normal--0-0-100-100-m-0-iso8859-2
-adobe-courier-bold-o-normal--0-0-75-75-m-0-iso8859-2
-adobe-courier-bold-o-normal--0-0-75-75-m-0-iso8859-2
-adobe-courier-bold-o-normal--0-0-75-75-m-0-koi8-ub
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso10646-1
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-14
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-15
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-2
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-2
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-2
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-9
-adobe-courier-bold-o-normal--10-100-75-75-m-60-koi8-r
-adobe-courier-bold-o-normal--10-100-75-75-m-60-koi8-r
-adobe-courier-bold-o-normal--10-100-75-75-m-60-koi8-u
-adobe-courier-bold-o-normal--10-100-75-75-m-60-koi8-u
...

30

Client-Side Fonts (the new way):

Server-side fonts are now deprecated. Instead, applications should use
client-side fonts. Current versions of most major software packages
now use client-side fonts.
With client-side fonts, the X client has direct access to the font files.
The client lays out the text as it wishes, then sends graphical
commands to the X Server, telling it to draw exactly what the client
wants.

This

Remote Computer

Write This
X Client

Fonts
Arial
Chancery
Helvetica...

X Server

31

Current versions of KDE, Gnome, the Mozilla browsers

(firefox, seamonkey) and Thunderbird all use clientside fonts. Only a few applications still use serverside fonts.

Configuring Client-Side Fonts:

Client-side fonts are configured through a system called fontconfig. The main
fontconfig configuration file is /etc/fonts/fonts.conf . This is an XML file containing,
among other things, a list of font directories:
<!-- Font directory list -->
<dir>/usr/share/fonts</dir>
<dir>/usr/share/X11/fonts/Type1</dir>
<dir>/usr/share/X11/fonts/OTF</dir>
<dir>~/.fonts</dir>
To add a font, the font file should be put into one of these directories (e.g., ~/.fonts) and then the
fc-cache command should be used to update the fontconfig cache:

~/demo> fc-cache -f -v ~/.fonts

To get a list of the fonts known to fontconfig, use the fc-list command:
~/demo> fc-list
Verdana:style=Regular,Normal,Standard
Dustismo:style=Regular
Candara:style=Italic
Luxi Serif:style=Regular
Liberation Mono:style=Regular
MiscFixed:style=Regular
Utopia:style=Bold Italic

32

Part 6: Desktop Environments

33

A desktop environment is a suite of X applications

that have a unified look and feel, and are designed to
work well together.
The two most popular desktop environments for Linux
are currently KDE and Gnome, but there's a lot of
turmoil going on in the desktop arena right now.

KDE:

34

Here's a KDE desktop. By default, its layout is similar

to the Microsoft Windows desktop. There's an icon
bar at the bottom, with a K menu (similar to
Windows' Start menu) at the left. Icons on the
desktop give quick access to file browsers, a recycle
bin, etc. Files can be dragged and dropped from one
application to another. The environment can be
configured, in great detail, through a graphical
control panel.

About KDE:

Developed in 1996 by Matthias Ettrich, a

university student in Germany.

Based on the Qt Toolkit, a commercial product which has

since been released under the GNU General Public License.

Name is a play on CDE, the Common Desktop

Environment promoted by corporations controlling the
development of X at the time. Ettrich called his effort the Kool
Desktop Environment.

Ettrich's goal was to produce an integrated, polished desktop

environment from a suite of matched applications. The
environment should be easy for even a novice user to master.

Matthias Ettrich's original Usenet posting:

http://groups.google.com/group/de.comp.os.linux.misc/msg/cb4b2d67ffc3ffce

35

Most Linux distributions make it fairly easy to choose

either the Gnome or KDE desktop. Some
distributions use Gnome as the default desktop, and
some use KDE. Among those that use KDE are
SuSE, Slackware and Knoppix.

Gnome:

36

Here's a Gnome desktop. Notice that the taskbar is on

the top, by default, and the main menu is a dropdown at the top left. Iconified applications appear in
a separate icon bar at the bottom of the screen. As
with KDE, desktop icons provide quick access to file
browsers, etc.
Both Gnome and KDE are highly configurable, and can
be made to look very different from these
screenshots. Gnome tends to be much less
configurable than KDE, though, since the Gnome
developers have eliminated choices that they believe
would be confusing to the end user.

About Gnome:

Developed in 1997 by Miguel de Icaza, a Mexican

software developer.

Based on the GTK+ toolkit, derived from GIMP.

Project began as an alternative to KDE, out of concern about

the license terms of KDE's Qt toolkit.

Gnome originally stood for GNU Network Object Model

Environment, reflecting the project's early reliance on CORBA
(an inter-application communication system similar to
Microsoft's OLE).

Gnome has concentrated on narrowing down users'

configuration choices and presenting a pre-configured
environment that is highly polished.

37

Gnome is currently the most common default desktop

environment among major Linux distributions.
Among distributions that use it as the default desktop
are Red Hat Enterprise Linux, Fedora, and CentOS.

Gnome vs. KDE vs. Other:

This 'users are idiots, and are confused by functionality'
mentality of Gnome is a disease. If you think your users are
idiots, only idiots will use it. I don't use Gnome, because in
striving to be simple, it has long since reached the point where it
simply doesn't do what I need it to do. Please, just tell people to
use KDE.
--Linus Torvalds, 2005
I used to be a KDE user. I thought KDE 4.0 was such a disaster
I switched to GNOME.
--Linus Torvalds, 2009
I'm sure there are other ways, but that's just an example of the
kind of "head up the arse" behavior of gnome3. Seriously. I have
been asking other developers about gnome3, they all think it's
crazy... I'm using Xfce.
--Linus Torvalds, 2011
38

KDE, Gnome and Xfce are all fine environments.

Unless you're planning to administer a department
(or a University) full of computers, just pick one and
learn to use it.
KDE has an edge in configurability. Gnome currently
has a greater installed user base, and more vendor
support. Xfce is simple, lightweight and stable.
They all have comparable speed. All are under
constant development by teams of very bright,
enthusiastic people.
KDE, Gnome and Xfce people work together to make
applications from each work well with the others.
There are no major functional differences between
them these days. It's mainly a matter of details and
tastes.

Gnome and KDE Applications Together:

39

It's important to remember that there's no reason you

can't use both Gnome and KDE applications at the
same time. (Or applications written in any other
toolkit, for that matter.) The X server doesn't care
what toolkit was used to create an application. The
choice of toolkit primarily controls the look and feel of
an application.
The screenshot above shows a Gnome gnometerminal, a KDE konsole terminal, a Gnome
calculator and a KDE calculator, all open at the same
time.

Since Linus mentioned Xfce, here's a screenshot

showing the default look of this desktop environment.
Xfce's focus is on being simple, fast and light
(meaning that it can run well on slow computers or
those that have only a small amount of memory).

Unity:

41

The future? The Ubuntu distribution has switched

away from Gnome, beginning with Ubuntu version
11, and is now using a new desktop interface called
Unity. Unity looks similar to the interfaces used on
mobile devices (ipods, ipads and iphones, for
example). It has large, friendly icons and limited
configurability. The goal of Unity seems to be to
appeal to computer novices.

Part 7: Configuring the X Server

42

More and more, you'll find that this is something you

never need to do. Here's a little information to help
you, just in case.

The xorg.conf File:

The primary configuration file for the X server is /etc/X11/xorg.conf:
Section "ServerLayout"
Identifier
"single head configuration"
Screen
0 "Screen0" 0 0
InputDevice
"Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver
"kbd"
Option
"XkbModel" "pc105"
Option
"XkbLayout" "us"
EndSection
Section "Device"
Identifier
Driver
EndSection

"Videocard0"
"vesa"

The xorg.conf file only needs to

specify settings that differ from
defaults.

Video Driver

Section "Screen"
Color Depth
Identifier "Screen0"
Device
"Videocard0"
Available Resolutions
DefaultDepth
24
SubSection "Display"
Viewport
0 0
Depth
24
Modes
"1280x1024" "1024x768 "800x600" "640x480"
EndSubSection
EndSection

43

I've picked a very minimal xorg.conf file, but these files

do tend to be rather small these days. Current
versions of the X server are able to pick intelligent
defaults by looking at the video hardware.
Some vendors (ATI and NVidia, for example) provide
proprietary (binary-only) video drivers for Linux.
These typically come packaged with installation
programs that will edit your xorg.conf file
appropriately.
In other cases, the configuration programs provided by
your Linux distribution may be able to do this for you.

Configuring the X Server:

Sometimes you need to edit xorg.conf by hand, but that's becoming
rarer. Usually, you can configure the X server using graphical tools
provided by your Linux distribution. Here are a couple of examples:

The system-display-properties application,

available under older versions of Red Hat-derived
distributions like RHEL, Fedora and CentOS:

The gnome-display-properties
application, available under most
newer distributions, including Ubuntu:

44

Finally, another look at what may be in store for the future.

In recent years, Kristian Hogsberg (a programmer who works on
graphics software for Linux) has developed an alternative to
the X server. He calls his new server Wayland. This new
graphics system has been written from scratch, without
inheriting any of the 20-year-old baggage from X. Hogsberg
aims to make Wayland simple, fast and light. It uses existing
features in the Linux kernel and modern video chipsets to do
most of the work.
Wayland is controversial, though, because it doesn't natively
support existing X clients, and (more controversial yet) it
doesn't have network transparency. Nonetheless, one major
linux distribution (Ubuntu) has said that it will switch from X to
Wayland in the future.
For more information about Wayland, see:
http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

The End

46

Thank You!