@matthewg42:

Wasn't QT4 X independent? So KDE needs no porting. The other DE's won't be needing any porting because KDE is useful enough to replace them for that time beeing: we just need a workable Z window system.

For as far as just another layer goes you are right, but Z itself will get faster than X. So _if_ Z gets adopted and X gets left behind we will get rid of that extra layer and some more.

Sure it would take a lot of work but it would be fun. It all depends on how the Z architecture will look like. I don't know anything about hybrids but maybe Z and X could be hybridized? When one wants to use X he can without a performance penalty and if he wants to use Z he will get a faster system. This could cut a lot of work and bridge the gap.

Instead of creating Z from scratch we could also take the latest X and modify it heavily, remove some and add some. Throw it all in the blender and see what we can make with existing code.

The only email address on their website is dead. I cannot contact them.

Applications written for QT do not need to know about the underlying graphics system, but QT itself must be implemented in terms of some underlying windowing system. You could implement it as direct calls to specific video cards if you liked, but then you'd have to write a QT driver for every card/chipset. The next step up is the framebuffer, or you'd have to implement your own hardware abstraction later which would itself have to have drivers for each card/chipset.

Point taken - "native Z apps" would not incur this extra layer and might be faster than X apps running directly in X (if this Z system is actually faster). The rest - all the legacy X apps would incur this penalty. The problem is that there are so many apps already written for X that for the foreseeable future "the rest" would be nearly everything.

Your previous comments suggest that you think X is designed wrong from the ground up, and you said you thought it would be faster to start from scratch... If you really think X is that bad, I don't understand why you would want to fork it... except that you might be conceding that it's not worth abandoning entirely.

This is a problem for every radically different technology. For that matter, backwards compatibility is one reason Microsoft hasn't started from scratch. They know their system is flawed, but breaking backwards compatibility would cripple their business model. Apple did it when they put together OS X. But their business was already in the toilet...

There's a similar issue right now with the init system. Ubuntu developers have created a new system, called upstart, but they had to keep a compatibility layer until everyone starts adopting it...

Agreed.

The decision to try something new must be made by balancing the advantages with the pain. In the case of X it would mean a lot of pain: Implementing new graphics drivers for all those different video cards... and persuading the closed-source driver makers to spend time on your project... porting all the useful GUI frameworks... making a backwards compatible X layer... Designing and implementing a good API for your native aps... and on and on.

And on the plus side, you feel better that it is not X.

Frankly it doesn't seem worth it unless there is something which is a "must have" feature, which is simply impossible with X. "It's messy to configure multiple-monitor support", and the other gripes don't justify the effort. Not for me anyhow.

I obviously created the wrong impression. My bad. What I meant is that when the architecture of Z is designed one could look at X's code and see what code can be cut&paste into Z with modifying. What could also happen is that one learns how X actually works by looking at the code and see how one could make it's own implementation (EDIT: read specification) with this knowledge. I prefer the second option.

Hi, Vincent.

I came across this thread by accident and registered just so I could post a reply.

The X Window System has been around for twenty-three years, and I've been using it for twenty of them. I spent two of my earliest X-using years developing a program called XTV, which was the first successful attempt at allowing multiple remote clients to view and operate an application running on a single system without special hardware or software. I've had the MIT reference implementation of the X server and Xlib apart and back together more times than I can count.

I thought you might appreciate some perspective on your top five list from someone who's had a chance to watch X and the hardware it runs on evolve over time.

If you strip it down to what's actually X, there are exactly three layers: the client (your application), the server (which carries out the client's requests, such as drawing a line between two points in a window) and the network between them. If you're running a client on the same machine as the server, the network isn't even a factor since the library uses a native IPC mechanism. All of the stacks of libraries you see used on the client side (Xlib, Xt, widget sets, etc.) are conveniences so developers with applications to write don't have to keep reinventing the basic building blocks.

You can, of course, write a single program that directly manipulates a local frame buffer and achieves much better performance than you can wring out of a comparable X application running locally. But in doing so, you've developed a one-trick pony that has none of the benefits that have made X the success it is: multiple applications, remote clients, device-independence and portability. To paraphrase something George Santayana once said: those who do not understand X are condemned to reinvent it -- poorly.

Perhaps not, but there are lots of other uses for it. There hasn't been a day this week when I haven't run an X application remotely and had it display on my desk. Many times, it's usually just so I don't have to sit at a console in a loud laboratory, but sometimes it's just because my phone rang at 3:00 on the morning, I need to run something and don't want to drive an hour to be in the office. And sometimes it's on a machine halfway around the world.

