Fog Creek Software
Discussion Board

Developing a Replacement for "X" For Linux?

This question is posed in reference to the thread on Kylix abandonment where X itself is castigated as a terrible system.

I always get arguments from strident *nix zealots over this, but to me X always feels like a unrefined internal demo of a decent GUI that is months away from even an alpha test release. There's always something about it that is broken, that doesn't feel right... the mouse is ALWAYS annoying in X. The mouse movement and acceleration in X is always just f*cked up. A Windows using going to X typically has the sort of sensation you would get if you tried to raise your arm and your foot jerks instead. Everything's "wrong" while pretending to be "idiot happy faced right."

Another point of confusion in X is the distinction between X itself and the window manager of choice. There's TWM, there's KDE, and there's a zillion other choices.  And also a major barrier to adoption is the hassle factor in mastering the scheme(s) used in the many X window managers for things like links. I have to this date NEVER figured out how to simply set up a frikkin' shortcut in any X window manager.

This is not exactly a rant about choice. It's a rant about useless proliferation of snivelly-faced useless assed geek ways of doing things that net the end user a tower of babel of terminology.

And I'm not a Unix noob. I am quite happy and comfortable with the Unix command line. I write shell scripts, etc. and I've installed and debugged many servers to my Linux host such as mysql, qmail, etc.

It seems to me (in my naive Windows centric worldview) that someone would have over the years developed a good, solid replacement for X that implements the X programming interface and refines the behavior of the desktop, keyboard and mouse to the level of Windows.  One that replicates the relatively simple Windows desktop.

I do realize that the Win32 API is implemented as a local programming interface and X is designed to be remoted. I have read that the technical barrier is the concept of a "frame buffer" in Windows that is unavailable with X. Somehow, this explanation hasn't clicked.

So, what are the technical barriers to someone writing an X+desktop manager replacement that doesn't suck @ss? Or is this simply a matter of the will or comprehension of the problem not being there?

Bored Bystander
Sunday, November 9, 2003

there are no technical barriers. for instance, every apple computer comes with an X + window manager replacement that runs on top of unix.
read chapter 7 for historical insight as to why X sucks the way it does.

Sunday, November 9, 2003

I disagree with many of your points, but nothing of import, really. X has some significant downsides. As far as I can tell, it hasn't been replaced because no one can write something better without breaking twenty years of X application development.

And as far as the plethora of interfaces goes, I think that's a plus. That's mostly me, because I happen to have a particularly obscure (yet efficient for me) setup here, and I want to keep it. Perhaps there should be a standard WM and DE. But one shouldn't make choice difficult.

And in any case, you point out how bad things are. But did you use KDE 1.0? It was an improvement over many things out there, but in just a few years, it has come very far. I would even go as far as to say that KDE, from inception to current, has gone farther for its age than any other product. That's a bit extreme, I think, but in many cases, true.

Things *are* improving. but they are keeping the X protocol because it's hard to replace and keep it compatible. And do you really expect backwards compatibility to be abandoned?

Mike Swieton
Sunday, November 9, 2003

X uses a framebuffer.  One difference I'm aware of is that certain XFree86 functions don't use DMA to interface with the frame buffer (like it's font renderer for example), which causes it to feel so unresponsive.

A lot of it has to do with what X server you're running.  If most of your experience is with XFree86, I can understand why you'd feel that way.  Commercial X servers are often much more fluid and responsive IME.  Projects like Freedesktop and Xouvert are working towards fixing what's wrong with X and bringing it up to speed with reality.

Jim Battin
Sunday, November 9, 2003


X both sucketh, and yet it doesn't.  I'm sick today, so you'll pardon me in that I've gt nothing better to do than troll the boards... :)

Anyhoo, it is and it isn't X itself that you seem to hate so much.  It is the "desktop" that runs on top of X that you seem to despise.  For that, I highly recommend giving the Ximian Gnome 2 desktop a try.  (

I used to loathe Gnome, for all the frustrating reasons you enumerate, and more.  I used KDE for a long time - mostly because most everything was not broken the way Gnome 1.x was.

However, the Gnome 2.x desktop is very polished and very intuitive.  If you have time to screw around with it, I'd give it a try.  FYI: the windows manager du jour is "Metacity" - whatever that is.  It gets my vote.

