Beyond the basic kernel, Linux development is a free-for all with anyone able to write or adapt any elements of functionality they want for a system.

Given the fanaticism that graphical user interfaces (GUIs) generate across different platforms, it should come as no surprise that many people have tried to shape the structure of graphical environments for Linux.

For the sake of ease of use and consistency, the Windows and Macintosh operating systems have very strict, centrally administered rules governing how applications can be written and what standards must be adhered to in terms of functionality and appearance.

This is done with good reason: without them, there'd be a confusing mishmash of application and menu layout standards, with applications that appear inconsistent as a result of using different widget sets.

System resources would also be wasted by having to load multiple files that perform the same task. These problems haven't troubled most users since the pre-Windows era, when every DOS-based program had its own basic GUI and menu system that had to be deciphered on its own.

Now, however, it's taken for granted that Windows programs will function in a certain way. This type of centralised control was never going to be possible in the Unix world, so the system was designed from the ground up to be extremely open, extensible and configurable.

The downside is that, until the recent Gnome and KDE projects, the Linux desktop was convoluted, confusing and lacking in features.

The basis of Linux GUIs is a free implementation of the X Windows system called Xfree86. In one form or another X Windows provides basic functionality for practically all GUIs under the various flavours of Unix, with servers existing for Windows, Mac OS X and others. On top of X, a window manager is employed to draw the windows onscreen and display application data.

This is where the confusion begins, as there are many window managers available for Linux, with different features to suit most tastes.

This is all that's necessary for graphical computing, but most users opt to go the final step and run a desktop environment such as Gnome or KDE, which enforces a consistent look and feel to applications, as well as providing features like information embedding and drag-and-drop.

The X Windows system

Following the Unix philosophy, X Windows was built from the ground up to be a networked, multi-user, client/server graphical environment. As such, it does a lot more than simply draw pictures onscreen and this, perhaps, excuses some of its size and complexity.

Rather than being a part of the operating system, as with GUIs in other modern operating systems, X is just another server that sits on top of the kernel providing functionality.

Originally developed by the Athena Project in 1984, it came under the control of the X Consortium in 1988, which continues to administer and oversee its development.

The job of the X server is to communicate directly with the input devices and graphics hardware on the system, so all applications have to do is talk to the X server and it will take care of hardware input and display output without each application having to know anything about the display hardware.

X Windows doesn't just perform these tasks for a single machine, but allows multiple users to connect and display information from other devices across a network.

Users can log in to a central server and have all data displayed on a local thin client or run an application on one machine and have it displayed on another, including word processors, web browsers, output from a very intensive computation or image editors.

Hardware

X Windows not only displays output, but collects input to feed to applications, requiring keyboard and mouse compatibility, as well as display and video adapters.

Most of these are straightforward: X can handle most modern keyboards and mice, including PS/2, USB and infrared interfaces. Your video card determines the compatibility of the display, so any that can be driven by your graphics hardware will be perfectly happy with Linux.

The only difficult bit is making sure that X Windows is able to talk to your graphics adapter. There are many variants of the X Windows server, with each different type of graphics hardware requiring its own version.

While some cards can get away with a generic SVGA server, others require something more specialised, especially newer boards with 3D acceleration or advanced features.

The list of supported cards is quite long and extends right up to the most recent nVidia boards, although users are advised to check for issues with their specific hardware.

As most drivers are written by Linux enthusiasts and not the companies themselves, drivers often don't appear immediately on release of the hardware and special features might not be supported right away, if ever.

Supported cards are listed here, although vendor sites should also be checked.

Notebook PCs can also be problematic, as they often contain non-standard hardware that can't be changed. Specific hardware can be checked at www.linux-laptop.net.

Running X

Configuring X Windows has been made much easier in recent years. Distributions have tools that perform set-up during and after installation, in addition to the xf86config utility which comes with X Windows.

The main configuration file for X Windows is XFConfig or XFConfig-4 for Xfree86 v4 and above, which is generally found at /etc/X11/, although this might change between distributions.

This file contains the information that X needs to communicate with your display and graphics hardware. Generally, this file will be created by the distribution installer or a configuration program that can detect your hardware and set things up for you.

The adventurous can edit the file by hand to get non-standard resolutions (anything your hardware supports is OK) or fine-tune clock timings.

