X Window System Administration
When the X Window System was first released, many complained that the system was big, slow and complicated. My first experience with X was installing one of the earliest releases available for Intel hardware on my 386 running UNIX with 4MB of RAM and an 80MB hard drive. The installation took up most of the drive, and X ran so slowly (with much thrashing of virtual memory) that it was simply unusable. I quickly decided to remove it from my system and went on to “real work”.
However, I got a taste of what X was like and appreciated how the developers took the “high road” in their design. They combined a high degree of versatility and a client-server architecture, at the noticeable expense of performance on what is now generally considered to be archaic hardware.
Today, most computers running Linux have more than sufficient hardware resources to run X with good performance, so running X on an inexpensive desktop system is commonplace. Now that we've all got X running on our desktops, the next hurdle is configuring X and customizing it to meet our needs.
I will start out by presenting a brief description of how X is structured and how the parts interoperate. Once you know this, it will be much easier to make sense of the implementation details.
One of the most basic facts to be aware of is that X is not part of the kernel. Unlike other operating systems, where applications make requests to put up windows, menus, et al., to the operating system API, X is entirely contained in user space, running as ordinary processes. These processes are classed into two groups: client processes and server processes.
The job of the X server is to handle the interface to the hardware (graphics adapter, keyboard and mouse) and a few additional low-level services such as drawing, color allocation, event handling, inter-client communication and managing a resource database of user preferences.
Clients communicate with the X server through the X protocol, which can be run over interprocess communication (IPC) on one system, or between systems using TCP/IP. This allows an X client to run on one system and use the display, keyboard and mouse on another. Yes, it is even possible to run an X protocol over the Internet.
For example, if I use TELNET to access my ISP and run the command xeyes, the program will start up and display a window on my Linux system. The program seems to be running locally, even though it is actually running on the remote system and just using my system for the display. The way this works is that the remote system is running xeyes, while the client (requesting services) and my Linux system are running the X server (which fulfills the client's requests). This, of course, requires that my system be set up to allow it; I use the xhost command to allow my ISP's system to use the X server on my system. Also, the $DISPLAY environment variable in my TELNET session must be set correctly (see below). I am using this example only as a demonstration; if you want your system to be secure, you will probably not want to allow people to access your X server from an outside network. One trick used by crackers is to put up an invisible window covering your display that catches all keyboard input, including passwords.
Each display is handled by one server process, but many clients can use a display at the same time. One of the most fundamental client types is the window manager, which allows the user to manipulate windows. A window manager performs actions such as drawing “decorations” around windows (borders, title bars and buttons), and provides functionality such as pop-up menus and the iconization of running clients. Desktop environments such as KDE and Gnome are implemented as user-space X clients, as are all other applications that run under X. These applications can be of any level of complexity, from xlogo to Netscape Navigator.
In the remainder of this article, I will cover some basic X Window System administration. A full treatment would take a whole book, so I'm going to discuss only what I consider the most important points for the novice X administrator. For the most part, I will assume you have X already configured and running. I will skip over advanced topics such as security and running X over a network (on X terminals or remote systems) as much as possible. This article covers XFree86, which comes with most Linux distributions. If you are running a commercial X server, you may want to skip the section below on configuring the X server, but the rest of the material covered is independent of the server you are using.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
3 hours 41 min ago
- Yeah, user namespaces are
4 hours 58 min ago
- Cari Uang
8 hours 29 min ago
- user namespaces
11 hours 23 min ago
11 hours 48 min ago
- One advantage with VMs
14 hours 17 min ago
- about info
14 hours 50 min ago
14 hours 51 min ago
14 hours 52 min ago
14 hours 54 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?