What you're complaining about isn't a facet of X itself, it's a facet of the implementation you're running. There's a very critical difference. X is just a display protocol that defines how clients make requests of the server and how the server responds to them or provides data about events such as key presses. On the client side, you can toss Xlib out the window and replace it with something completely different, write lots of applications for your new library and they'll run just fine on any server that properly implements the protocol. Similarly, you can write a completely new server from the ground up, and clients will run just fine if the protocol is handled correctly.

Modern X (or at least the current X.Org implementation) has become so modular and so configurable that needing to rebuild it from scratch is a very rare occasion. I've done just fine with pre-built X for a long time and haven't done a build since maybe 1994.

In any case, don't knock it 'til you've tried it. X.Org doesn't appear to have made significant changes to the build process since I was last up to my waist in it; it still looks like you can unpack the source and do a "make World" from the top. Sure, there's a lot going on, but X isn't Hello, World, it's a large, complex product. The innards are very well organized, though.

Old is not necessarily a bad thing. Humanity is based on old technology, too, but you don't hear people clamoring for a rewrite.

X11, the basic protocol, hasn't changed in 20 years because it gets the job done. The current X.Org implementation is the product of two decades' worth of being beaten on and refined in its predecessors (MIT X, X386, XFree86 and others). The code is very stable and well-behaved, which is a sign of maturity. There's almost no benefit in doing a ground-up rebuild of a mature product using some other technology. I notice, for example, that there are one or two server implementations in Java and that neither is being used to run X on desktops.


Anyway, I hope that sheds some light on a few things.

--Mark

Why? The vast majority using X runs both the server and the client locally. Why not have one layer that can take care of what the X server and X client can do together and make another layer that will only be consulted when running over a network? This doesn't make any sense (probably only for the devs of X and that's probably why it is implemented this way.). It is not easier and only creates complexity.

Also, you say that applications written for Xlib, Xt and widget sets would still work across new releases of X, right? This would make it insanely easy to create backwards compatibility Library compatibility...

That success you are talking about is only due to the fact that there hasn't been a single alternative to it. And I don't want a local for X, because I want to get rid of X as a whole.

So you are saying that that is only possible with X and _nobody_ out of 6 billion human being can make a networked alternative?

Yeah well it is coming straight from X.org itself. If I am complaining about a project that has over 15 years of development and still doesn't work well then I can only conclude that X is a huge mistake.

Xlib is the only thing that is actually worth keeping if one would create Z.

Yes X is not "Hello world", but impossible is nothing.

I am sure WOlfenstein3D's code is still up to the memory management that fits today's needs... So old _can_ actually mean it's bad. It is when it is on a low level and X is just that.

That's untrue. There's been SVGAlib, direct framebuffer apps, Y-windows, WHY (which you yourself pointed out), and others too. The fact is that there have been many attempts to replace X, and all have failed to provide enough benefit to justify the disruption.

You miss the point which Blrfl makes, and which I made before. The pivotal word is necessarily. You asserted that X is bad because it is old, which is a non-sequitur fallacy.

Sure you can find examples of bad code which is old, but it does not follow that if code is old therefore it is bad.

@matthewg42:

Yes there have been alternatives _after_ X has been developped for lots of years. SVGAlib brakes compatibility with X and is implemented _in_ X itself. I don't count that as a alternative and it is a bad alternative because nothing built on X can run on it. Y-windows and WHY came _much_ later and got abandonded so there has never been a complete 'product' release.

Well look at it this way:
Old low level software is designed for close interaction with the hardware from that time. When hardware evolves and the software that accesses hardware does not then I considder it bad. Wouldn't you?

I guess it depends on what kind of code can turn bad when it gets old. You are right though that not all old code can automatically mean it turns bad over time.

I don't think so - I think it uses BIOS calls to the video hardware to draw stuff. No X has to be running, in fact I seem to recall that it was a pain in the backside to run SVGAlib apps if X was running.
Well, welcome to the reality in which we live. If you'd like to develop an alternative and have it introduced at the same time as X, good luck building a time machine.

So what was the point of your original post? Do you want to explore the alternatives of just whine about X?

Why would you use wine ? Only because many developers don't support Windows. Well, this is not really X problem.

