Xis a stupid name for the system responsible for drawing the windows on your screen, and for managing your mouse and keyboard, but that's the name we're stuck with. As with the glut of programming languages called B, C, C++ and C#, X got its name because its the successor to a windowing system called W, which at least makes a little more sense.
X has been one of the most important components in the Linux operating system almost from its inception. It's often criticised for its complexity and size, but there can't be many pieces of software that have lasted almost 20 years, especially when graphics and GUIs have changed so much.
But there's something even more confusing about X than its name, and that its use of the terms 'client' and 'server'. This relationship hails back to a time before Linux, when X was developed to work on dumb, cheap screens and keyboards connected to a powerful Unix mainframe system.
XTERM: The original XTerm is still the default failsafe terminal for many distributions, including Ubuntu
The mainframe would do all the hard work, calculating the contents of windows and the shape of the GUI, while all the screen had to do was handle the interaction and display the data. To ensure that this connectivity wasn't tied to any single vendor, an open protocol was created to shuffle the data between the various devices, and the result was X.
Client–server confusion
What is counter-intuitive is that the server in this equation is the terminal – the bit with the screen and keyboard. The client is the machine with all the CPU horsepower.
Normally, in client–server environments, it's the other way around, with the more powerful machine being called the server. X swaps this around because it's the terminal that serves resources to the user, while the applications use these resources as clients.
Now that both the client and the server run on the same machine, these complications aren't an issue. Configuration is almost automatic these days, but you can still exploit X's client–server architecture. It's the reason why you can have more than one graphical session on one machine, for example, and why Linux is so good for remote desktops.
The system that handles authentication when you log into your system is called PAM (Pluggable Authentication Modules), which, as its name suggests, is able to implement many different types of security systems through the use of modules.
Authentication, in this sense, is a way of securing your login details and making sure they match those in your configuration files without the data being snooped or copied in the process. If a PAM module fails the authentication process, then it can't be trusted.
Installed modules can be found in the /etc/ pam.d/directory on most distributions. If you use Gnome, there's one to authenticate your login at the Gdm screen, as well as enabling the auto-login feature. There are common modules for handling the standard login prompt for the command line, as well as popular commands like passwd, cvs and sudo.
Each will use Pam to make sure you are who you say you are, and because it's pluggable, the authentication modules don't always have to be password-based. There are modules you can configure to use biometric information, like a fingerprint, or an encrypted key held on a USB thumb drive.
The great thing about PAM is that these methods are disconnected from whatever it is you're authenticating, which means you can freely configure your system to mix and match.
Command-line shells
The thing that controls the inner workings of your computer is known as a shell, and shells can be either graphical or text based.
Before graphical displays were used to provide interactive environments to people over a network, text-based displays were the norm, and this layer is still a vitally important part of Linux. They hide beneath your GUI, and often protrude through the GUI level when you need to accomplish a specific task that no GUI design has yet been able to contain.
There are many graphical applications that can open a window on the world of the command line, with Gnome's Terminal and KDE's Konsole being two of the most common. But the best thing about the shell is that you don't need a GUI at all.
You may have seen what are known as virtual consoles, for example. These are the login prompts that appear when you hold the Alt key and press F1–F6. If you log in with your username and password through one of these, you'll find a fully functional terminal, which can be particularly handy if your X session crashed and you need to restart it.
Consoles like these are still used by many system administrators and normal desktop users today. It takes less bandwidth to send text information over a network and it's easier to reconstruct than its graphical counterpart, which makes it ideal for remote administration.
This also means that the command line interface is more capable than a graphical environment, if you can cope with the learning curve.
By default, if you don't install the X Window System, most distributions will fall back to what's known as the Bourne Again Shell – Bash for short.
THE TERMINAL: Most Linux installations offer more than one way of accessing a terminal, and more than one terminal
Bash is the command line that most of us use, and it enables you to execute scripts and applications from anywhere on your system. If you don't mind the terse user interface of text-based systems like this, you can accomplish almost anything with the command line.
There are many different shells, and each is tailored for a specific type of user. You might want a programming-like interface (C-Shell), for example, or a super-powerful do-everything shell (Z Shell), but they all offer the same basic functionality, and to get the best out of them, you need to understand something about the Linux filesystem.
