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.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-06-29
You can't seriously, with a straight face, tell me that because they use processes and threaded messaging that Windows' and OS X's GUIs are "just like X". They are so fundamentally different in nearly every major aspect even a school child could point it out. The latency is the biggest tell-tale; there is no perceivable latency in the commercial OSes because they aren't wasting time looking for a god damn networking stack to send the commands over! From the ground up it's a different design. Yeah, there will be similarities because they all want to accomplish the same basic goal: Drawing windows and providing a workspace. However, your entire post may as well have said "a car is really just a horse drawn buggy because they both get you somewhere". Sorry for the tired car analogy but it's true.
As Thom said, when the Windows GUI backend crashes it doesn't take other processes out with it. X does. That's a flaw, and a f--king major one. I guarantee that if X were either redesigned or replaced with something that left out the legacy networking crap and went with a modern methodology we would see the same performance and stability we see on real window systems.
Member since:2009-08-17
Really you can. Windows stack, for example, has been redesigned to be a real client-server thing since NT (4.0 at least). And X really does not use the network stack when both the server and the clients are running on the same machine. As previously pointed out, it uses shared memory and/or unix sockets, which are actually exactly the same thing that Windows and Mac OS X are using for communicating between the server and clients.
There is nothing fundamentally wrong in X. It's almost the best architecture available, and (look for MS documentation in MSDN or ask ReactOS devs) others have been copying it. You really don't have to send 80's drawing commands to the server through network. On local machine nothing ever hits the net, and XRender has the same cool features as Mac OS X or Windows. And believe or not, also Mac OS X and Windows have support for commands like "draw line from x1,y1 to x2,y2".
There are, however, bad implementations, and especially bad drivers around. It is really unforgivable, that there has been bad experiences with X, but in the end it's the matter of manpower. MS has money and manpower, the graphic card makers have money and manpower. FOSS has not either.
The latency issue is not because of network or design that much, but because of bad drivers AND because of the fact that MS has the graphics drivers in the kernel, not in the user space. During the early days of NT 4.0 and W2K this was a really bad decision, but now a days MS has got it right and working really great. Also Linux is moving to this direction with KMS and Gallium etc.
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
Member since:
2007-09-08
Windows' and OS X's UI stacks have never, ever had that ability, because they never needed it.
Wrong on both counts.
First of all, the client / server model used by X is almost (but not quite) entirely invisible when you're using a local server. No networking is involved. Communications between the client and server are handled through unix sockets and shared memory. Furthermore, when using OpenGL on a local machine, the X server is used only to set up the OpenGL context - the application communicates directly with the video drivers.
There's only one problem with X, as it stands, for local connections. Oddly enough, it's a problem that's even worse for remote connections - latency. Specifically, there are a lot of operations (thanks largely to xlib) that are synchronous. An application has to send a message to the server, and then wait for a response. XCB (a replacement for xlib) pretty much fixes that, but it isn't supported by any UI toolkit just yet, and proprietary video drivers (nVidia and AMD) don't support OpenGL using XCB.
So that's not a fundamental design flaw - it's an implementation problem. And one that can be fixed. The latency problem actually has been fixed for remote connections - NX acts as a proxy, and handles some of the messages directly, rather than waiting for the remote server to respond.
The architecture used by Windows' windowing system is very similar to X. In Vista, the windowing system is just another process, like any other. Applications communicate with that process using local IPC and shared memory. Direct3D and OpenGL are handled the same way they are in X, except there's no support at all for accelerated rendering over a network link. RDP is implemented by having a different windowing server, which acts like NX - it sends some of the messages over the network link, and handles some others itself. Windows XP works the same way, except the window server resides in the kernel instead of a user process.
RDP is a fundamental, inseparable part of the Windows windowing system, so you can't really argue that X is inherently worse than Windows because network transparency is a fundamental part of X.
As for OS X... It's windowing system is implemented much like a local-only X server. It's still a separate process, and applications use sockets and shared memory to talk to it. It doesn't have a separate network protocol, so it doesn't have a fallback for when shared memory isn't available, but otherwise it's very similar to X.
The only real difference between Windows / OS X and X11 is that, in X11, the window manager is a client process that talks to the server, while the window manager equivalent in Windows and OS X is built directly into the windowing system.
Other than that, it's all a matter of implementation.
Now, the implementation of X on Linux may suck, but that doesn't mean it needs to be thrown away. Especially considering that, for any replacement to be a success, it would have to implement most of the X protocol anyway. If it didn't, there wouldn't be any applications that could run on it, so nobody would use it.