If
you look around the Internet long enough, you'll find much anger and
hate over the X server,
the piece of software powering all Linux and FreeBSD graphical terminals (or desktops if you prefer). A lot of folks
spare no chance to blame X servers for being slow, bloated and laggy.
In most ensuing arguments, the X server's client-server model is
targeted as being the main culprit. “No one needs it anyway” is
what they usually say.
Well,
I do.
I am famous for giving counter-arguments, but this time I will
not just play devil's advocate. I will tell you the real story of how
the X server client-server model saved my fluffy underside one
afternoon.
But
first, a few words for the uninitiated:
The
X server is the program which knows how to “speak” to your video
card. It knows what resolutions your screen can handle, the refresh
rates of your monitor and it can draw stuff using different shapes
and colors. Not only that, it can also “read” where your mouse is
pointing to on the screen and whether you clicked on it or not.
Normal programs like Firefox and LibreOffice can present themselves on your screen and take inputs from your mouse
by “talking” to the X server. If there was no X server, each
application on your computer would need to know how to operate every
graphics card on the market, making software development a rather
painful occupation. All recent GNU/Linux and BSD operating systems
use X.org to do
graphics, a free (as in free speech) X server implementation.
Other
operating systems have something equivalent to an X server. In Apple
computers it's called Quartz and in Microsoft
Windows, GDI.
The
X server, however, has two very important and distinctive differences
compared to GDI and Quartz:
First,
the X server is not embedded into the operating system kernel as
Quartz and GDI are, it's a normal application. This makes the X
server slower and laggier than its competition, because programs
running in kernel space go through less restrictions and checks than
programs running in user mode. On the other hand, if the X server
happens to encounter an error, it does not bring down the entire
system with it. Only the X server fails and any programs that were
using it. What happens if GDI or Quartz fail, is left as an exercise
to the reader.
The
other difference is that, where GDI and Quartz function as libraries
to their applications, the
X server uses a client-server model to communicate with applications using it. Just like Firefox connects
to a remote web server through the Internet, to display a web page,
exchanging information encoded in HTTP and HTML format. In the same
way, to display itself on your screen, Firefox connects to the X
server and they exchange information using the X11 protocol. The
beauty of this arrangement is that, since the client-server model is
network-transparent, Firefox and the X server can actually be on
different machines!
I
got to whitness all of this fascinating stuff when I was playing
around with ltsp.org, a project which allows you to use obsolete and
otherwise useless computers as cheap, dumb graphic terminals to a
more powerful computer, a terminal server. In essence, ltsp.org uses
the X server's client-server model to its fullest potential: The old
computers only need enough resources to run an X server. All
applications are run on the powerful terminal server and display
their windows on the old computer's X server.
But
being fascinated is one thing. Being saved is quite another.
So
I am in Patras, Greece, at a computer gathering at the local
university, about 200km away from home and work. I am having a good
time until the phone rings, which rarely is a good sign. It's a
colleague from work. Apparently a site we were hosting was having a
hard time keeping up with the visits it was receiving. Normally, I
would use a VPN to connect to the machine and check out what was
wrong, only this time, I was not at home. I tried the VPN software
from there, but it didn't work. Thank you very much, piece of
proprietary crap!
And
so I started experimenting. I connected to my computer at home using
SSH,
enabling X11 forwarding. What is X11 forwarding you say? Well, it's a
neat SSH trick. While you connect to the remote computer, it also
opens a reverse connection from the remote computer to your local
computer's X server. So if I run Firefox on the remote computer, the
program will be running there, but the window and and pages I request
will be presented here. And all of that encrypted over the SSH
connection!
So
I have an SSH connection to my home computer with X11 forwarding
enabled. I fire up the VPN from home to my work network and
thankfully it works. I then proceed to do a second SSH connection
from my home to my work computer, again with X11 forwarding enabled.
At
this point I am thinking: “There is no way X11 forwarding can be
daisy-chained across two connections. I will try this just for the
sake of the effort.”
I
get my work machine's prompt. Last step is to attempt to do a remote
desktop connection towards the server with the problem (It was
perhaps redundant to mention that the server having problems was a
Windows box...). I type
rdesktop <hostname>
on my work computer's prompt and expect with 99%
certainty to be humiliated with a sarcastic version of a “Surely
you must be joking” message.
And
then, the unthinkable happens: The Windows server's prompt is
displayed on my screen. It had worked. The rdesktop program, running
on my work Linux PC, was displaying the Windows server login screen
through the X11 tunnel to my home Linux PC, and through the second
X11 tunnel to my Linux laptop in Patras. It was slow and just barely
usable. But it worked.
I
don't remember anymore what I did to fix the server. I most probably
restarted the services and things got better, as is usually the case
with Windows. But I will never forget how being able to route
application interfaces through the network helped me solve the
problem that day.
Alot
of folks hate every minute of using X.org and they would switch to an
alternative in a heartbeat. Some of them have gotten so fed up, they
are preparing an alternative, called Wayland. It's a gargantuan task replacing the beast that is X.org and I
wholeheartedly wish them good luck and to stay strong on their task.
Competition is always good in software projects. Moreover, I too am
frustrated that X.org is not as smooth as OSX and Windows and to be
entirely frank, I am a little envious.
But
if Wayland doesn't do client-server, I see myself staying with X.org
for a very long time.
