Is X The Future?

Future Linux-Guru wrote in to tell us about an essay thats running over at OS Opinion that talks about X11s Future. Not an issue we talk about much: Sure, X solves the problem, and in many ways, its very elegant, but is it really the standard that we all want to be using for our GUI coding in the future? This essay argues that we should. Do you agree?

Comments

Re:You've missed the point of X

[Jamie Zawinski]

The argument that "X is slow because of its network capability" doesn't hold any water and is really used only by people who don't understand X. X is slow (in some ways, it is) for other reasons... ones that, generally, can be solved.

In a word, wrong.

X is slow because of the separation of servers and clients, i.e., the client-server model, i.e., its network capacity. It doesn't matter that it uses shared segments in the degenerate case -- it still takes a dozen context-switches amongst three different processes before an X client can even pick its nose.

Windows and other window systems are way faster because when a program wants to draw a line, the DrawLine call in the graphics library ends up putting bits in a frame buffer. On X, the amount of overhead for every operation is just staggering. Even more so when window operations are involved rather than simple graphics operations.

For the dubious feature of sometimes being able to have clients and servers on different machines, you pay the price of never being able to have decent performance in the common one-machine case.

in answer to the original questions...

[Jamie Zawinski]

With this question, I don't want to start a discussion if X should be replaced or not, but I only want to find out what's bad about it and where other solutions are better.

There has been a lot of discussion here already about what X's failings are. Quite a lot of it has been wrong (X has many problems, but it's not that ``tvtwm sucks.'' That has nothing to do with X.)

The X chapter of the Unix Haters' Handbook really does do a great job of covering the major points. Yes, this was written several years ago, and not all of it is relevant any more (for example, most Linux users don't use Motif, so all the abuse piled on the Motif implementation probably isn't relevant to most of you; and GTK doesn't even use the X resource manager, so most of you probably don't use your .Xdefaults file any more.) But where he talks about the X protocol, the low-level X API, and the horrors that X's fundamental design decisions have inflicted on us (``run xterm well'' with window management added as an afterthought) it's spot-on. The ``Myth: X Demonstrates the Power of Client/Server Computing'' and ``Myth: X is Device Independent'' section are especially key.

But none of that matters . Why? Because it doesn't matter how much X sucks, because X is entrenched. It works badly, but it works well enough. It is the de-facto sub-standard. It cannot be replaced, or even fixed, without rewriting every single graphical application you have ever seen, and that's just not practical.

Worse is Better.

Another point I feel the need to make is that most of the people who have been posting to this thread don't understand what X actually is. Some people are talking about X, and some people are talking about ``the sum total of the graphical Unix experience'', of which X is only a small part. In particular, if you're flaming the way your window manager works, you're not talking about X, you're talking about some random crummy application. There are a ton of window managers (there are possibly even more WMs than there are IRC clients, and that's pretty impressive.)

The source of this confusion is that most other window systems come with policy: the look of the window management controls are built in to the window system itself, as are all kinds of other things like cut-and-paste and drag-and-drop: in the interest of ``flexibility,'' X left all of these things undefined, meaning there is no consistency at all.

X itself is very low-level, handling graphics operations and little else. Though small, it imposes serious performance restrictions by the nature of its design.

Because X itself does close to nothing, on top of it, many organizations have built the so-called ``toolkits'' that let you actually build user interfaces. These toolkits impose policy, and implement all the things that one would expect from a window system if one's first experience with a window system was something other than X.

These toolkits inherit all the limitations of X, and then add more of their own: Athena is ugly as sin, and does very little (it doesn't even have real menubars.) Motif was insanely buggy for years, and is still incredibly inefficient. GTK is slow, and isn't really finished yet. KDE requires C++. And so on. And of course all of them are incompatible with each other to various degrees.

If you're bitching about things not being ``object oriented'' enough, then you're bitching about a toolkit, not about X. X itself is so low level that there's just no need for OO hair: those abstractions come at a higher level.

Some people think it's a great thing that X doesn't come with policy. I say nonsense: rampant customizability is almost always an excuse for not having taken the time to get it right in the first place. I just want an appliance that works, I don't want to have to spend days tweaking it before I can turn it on.

Here's what X's lauded ``flexibility'' has given me: right now I'm looking at a screen that has applications on it written using five different toolkits. They all work basically the same (which is to say, they all work basically like a Xerox Alto), but each one renders menus differently, and half of them do cut-and-paste in incompatible ways. Thanks to the flexibility of X, there is no consistency. I really don't care what menus look like, or how cut-and-paste works; I just wish it was possible to pick one and stick with it.

The other efforts to provide consistency across the desktop (Gnome, KDE, whatever) all start off with the requirement of rewriting every single application to do so! What a colossal waste of time! But there is simply no other way, thanks to the legacy of X: thanks to X's refusal to dictate policy, there is no one policy to replace, there are dozens.

configuration mostly

[Roundeye]

I have no problems with X once it is up and
running. The X server idea with the server
running close to the client is highly useful,
as well as removing the window manager from
the server (as opposed to the options on most
prevalent systems).

Configuration does seem to be the problem
area with X -- especially now that XFree86
has become so popular. Our local NLUG just
had an hour-long lecture devoted to X
configuration (and many of the listeners were
the Linux Literate).

If X could be made to be more readily
configurable (which is not an X issue per se...)
by better configuration tools than currently
exist -- hell, even fetching specs from
www.xfree86.org automatically given a known
card name/chipset would dramatically ease
installation in most cases (most users don't
know where to look and most tools guess horribly
wrong about what numbers go with what cards) --
then X would be more usable by more people.

Another issue is security. Most X installations
are grossly insecure. A secure X distribution
(one that installs more securely by default)
would be a nice touch.

I don't, however, see any competing protocol which
offers anywhere near the utility of X.

My Biggest Problems with X

[Jordy]

1) To develop for X you have to be an X Consortium member which costs about $50k/year to do any real work. This is why so much work is being done on layers above X, because no one can actually submit the kind of radical modifications to X that are needed to bring it into the 90's.

2) The X consortium maintains full control over X itself... meaning they can (and have at least once) change the licensing to kill off any free implementations such as xfree86.