In fact, since there are much more Window developers than X developers, we can expect that generally the quality of Windows products will be higher than the quality of similar products for Linux and X. And indeed, I find winamp much better than xmms, armarok or kafeine. Also Ktorrent can be hardly compared with uTorrent, even though Ktorrent provides all features of uTorrent. But again these are not Microsoft products. WM player and IE really suck, and so are other Microsoft apps.

Comparing X to Windows. I like the fact that X doesn't force switching to GUI. You can still run linux console (which is much stronger than your beloved MS DOS), and get all access to all periferals, network, etc, while in Windows effectively buried console mode.

And if you ever programmed in Windows you will find that it really really sucks, especially with .NET. In X it's much easier even without libraries like gtk or qt.

Why would you use wine ? Only because many developers don't support Windows. Well, this is not really X problem.

In fact, since there are much more Window developers than X developers, we can expect that generally the quality of Windows products will be higher than the quality of similar products for Linux and X. And indeed, I find winamp much better than xmms, armarok or kafeine. Also Ktorrent can be hardly compared with uTorrent, even though Ktorrent provides all features of uTorrent. But again these are not Microsoft products. WM player and IE really suck, and so are other Microsoft apps.

Comparing X to Windows. I like the fact that X doesn't force switching to GUI. You can still run linux console (which is much stronger than MS DOS), and get all access to all periferals, network, etc, while in Windows effectively buried console mode.

And if you ever programmed in Windows you will find that it really really sucks, especially with .NET. In X it's much easier even without libraries like gtk or qt.

That wasn't my point. I meant that X never got a alternative in it's first years. That was the reason for this succes. My point isn't wanting to have a alternative for X in it's early years.

Well I was hoping to find alternatives for X and compare them to X to see if they could be valuable alternatives for me. They clearly aren't there. It's not exactly my point to whine about X. I want to discuss X here and by that I would like to see how a different X would look like just out of curiosity. Just so that if I ever am going to be programming software for anything POSIX I could make this my project. It has a huge possibility of failure but I think it would be fun anyways. This thread is also teaching me somethings about X. I am not here to 'just flame X' because I could do that on Microsoft forums .

(One huge reply to several posts coming... Go grab a drink!)

You talk about having the ability to run a client across the network as if it were some big, elaborate chunk of code that adds a huge amount of complexity. It isn't.

Examine the code that gets executed by XOpenDisplay() and you'll discover that all it does is make a decision about whether or not it should talk to a local socket or open a connection to another host and acts accordingly. The end result of either operation is a file descriptor. Once that file descriptor is in hand, all Xlib (or any other application) has to do to communicate with the server is write to it and read from it. Even that bit of code is isolated enough that the rest of Xlib has no idea whether the server is on the same machine or the other side of the planet or even what mechanism is being used to transport the data. In fact, Xlib can be built to work on TCP/IP or DECnet, and adding any other streaming protocol is a trivial effort. You can even port the entire thing to a non-POSIX environment and only a very small amount of code will have to be re-written.

What you're forgetting here is that "X" refers to the protocol, not the implementation. That's a semantic nit, but it's an important one.

The fact is that if I were to dig up the Sun 3/50 I was using 20 years ago and put it on my network, every X application on it would display just fine on the X.Org server running my Linux box. Why? Because X11 hasn't changed since the day it was released (September 15, 1987). Conversely, if I were to fire up the X server on that crusty, dusty beast, I could run almost anything in the other direction. I say almost because the major changes to X over the last 20 years have come in the form of extensions. The base protocol remains the same and fully compatible. A program needing, say, the GLX extension to render OpenGL (with network transparency as the rest of X, I might add) obviously won't work on 1987-vintage software because OpenGL didn't even exist until 1992.

That is so incorrect that I don't know where to begin. There were scads of other window systems around during the timeframe that X was introduced. Off the top of my head, there were SunView, NeWS, NeXTStep, MacOS, Windows 1.0, Xerox Star, GEM, Intuition, GEOS and DESQview. The only survivors of that lot are NeXTStep (which lives on as part of the current version of MacOS) and Windows, which now looks very little like it did in its early versions in terms of appearance or API. If you search the academic literature of that time, you'll find there were many, many more that never made it our of the lab.

X was not the first windowing system in history, and while it will probably last a very long time, I doubt it will be the last.


