OSNews

First they should split of the network transparency part, I bet 90% of all X users are connected to a locally running X server at all times and those who are not are probably running their connection over a LAN so they could probably afford a less efficient protocol.

While the protocol definately has issues, what you're talking about isn't protocol dependant, but a failure of the underlying IPC mechanisms.

If they ditch the network part this would mean that all communication with the X server could run over the locally most efficient means of communication. As it is today everything runs on BSD sockets which are less then ideal when connecting to local servers on most operating systems.

And what IPC mechanism do you propose to use? Most systems have an extremely limited selection of IPC mechanisms, which are usually just pipes and sockets. Often times pipes will be implemented as sockets, thus sockets become the only IPC mechanism available.

The only other choice is SysV message queues, which are connectionless and therefore difficult to use for the purposes of a display server. Multiplexing multiple connections basically comes down to using one queue, which may lead to some issues such as any application connected to the server being able to "spoof" messages as coming from a different application. The API is also quite atrocious. The only advantage over sockets is typically increased speed.

The only real solution, in my mind, is shared memory and sockets, which is basically what X does through use of the SHM extension. The way X fails in this respect is failing to place the IPC code below the drawing library. It sits side by side with the drawing library as an extension. X also suffers from too many widget sets leading to discontiguous interface appearance and user interaction.

I'm all for scrapping X entirely and starting over with a new Quartz compatible display server built on a modified CoreFoundation using sockets/SysV shm in place of a CFMachPort in Run Loop Services. If people want backwards compatibility with X, it should be something that sits on top of the display server like rootless X does in OS X.

Of course this effort would require many, many skilled programmers who are willing to devote a great deal of time for the next few years to such a project. And this is, of course, only for writing the display server. Someone would still have to either rewrite GNUstep to make Quartz calls instead of X/DPS ones or start from scratch rebuilding the NeXT APIs. In other words due to sheer developer effort with negligable benefits, this isn't going to happen. Either to switch to OS X or be stuck with X.

Berlin is a nice toy, but I don't ever see it entering production use as an X replacement. It will always be slow due to a number of inherent design decisions.