Aaxsys Notes
  More articles

January 27 2009

On the Linux Desktop

(On an original "mistake" in the Linux project)

Introduction.

Aaxsys runs on Linux servers. The database (MySQL) server and the worker members of the cluster, even the routers, are all based on a combination of distributions of Linux. On the other hand, almost no clients come from a Linux-based desktop. However, their number is not zero. But taking a crude line count from an Apache access log, 85.6% came from Windows, 14% from Mac OS, and the remaining mere 0.4% from Linux. There is no intrinsic reason for this. Aaxsys is web-based and functional on any platform that has a (sufficiently standard compliant) browser available. While the combination of Linux and Apache rules the web, the reception of that content via Linux itself is reduced to the margins only.

In this article we claim that this situation goes back to a fundamental decision, or rather an omission, made in the very early stages in the development of Linux. Whether this decision should be called a mistake depends on one's basic understanding of the role of Linux. For many enthusiasts, in the late 1990's and the early years of this decade, desktop Linux was coming soon to replace Windows. From today's perspective, the development has been stagnant. In a couple of years, Linux will reach the age of 20. As a 32-bit operating system, it has been available even longer than Windows (NT having been released in 1993). Having a history this long, it should be reasonable to suspect there is a fundamental problem why Linux is only a marginal player on the desktop.

At first thought, one could say the same about Macintosh. Its market share is less than 10% after 25 years of existence. But there is an essential difference. Macintosh has traditionally been a hardware-bound operating system, beyond the major world of the PC. Linux, on the other hand, runs on almost anything, including Mac hardware itself. One could think the availability on cheap hardware together with a free-of-charge OS and applications would be an incentive for its more extensive adoptation. But this doesn't seem to be so.

The lack of a native desktop.

The graphical user interface in Linux is done via X-Windows. Similar to the early versions of Windows (1 - 3.X), it is, in fact, an application separate from the kernel. The Linux kernel is that part of the OS that makes Linux uniquely what it is, distinct from the various tools, applications and utilities that are, to a large part, common to a wider (Unix) heritage and development than Linux itself. The early form of the Linux kernel - say the Release 0.01 of 1991 - did not yet have the path of its development drawn and ready to be followed. The kernel had about 10000 lines of code. But very soon a large number of utilities were ported to Linux, among them X-Windows. This enabled the users have a "running" start for a GUI; the tools already developed for X were already available.

It was at this stage when the fundamental flaw entered in the design of Linux. There was no early decision to include a graphical interface. One could point out several reasons (beyond the creator's focus on the command-line). The interface would have been very primitive, and bound to specific hardware (video card). However, the early system was limited to a special kind of hard disk and keyboard. One could also say: Who actually used a GUI those days, outside of Macintosh and the very X-Windows of the expensive and rare graphical workstations? However, already in the 1980's, various graphical menu systems and shells were on the rise. We obtained a first-hand look into this realm through our work on a graphical previewer for TeX (Knuth's type-setting system for mathematical and technical text) in the mid-1980's.

A TeX previewer - apart from a similar "driver" for a printer - involved switching the PC to graphical mode and then manipulating the video memory for graphical effects. At that point, we had plans of extending the system with an elementary Postscript drawing interface to facilitate integrating graphics with TeX. This was never realized. But the elements of an elementary desktop were already available.

 
The main problems.

Due to not having included a native graphical interface into the Linux project from the beginning, but instead utilizing the then existing Unix way of displaying graphics (X-Windows), major problems ensued.

A. The first set of problems is due to the design of X-Windows. Due to its "network transparency", it was designed to be able to have the graphical display in machines (typically workstations) distinct from the machines (typically servers) in which the applications are run. For some reason, it is the client program that is called the X-server, while the remote counterpart is called the "client". The X-server runs as a user space application, outside of the kernel. Its client-server model (even when run in a single machine) separates the application and the X-server, leads to extra context switches (between kernel and user modes), extra buffering, round-trips and latency. In our personal experience, the interaction between the Linux GUI and the applications always seemed unresponsive. Until recently the desktop couldn't even tell that an application was loading, because for an X-server, separated from the application as it is, the application must take care of displaying this information itself. To sum up, the choice of X-windows instead of a native, possibly kernel-based graphical interface led to a desktop that felt slow compared with Windows.

B. Instead of becoming a focus of unified development, the Linux desktop first remained in the sidelines. Once started, the effort became divided between two major desktop environments (KDE and Gnome) that produce competing "looks" and are based on separate libraries and toolkits (Qt vs. GTK+). Unfortunately, these two are not the only projects in this area. We feel that this multiplicity has not only slowed down the development, but also hindered potential developers joining the effort. (These are developers who want to work in the center, not in the sidelines, and would like to see that their efforts lead to permanent value.) Compared with the kernel development that carries the inofficial stamp of "proper Linux", the desktop efforts can be seen like third-party tools for making Linux more user-friendly. Novell's Better Desktop Initiative refers to the problems of usability within these desktop environments.

GUI in kernel?

As is well known, with Windows NT 4.0, Microsoft moved critical parts of the graphical interface (the window manager and the graphical device interface - GDI) into kernel mode. The costly client-server mode in NT 3.51 was replaced by the single-container "executive" service in NT 4.0. This has been criticized as endangering the stability of the operating system: By including the graphics device drivers and other critical GUI code in the kernel, a badly behaving application could bring down the entire system. On the other hand, it is said, by keeping these functions separated in the user space, a malfunctioning program would only crash the particular GUI service under which it is running. Our own experience seems to negate this point. After running NT 4.0 for 10 years, with extensive applications, we have had very few system crashes. While IE has constantly crashed on us, it has never brought the entire system (or even other applications) down. Our XP has not crashed even once.

Linux gives a somewhat different picture. Our frequent problems with X sessions seem to indicate that either 1) the various parts do not seamlessly work together, perhaps because there is no single group of developers who could ensure this or 2) they have adopted a kind of laissez-faire attitude perhaps due to the idea that a crashing X session does not bring the OS down. For a user whose work is based on the command line and for whom GUI is just a helpful extension, a crashing X session does not necessarily destroy their work. However, for the "mass" user, for whom the desktop is all they will ever use, a crash in X Windows is tantamount to a re-start. Then what is the difference between Windows and Linux in this respect? For the mass user, it is the more responsive GUI.

For many serious Linux users, a kernel-based windowing system seems to be a definitely crazy idea, due to stability and security concerns. Additionally, the mere size of X11 would imply a "bloated kernel" if it were included. Here we come back to the main argument of this article. If a native desktop had been adopted into the Linux project from the beginning, there should be no intrinsic reason why multiple kernels could not be supported. Linux has always supported configuring and compiling alternative

 
kernels, adding or reducing various OS features. With the native GUI, Linux would simply come with two default kernels, one with the graphics support compiled in the kernel, and the other in which it is placed within the user mode. Let the users pick their choice!

In fact, there are in-kernel replacements for X11. MicroXwin is an X11 compatible replacement for embedded systems that implements graphics processing in the kernel as a loadable module. The Linux framebuffer is a graphics abstraction layer that allows graphical display circumventing X Windows. There exists a framebuffer UI (FBUI) which is a small in-kernel window manager for the framebuffer. They represent (today) what could have been the native Linux graphical user interface in its embryonic form, more than 15 years ago.

 
Aaxsys Notes, January 27, 2009