Incorrect. SVGAlib is a library that is capable of doing a tiny fraction of what X can do, using an SVGA card as a frame buffer. It has absolutely nothing in common with X. Matthewg42's comments are spot on. I'm not familiar enough with the details for SVGAlib to say for sure, but it would, in theory, be possible to implement an X server using SVGAlib. It would also be possible to build an SVGAlib replacement that would render to a window on an X server.

Well, you're welcome to do that, but I expect a promise. You can't come back here and tell use you've developed a window system that squeezes out an infinitesimal bit of extra performance out of your system and then turn around and complain that developers aren't lining up to to port their applications to it.

If you think you can develop something that improves on the status quo, then stop posting complaints on message boards and for God's sake do it. Two guys named Bob Scheifler and Jim Gettys once had an idea for a better window system. Put their names into Google and let me know what they did with that idea and how it turned out.

Once again, you are complaining about an implementation of X, not X itself. X.Org is a non-profit, and its job is to be the steward of the X protocol and provide one reference implementation to be used as guidance on how an X server should behave. As early as 1989, a number of the people on the original development team at MIT were getting a big laugh out of the fact that their implementation was in such wide use. They figured others would do their own implementations, but I think people realized that more people working to improve a single implementation would be of more benefit all the way around.

Next time you board a Boeing 777, stop and admire the display panels on the flight deck and throughout the plane. The crew doesn't know it, but those panels are all running X servers. They don't run MIT X, they run a server called Metro X, which was developed by a private company called Metro Link. There were a handful of companies who developed X servers that were better than the reference implementation in one way or another. All of them are out of business because the reference implementation has become good enough for just about every implementation. Metro Link's product was was better in some ways, and they went on to contribute a huge amount of time and code, much of which made significant changes in the reference implementation's architecture. I forget what release of XF86included it, but I remember being very pleased with the changes that took place. We owe the people from Metro Link a huge debt of gratitude for their generosity.

Why (no pun intended) do you think that might be?

That isn't a reflection on Windows or X, it's a reflection on the developer of the application. Applications written for either environment can fall anywhere in the good/crappy spectrum.

That being the case, let me suggest a change in your approach. Don't come out and telling us the X is flawed, horrible, kicks puppies and eats young children. Discuss in very specific terms what you think the problems are and ask others what they think should have been done differently. Put it all together and decide if the upheaval that would be caused by changing window systems is worth the benefits that developing and deploying something new would provide. X has been around for so long with so little competition because nothing else has passed that test. Dennis Ritchie used to say something about one of his creations that applies equally to X: "C is quirky, flawed, and an enormous success."

I hesitate to make this personal, but you come across like a college sophomore who's got few semesters of CS classes under his belt and thinks he's ready to change the world. (In the name of full disclosure, I fell into that category at one point myself.) I've worked with people from all over the world, so it may just be the language/cultural barrier at work here.

Anyway, I think there's now a greasy spot on the floor where the dead horse was beaten. I've said pretty much everything I can on the subject, so unless someone has a specific question, I'm going to sit back and read whatever follows.

--Mark

@Blrfl:

Ok that's good. I didn't knew it went that way.

X refers only to the protocol you say. Can you tell me what the specification and the implementation is called (X, X11, X?r?.?, X.Org/XFree86?)

You say that you can still interact with a very old version of the X implementation. It is nice that the implementation doesn't break compatibility with older versions but the protocol has nothing to do with local hardware interaction code, or am I wrong? I have a question about that BTW: is hardware interaction different when I run GLX?

That's all closed source. How can that compete on a open source bias?

Then why are you so against a replacement for it? How would you design it if you were to create a new X that isn't X?

First of all I want to get rid of X on my own pc. I am not saying I wish other people got rid of it. Use what you love, right? That's Linux. Secondly: I am not expecting anyone to port anything. It's not like I demand it. I would however like it. Z would need to be backwards compatible with X (EDIT:-'s most widely used implementatiin).

Hey! I don't like that 'status quo'! It's about software not "Hey I have more money and power than you therefore I am teh_1337". I could say I'm going to do it but I don't have enough knowledge yet. I am not going to promise the world just to be delivering shit afterwards. And what's wrong with dreaming and fantasising?

I don't know what happened to Y but I know now why WHY was abandoned; they wanted to built their software on top of SDL. No wonder that project is dead; SDL runs on Xlib (not that Xlib sucks but they were building it on top of X while they wanted to replace it XD)

Did I said I was going to pull out my magic wand and make it all happen?