It's important to check the capabilities of your hardware before entering values here, as incorrect settings might damage your equipment. It's also a bad idea to simply drop in a config file from another machine, as it will almost certainly be set up for different equipment.

Aside from listing the devices and pointing to the proper drivers, the file contains a 'screens' section, which defines graphics hardware, resolution and colour depth.

There could be multiple entries here for different resolutions at which you might want to run. You can toggle through the resolutions while running X by hitting Ctrl-Alt-+ and Ctrl-Alt -. Separate applications, such as Gnome QuickRes, are needed to change colour depth on-the-fly.

Window managers

On its own, X can do little more than output pixels to screen, a process that would leave users with a grey, snowy background underneath an immovable xterm.

A window manager makes the display more attractive but, more importantly, adds several pieces of functionality, allowing the user to interact with X, drawing windows around applications and creating menu systems in their window.

In addition, many perform extra tasks, such as providing background wallpaper, controlling key bindings for mouse and keyboard shortcuts, launching programs either by a wharf/toolbar or by context-sensitive right-clicking, and multiple desktop functionality.

There are many available for free download, with a different range of features to cater for most tastes. At the lean end is fvwm, an 'old school' window manager that provides basic functionality with a very low resource footprint favoured by those who think that the best thing a window manager can do is stay out of the way.

At the other end is Enlightenment, which is designed to be extremely powerful and infinitely configurable. If you have a fast machine and love having weird, eye-candy desktops with unique themes and windows that aren't just boring rectangles, this could be for you.

Choosing a window manager used to be a near religious decision, as it controlled how you interacted with the computer, and dominated what you perceived a computer to be. Check out www.plig.org/xwinman/ for more information and pointers to the most widely used window managers.

These days, your choice might be dictated to some degree by whether a window manager is compatible with your desktop environment, such as Gnome or KDE.

Both function with their defaults and a few others, including Enlightenment and the popular Windowmaker, are among others available.

A window manager will still work even if it isn't supported by a desktop environment, but there might be conflicts over which draws the background or a context-sensitive right-click menu and some features might not work.

It's up to the user to decide what's most important to them. Many still load the libraries that allow them to run Gnome and KDE applications without running either environment, preferring to operate with just a window manager.

Desktop environments

Desktop environments for Unix have existed for many years, principally in the form of the not very attractive or functional and not free CDE. In recent years, Gnome and KDE have been getting a lot of press, as they've developed a lot of the functionality that allows Linux to compete with Windows on the desktop.

Without an environment, all applications run separately without any way to interact with each other, so there's no way to perform data linking and embedding or even simple drag and drop.

They also include taskbar equivalents that provide application launchers as well as a central location for resources, such as help and control panel access. Much of this functionality can be taken care of by the window manager, reinforcing the importance of having a window manager and desktop environment that work well together.

Desktop environments provide a consistent look and feel through the use of constant menu conventions and the same widget set, which also lessens the resource burden.

As with window managers, applications must be written to take advantage of the properties of a desktop environment. To this end, both Gnome and KDE have large lists of software for almost any purpose on their websites, with both going so far as to have full office suites in development.

Applications from a particular environment can still be run, even if you choose not to run it, as long as the proper libraries are installed on your machine.

Gnome and KDE work increasingly well with each other, for example importing the other's programs into each application launchers and allowing for interaction between the two systems.

Both are moving ahead with great speed: KDE has just released version 3 and Gnome 2 was scheduled for release in April 2002.

Launching X Windows

There are two common ways of launching X Windows. Traditionally, after logging in at the console, the user types in startx. This calls xinit, which launches X and looks for configuration files called xinitrc and xclients.

There will be general copies of these files for system-wide defaults (generally found in /etc/X11/xinit/), although each user can make a copy with personal preferences that will live in their home directory. Note that personal copies will exist as .xinitrc and .xclients, with the preceding full stop indicating a hidden file.

To display these files, type ls -al at the console, with the 'a' flag displaying hidden files. Xinitrc sets up the environment, configuring resources and performing tasks such as loading the proper keyboard mappings.

It will then check to see if there are any scripts that need to be run to launch other clients. Following this, it checks for the existence of an xclients file, either in the user's home directory or in a central location, performing the instructions in whichever it finds first.

In case no xclients file is found, failsafe instructions are included to launch a basic environment, in this case a clock, an xterm and the Netscape browser. Note how applications can be launched to appear at a certain position onscreen and with certain properties configured.