3) The software is extremely dated with over a decade of backwards compatibility which no one even uses any more bloating the code base.

4) C... Object Oriented environment.. please. I'm sure a lot of people will bash this, but writing GUI programs in an OO language is simply easier. And before you start on the OO toolkits out there, read the next point.

5) Of course there are C++ and Java toolkits out there, but until they are standard within X, it's a big war. I have roughly 15 X toolkits on my machine to run a total of 8 programs and a window manager. Doesn't anyone else think this is silly?

6) Sluggish. I have AccelX and I have to admit the entire experience is still very slow. Netscape flickers gray every time I scroll up and down, windows take ages to redraw when switching between them, etc. I multiboot to Windows and don't have any of these problems, everything is quite snappy... even if it crashes every 8 hours :)

7) Inconsistant. With all the toolkits out there, it is so very hard to get a nice consistant desktop. I wouldn't even claim that Windows is consistant, but it is pretty close. MacOS is better.. but at least both environments are intuitive.

Once you understand the basics, you can switch between different applications and automatically pickup that the scisors in the toolbar means cut or that the file menu will have an 'exit' entry or even that ctrl-c will copy the selected text (most of the time at least :)

Of course, I am biased on this subject...

--

Berlin

[Jordy]

Berlin is a new windowing system for Unix systems designed to replace the aging X Window System. Berlin is currently released under LGPL and is developed using an open development model. We are sponsored in part by SPI who also sponsors the Debian and GNOME projects.

Berlin operates on the object level. All GUI components (widgets), applications, and non-visual components such as audio components, are CORBA accessible components. This means they are network transparent, platform independent, and language independent.

To do things like displaying an application run on a server on your local workstation (the way X does), we abstracted 2D and 3D APIs as much as possible, we also implemented commonly used functions in the display server to reduce the network traffic as much as possible.

If you are familiar with how ActiveX components in Windows work, this should be a very familiar model. All communication between components, applications and Berlin is done via CORBA using the OmniORB2 CORBA ORB (which is recognized as the fastest CORBA implementation out there).

Because we use CORBA, any language with CORBA bindings will be usable for writing Berlin applications and components. These include C, C++, Perl, Java, Python and much more.

We adopted a paradigm similar to the classic Model-View-Controller so that the look of individual components such as buttons is not directly tied to it's interface and can be swapped out easily and painlessly. New components that ship with applications, and indeed the applications themselves, can be used freely by other applications extending the reusability of code to the extreme.

A lot of Berlin's design was taken from Fresco, the competing toolkit to Motif. Fresco is still one of the most advanced toolkits out there and it's influences can be seen in several newer toolkits such as Java's JFC.

Instead of implementing our own video drivers in userspace as X does, our backend currently uses Mesa an OpenGL implementation, but can be replaced without much work. Current versions of Mesa can use a wide variety of video drivers from the integrated drivers in the Linux kernel to X itself.

Overall, we hope to provide all the power we can to developers while ending the excessive desire to create new toolkits in order to add a single widget or modify an existing one.

--