nat ersoz
Sunday, November 9, 2003

>>read chapter 7 for historical insight as to why X sucks the way it does.

Gee, huffing aside, there is some really good reading in that article. (the stuff about drawing a IC chip on the screen, and moving it around is brilliant).

The problem it seems s not really x-windows, however, after reading the above reference, one does see much of the short-comings of x-widows. There is some brilliant insights in that chapter 7 reference, and it explains much why .net makes so much sense. I am talking about coming up with a system that allows a INTELLIGENT division between client and server and .net does this in a very good way. We are talking about com automation across the net here. What is lost n x-widows is a means to provide a very good mechanism to use the server side, and the client side processor in a proper way. We can easily argue that x-windows should not have to be part of this division process anyway!.

We do have to distinguish between applications talking to each other, and a simple network pipe to send graphics down (which is what x-windows really is anyway!).

Note that people love windows because the appcltions provide such a incredible user experience. They look great, and they perform very well indeed. Further, you might be trying to play a golf game, or move a new barbecue design around on the screen in your favorite CAD program. For this kind of stuff, you need local high speed processing, and a good graphics card! A rich high performance GUI is not going away soon!

Anyway, the real problem here seems not x-windows, but what standard the developers are going to develop their GUI to? I mean, just what library will you use to display/show/ and manage the creation of tool bars? Its the lack of a standard API that really seems to be a large part of the problem here.  From this standard follows the ability to cut and paste. It is useless to just cut and paste a bit map. You want to at least have some meta display standard that cut and paste can use, so that you can have proper application integration. I can cut and paste a Visio ER diagram into excel, and MUCH more then just a bitmap is pasted into Excel.

The original Mac was cool because it had a mouse, but it was true computer revolution that you could cut and paste between applications. Having software work with each other is far more important then just a mouse or cute GUI.

In addition, x-windows as mentioned in that article does not have a good ability to off load some of the GUI to the client when needed.

Of course, the big problem with windows was its un-ability to utilize the server side. However, that has now been addressed with .net (mostly soap stuff/web services...but still a big leap for windows developers).

What this means is that once again, any market advantage that a better x-windows design could have provided due to better connectivity has been long lost.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, November 9, 2003

BB - I am with you on this. Every six months I'll take my system and load a fresh copy of WhizBang Linux with the latest ThisAndThat WM to see if they have arrived yet. Using a WM like KDE or Gnome makes me feel like I am playing a game of Jenga - it could all collapse at any point because of all the levels and complexity of how they stack.

I have settled on Windows as my desktop system with an older FreeBSD system sitting under the desk. I can open up a CMD prompt in WinXP and telnet to the system - just like having a Terminal application in an X windows system. I consider it all the benefits of WinXP with the fun Unix toys when I need them (thank you Samba team!).

Sunday, November 9, 2003

Has some thoughts from one of the Unix haters

Sunday, November 9, 2003

I agree that X is badly in need of replacement. But there just isn't enough incentive, in terms of money or reputation, to encourage anyone to go do it. Most people would see it and say "oh, that's cool," but it's not the type of software that people would pay a lot for, nor would it really work under a community/free development model.

Dan Maas
Monday, November 10, 2003

doesn't NeXTStep^h^h^h^h^h^h^h^h OSX basically replace X? Of course, it's not for linux. But it does have a windowing system on top of a unix kernel. though they do have an X server running there too now if you need it.

Monday, November 10, 2003

X is a great illustration of the consequences of abdication of responsibility. The "mechanism not policy" mantra sounds like it releases your artistic freedom but all it's really saying is that the original designers didn't have a clue (about user interfaces; their programming skills must have been right up there).

I see similar abdication-masquerading-as-flexibility in database schema design, Mozilla, even in semiconductor design (my own personal shrine to the method, where I thought it was too hard to research user needs and designed the ultimate memory controller instead of the right one).

X is a good example of a system designed by committee. Can anybody see the JCP condemning Java to a similar fate?

