Linked by Thom Holwerda on Sat 15th Aug 2009 17:55 UTC
Over the past couple of months, and especially over the past couple of weeks, I've been working very hard to write and complete my thesis. I performed all the work on Windows 7, but now that the thesis is finally done, submitted, and accepted, I installed Ubuntu - and immediately I was reminded of why I do not do any serious work on Linux: the train wreck that is X.org.
Permalink for comment 379021
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2007-09-08
No, they really aren't.
Your central argument is that X is inherently deficient because of the network support, which is a load of crap.
Windows has the same network support that X does, and it works in very nearly the same way. X does not use the network at all when the client and server are on the same machine. In the local-only case, both Windows and X use equivalent communications mechanisms (local IPC and shared memory) to communicate with the window server.
As far as your thesis goes, how are these systems any different?
Nor is X. When running a local server, the networking system is not involved. At all. It's entirely possible to run X on a system with no networking stack at all, and it still works.
The latency occurs because Xlib is synchronous. An application tries to send a command to the X server, over whatever communications mechanism you're using (Unix domain sockets locally, network sockets remotely). Xlib then blocks, and waits for the X server to acknowledge the response. The application can not continue until the X server responds, and Xlib allows the application to continue.
Running locally, this causes problems because you're forcing the OS to put the client to sleep while it waits for a response from the server. You need three task switches to deal with a single X message. Since there's no way to batch them together, this latency ends up absolutely killing performance by causing lots of unnecessary task switches. Even on an SMP machine, the two processes are forced to take turns, rather then being able to run in parallel.
While this is stupid, it's not a fundamental problem with X itself. It's a fundamental problem with Xlib.
If you use XCB, you can send these commands asynchronously. The client can fire off a long list of commands, and let the X server get around to it whenever it's able to. Most of the time, the application doesn't care when a sequence of commands is finished, so it can just send off the commands, and either get on with something else, or go back to sleep.
Windows handles local IPC mechanisms asynchronously by default, so this problem doesn't occur on Windows.
It's an IMPLEMENTATION problem, not a design problem.
It's entirely possible to write an X server that can recover from video driver crashes in the same way that Vista can.
Following Vista's example, you could split X itself right down the middle into two processes. You have the server process, which handles incoming connections (both local, and network), keeps track of resources, and spawns the driver as a separate process. Should the driver process crash, the server process can restart it without interrupting the client connections.
No. You'd get a windowing system that nobody would use, because there are no applications available for it, and no drivers for it.
Edit: That last bit is, of course, why no replacement for X has ever been successful - any replacement has to be able to run existing applications. It's also why we're pretty much stuck with Xorg - any replacement would have to have at least equivalent driver support.
The problem is that Xorg sucks as an X implementation, for a number of reasons, and some of the lower-level bits used by most toolkits (like Xlib) also suck. At least Xorg sucks less than Xfree86 did, but that's not saying much.
Edited 2009-08-17 14:20 UTC