In this case, it controlls what page Netscape loads on launch although, similarly, you could set the background colour of the xterm, for example. After this, the script tries to load one of the more basic window managers that can be found on most systems; first the light, but functional, fvwm and failing that the truly spartan twm, which is better than nothing at all.

Preferably, all of this will be achieved by finding an xclients file. The xclients script first tries to launch a desktop environment, in this case Gnome or KDE. Preferences should be configured in a file but, if it can't be found, it will try to launch whatever it can find, in this instance trying Gnome first, then KDE.

If a desktop environment is found, it will take care of launching a window manager and default applications as specified by the user in the control panel of that environment. Failing that, it tries to launch a window manager, this time starting with Windowmaker, then recent variants of fvwm.

As with desktop environments, window managers have methods of launching applications. Again, when all else fails, it tries to launch twm and some basic applications. Commands can also be appended to the startx command, but it's easier to edit the config files or just perform the tasks once X has started.

The other, increasingly common, method is to use a display manager that launches X as part of the boot process so that the GUI is already running before you log in.

X comes with X display manager (xdm), with both Gnome and KDE having their own versions (gdm and kdm, respectively), which perform similar functions. In addition to launching X, this method can be used to define local, as well as remote, network 'displays' - the system by which X determines where to display applications.

This can be used to differentiate between using a notebook PC's built-in display against an external pane or whether to display an application on the local display or a remote desktop thousands of miles away.

Remote working

X is network aware and, while this makes it very powerful, it introduces problems of security and complexity. Where should applications be displayed? Who should get to see what is displayed on your desktop? Should other machines be allowed to write to your display?

X runs backwards to the normal perception of client/server. The server is running on your local machine, providing the graphics output. Each application is considered to be a client that connects to the server, sending it information to be displayed.

You can set X to accept or reject all connection attempts going in either direction. Given the security risks it's best to turn off all connections and enable them on a case-by-case basis.

When starting an application, X has to know where to send the output. By default, it will be sent to the local display, known as :0 (display 0). To have the application output sent to another place, it must be redirected to the hostname of that display.

For example, let's say that we perform our calculations on think.pcmag.co.uk, but want to display them on show.pcmag.co.uk. From 'show', you'd telnet into 'think' and enter:

Setenv DISPLAY
think.pcmag.co.uk:0

This tells it to display the output on display 0 (the default) of the local display.

Next, run the application Process_logs.pl &. Keep in mind that this will direct all output to show.pcmag.co.uk until switched off. A different method that's more compact and functions on a single-case basis would be process_logs.pl -display show.pcmag.co.uk:0 &.

The exact structure of the command can change depending on which shell you're running, but the display reference will remain the same.

Before doing this, you must set up the host, telling it to receive the request to display the data. Access to hosts can be given three ways. The easiest is to set it on the command line using the DISPLAY environment variable, which gives permissions based on hostname. In this case, we'd use:

Xhost + think.pcmag.co.uk

And when finished switch it off with

Xhost -think.pcmag.co.uk

The careless can simply set xhost + to allow anyone to connect (or xhost to bar all connections), although this isn't recommended for security reasons. For machines requiring frequent access, you can set up a hostnames file that allows access for some devices.

While easy to use, this method has a number of shortcomings, such as being unable to distinguish between different users on a remote machine and being susceptible to spoofing.

The second method is called Xauth, which uses a cookie system to control access. At the start of a session, the server reads a cookie and only allows access to remote systems with the same cookie. Provided you keep the directory with the cookie files in it secure, this is preferable to xhost.

Arguably the best solution is to forward your X session over a secure shell connection, which controls the log-in process and encrypts the data as it travels between the two machines. To use this method, either use the command line switch -X or enter the following into your ssh config file:

Host remote.host.name
ForwardX11 yes

If you don't want other machines to connect to yours, the most effective step is to add -nolisten tcp to the end of the main command in xserverrc. This will prevent the X server from listening for incoming connections and minimise the security risk. K

RESOURCES:

Here are some popular Linux distributors to check out:

Best Linux
www.bestlinux.net

Caldera
www.calderasystems.com

Conectiva
en.conectiva.com/

Debian
www.debian.org

Linux-Mandrake
www.linux-mandrake.com

RedHat
www.redhat.com

Slackware
www.slackware.com

SuSE
www.suse.com

Xandros (previously Corel Linux)
www.xandros.com