(Just reviewing this, I see I haven't actually addressed the repacement possibility.) There may be a replacement for X but it will only come from a benevolent dictator. If any policy decisions are left to the masses, endless squabbling and market fracturing will result.

Don't like X? Get a Mac.

Paul Sharples
Monday, November 10, 2003

"If any policy decisions are left to the masses, endless squabbling and market fracturing will result."

Sure sounds like the OSS community or Unix as a whole

Monday, November 10, 2003

I think "abdication-masquerading-as-flexibility" reflects my feelings about X and many other Linux and OSS things the best.

IE: the Windows desktop *could* have been replaced by a third party window manager if someone were to come up with a salable improvement or if (in the OSS model) some volunteer group decided that it could build a better Windows than Windows. No such thing has ever happened (to my knowledge) with the exception of some little trinkets like HP's "Dashboard" a few years ago and the like. Everyone's Windows looks like... Windows. What a concept.

That tells me that although Windows is not "very" flexible (that is, no endless hodge podge of UI replacements in the vein of "X" windows managers), it's stable  and satisfactory for most people.

And without a desktop setup for Linux that is a "standard", that average people can get configured and running correctly, that doesn't contain 16 septillion ways of doing the same rudimentary things that everyone needs to do ... Linux on the desktop does not have a chance, and its (high) rate of adoption elsewhere is therefore pretty surprising.

Bored Bystander
Monday, November 10, 2003

> And without a desktop setup for Linux that is a "standard", that average people can get configured and running correctly, that doesn't contain 16 septillion ways of doing the same rudimentary things that everyone needs to do ... Linux on the desktop does not have a chance, and its (high) rate of adoption elsewhere is therefore pretty surprising.

I think one can agree with your premises without accepting the conclusion.

IMO, if Linux on the desktop is progressing even though the tech sucks (*), then the drivers are not technological.

The "rate of adoption elsewhere" comment I find just bizarre. Why not conclude that since Linux has gained quite a following in the server and embedded spaces, it's filling some real needs there?

* And it's getting progressively better

Monday, November 10, 2003


Some of us like it this way.  BTW, OSX for Linux is known as Darwin, and is available for any OS running X (BSD, Linux, ...).

If Linux never replaces Windows on the corporate or consumer desktop, will those who do use it care?

From what I can tell, the reason X is slow is that every Xlib function call gets marshalled across a Unix local socket (aka pipe) for the local client(s).  That is both powerful and lame all at once.  Superb for multi-user, slow as heck for the single user machine.

Monday, November 10, 2003

From Apple's website on Darwin: "Beneath the appealing, easy-to-use interface of Mac OS X is a rock-solid foundation that is engineered for stability, reliability, and performance."

One of us is misunderstanding what Darwin is. As I have read it, there is no such thing as Darwin for Linux. Darwin is a Unix-Like operating system based on the BSD flavor. Darwin is just the traditional core set of command line applications and OS. This does not a Macintosh OSX make. All the stability of a Mac, but none of the “appealing, easy-to-use interface of” one.

If X is “slow as heck for the single user”, how on earth would it be superb for the multi-user? Be honest, can you count on one hand or two, the number of times you have used a remote X session? :)

Tuesday, November 11, 2003

I use remote X sessions everyday to connect to do my homework. So that would take many more then two hands.

Phil Larson
Tuesday, November 11, 2003

I use X remote all the time.  X forwarding over SSH - very common, very useful, and very secure.  Built in.

As for OSX and Darwin - what the heck do I know, I don't actually use it, just sounded interesting.  Reading web pages and regurgitating as we go.

Tuesday, November 11, 2003

"From what I can tell, the reason X is slow is that every Xlib function call gets marshalled across a Unix local socket (aka pipe) for the local client(s)."

If you don't know, don't guess.

Or, to put it another way: where are the measurements indicating that this is slow? And slow compared to what?

Daryl Oidy
Tuesday, November 11, 2003

That would require effort on my part to investigate why X is slow.  For our project, we've already abandonned X in favor of using the linux framebuffer directly (which supplied a 2x improvement in speed).

Given that so much was the same in the X video driver implementation and the linux framebuffer implementation, I am left to speculate that it was likely the socket communication which X uses which made it slow.  It is not an estimate without basis.

But to investigate why a technology which we've abandoned is slow...  Hmmm - why don't you do it if you're so interested?

Tuesday, November 11, 2003

*  Recent Topics

*  Fog Creek Home