Slashdot Mirror
X Windows Must Die!
Kernel Sanders writes: "I frankly don't see much light at the end of the tunnel. X is too deeply embedded in the Unix world to be easily dislodged, and the lack of a GUI standard on the platform doesn't appear likely to be resolved. Maybe the embedded space can offer some salvation -- programmers will *have* to forgo X to run on smaller devices, and perhaps this will be the wedge that gets X out of all our lives."
Ummm ... GTK+ has such a layer. It's called GDK.
The GDK library provides a layer of abstraction that sits between GTK+ widgets and applications and the underlying windowing system. Instead of making calls directly to the X window system, applications call GDK when they need to draw to the screen or handle events.
This extra layer of abstraction provides several advantages. First, it increase portability. Porting GTK+ (and hence, to a large part, GNOME) to another windowing system reduces to porting the GDK layer. A port to Microsoft Windows has already been done. Also, it allows GTK+ programs to transparently use a number of X extensions that may or may not be present. If they are not present, GDK provides substitute functionality in terms of standard X calls. Finally, in many cases, the GDK calls are simpler than the corresponding X calls. Some rarely used parameters are omitted and the correct values for other parameters are determined automatically.
----
Celebrate the finer things in life
I program embedded systems. We are switching our Os from vxWorks to linux, because linux has some features we need. (We are accually doing a hybred, some processors will still use vxWorks, where they do real time processing, but those that just control the box are going to linux.
X is a big advantage to us, and the biggest part of it is remote display. We don't have a display of any sort on the machine, nor a keyboard. If we want to run a program it has to display across the network. I can log into whichever processor I need, start a xgdb session back to my desk and debug. Sure there is remote debugging in gdb, but that doesn't work so nicely.
I think you will find more embedded systems devoplers going to X because is allows them to remotly display debugging back to the desktop. There are free implimentations of X, and plenty of libraries and expirence working with it. Drop that into the box, and once it works anyone can use it.
There are a LOT more things wrong with X fonts than just the lack of the ability to anti-alias (which is really just eye-candy).
... yay, bloat)
The problem with X is that you can't really get anything but glyph bitmaps from the fonts. Even when you're using a scalable font -- it still rasterizes the glyph at the requested size and then sends you a monochrome bitmap.
You can't get kerning info, you can't get unicode mapping tables, you can't get various other glyph metrics; the list goes on and on.
No arbitrary linear transformations of glyphs either -- at least not unless you want to do it yourself after-the-fact on a low-resolution monochrome bitmap.
Okay, let's say you request a glyph bitmap much larger than you actually need, so you can transform/antialias it and then scale down (this is what The GIMP does, for example).
Whoops. Most X font servers crap out above a certain glyph size. (last I tried, XFree86's did)
I'm a graphic designer and a programmer; I know what I need from a font subsystem to do more than simply display some text, and I know X's font subsystem would have to be replaced for me to get it from X.
(and note that thanks to the existing design, the replacement would have to be incompatible, or you'd have to implement both the old and new protocols, duplicating a lot of code
DNA just wants to be free...
About fifteen years ago, Sun pulled a classic move akin to the blunder Apple made in not licensing the MacOS. Sun had a beautiful system called "NeWS" (for "Networked Windowing System"). It used PostScript for the basic rendering model, but added interaction, threads (!), object-oriented programming, and networking. Windows were defined by PostScript clipping paths, which meant you could have a window shaped like a text string if you wanted (years before X added the Shape extension). It was more powerful than Display PostScript (which, I think, came along a little later), and like the Berlin Project, widgets could be run server-side. You'd send PostScript code (which could contain objects, threads, etc.) down a socket, and the server would execute it. Like eXene, which runs under Concurrent ML, you could, conceptually, at least, make an object in its own thread that was a widget. No callbacks - just a while (1) loop (well, a tail-recursvie function in eXene - CML is functional).
But Sun wanted to keep full control of NeWS to itself (just like with Java nowadays). It pissed off so many people in the community that everybody else got together behind X, knowing full well that X was much worse. As it was once explained to me by Andy van Dam, the industry settled on a steam locomotive because Sun didn't want to share their bullet train.
NeWS of course died a slow and lingering death. For a while, it was included as an extension to Sun's Openwin X server. It was fun - you could scribble all over the root window with PostScript with a couple of lines of code. Eventually, I think Sun dropped NeWS entirely because no one used it.
An old story.....
-----
Klactovedestene!
There you go: the X windows disasater
/. as well. Just get him started on the topic. :)
Possible the greatest work of literature ever written about X. Guaranteed to entertain you for several minutes at least. I think he hangs around
Really, it's solid stuff. Think about it, instead of having a knee-jerk reaction.
w/m
X is highly polished and efficient distributed graphics protocol. Berlin is based on CORBA - the most awkward and bloated programming interface known to man - go to www.omg.org and research it for yourself. Especially read about the sub-optimal IIOP on-the-wire marshalling for basic data types. But what am I thinking? Of course you won't. You just like to spout tired old cliches.
Why oh why oh why do so many people harp on here on slashdot that X is 'bad'? Do you even understand the issues? Have you even ever tried comparing X with other windowing systems? Do you have any idea of the design goals of X?
In short, do the people who post "X sucks let get rid of it!" to threads like this have ANY feckin' clue?
"It's slow - lets get rid of it!!!":
Is it really slow? Seems fast enough to me, and I started out with X11R6 on Sparcstation 1's. Perhaps you are confusing X with XFree86?
Also, most other windowing systems have a huge advantage over X, ie they are called as library or system functions, whereas X was designed as a PROTOCOL for network transparency. This has an impact on speed but only slight, and if the X client and server are running on the same host there is no reason why they can't communicate via shared memory or some other X extension (see below). However X has something that these procedure call window systems don't: SEAMLESS network transparency. If I show you my desktop you have absolutely no way to tell which windows are running locally and which are running on various other machines round here.
"It's bloated! lets get rid of it!":
What is bloated exactly? X the protocol is a very lean protocol (though very chatty), designed with extensibility and low-latency connections in mind. ie if you can't do it with X, then go write an EXTENSION. Implementations are a different story, but again X != XFree86. (though XF4 is a different story - leaner and faster).
If the implementation you use is bloated go use a different one. Have a look at handhelds.org they're working on a small footprint X server for handhelds.
"Xlib/Xt suck!! let's get rid of X!":
Then don't use Xlib or Xt! Use Qt or GTK+.
"X sucks for fonts. let's get rid of it!":
Firstly, I bet you havn't read the X-Font-Deuglification HOWTO. Go to linuxdoc.org/HOWTO and read it and find out how to make all those sites like microsoft.com, dabs.com, etc, look right under netscape. Don't blame X cause it wasn't setup right! Blame your Vendor.
Secondly, X apparently won't handle anti-aliasing of fonts as it stands now. ("So let's get rid of it!"). HOWEVER do you know why anti-aliasing of fonts was invented? Cause in the mists of time, a lot of computers had terrible resolution screens. Anti-aliasing is a HACK to make fonts look better, nowadays we nearly all have at least 100dpi displays so you are better off setting X up CORRECTLY and getting clear fonts without anti-aliasing.
Thirdly, if there truly is a problem with font handling in X, well then let's do something about this small problem. Either implement an extension (Display Postscript springs to mind - most commercial Unices have this), or else fix X if needs be so that X11R7 has even better font handling.
In Summary:
X is one of the most amazing software concepts ever! It's like Unix, a timeless classic.
- If it can't do something, extend it!
- If it has a limitation, then get it fixed for the next major release of the X protocol!
but please stop the silly misinformed whinging and whineing.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
There IS a lot of R&D going on right now, but you're not seeing it, because R&D is rarely ever at a level to be used by consumers, even the high level consumers that many slashdoters are.
Eros:
http://www.eros-os.org/
MIT Exokernel Operating System
http://www.pdos.lcs.mit.edu/exo/
HURD(for its experiments in translators)
http://www.gnu.org/software/hurd/hurd.html
and a billion and one other OS projects. While many of these do not provide much, there ideas and ideals (and often bastards there of) are often incorporated into more frequently used OSs.
For innovation on the other fronts check out:
Freenet
http://freenet.sourceforge.net/
Berlin (for combining a lot of good ideas)
http://berlin.sourceforge.net/
GiNaC (algebraic extensions to C++)
http://www.ginac.de/
LyX (What you see is what you Mean editor)
http://www.lyx.org/
There is a ton of innovating software out there, all developed in open source. It's just you don't see giant leaps forward in computer science and gui interfacing. But then, you never do anyway! Innovation is a gradual process, and takes a LOT of time. But it is out there, you just have to start looking
A lot of times, people will look around on their desktop and say, "Gee, nothing here looks new." But that's 1) Because you've been sitting there i front of that desktop for who-knows-how-long(oh god, that's not 5.0 is it?!). When's the last time you installed something new? And 2) Because vendors try to plop down in front of you an interface that is intuitive. And what is intuitive in gui's? Almost always it is something you're already familiar with(almost nothing is truly intuitive). So you get the same-old same-old in front of you.
So get out there and look for something already! Find something you think is cool and work on it, or start working on your own idea. Even if it doesn't succeed, its ideas can probably be passed on to something that will.
X was such a deeply ingrained part of most applications that we just couldn't do it until now! It took the community a number of years to develop a rich, fully featured set of toolkits to sit on top of X that didn't require any sort of programmer knowledge of the X system.
There are still a number of Unix apps we use that are purely X-based. Look at some of the eye-candy apps that come with any default install of Linux.
GTK+ and KDE are becoming the new toolkits of choice for Unix GUI programmers. As we have to rely less and less on X-tied programs, we can get closer and closer to dumping this beast.
Any new system would probably need to be able to run an X emulation layer at some point. The cool thing about keeping X around this long is that we've learned a great deal about how to optimize gfx operations under Unix - we can use all of this information later to build ourselves a top-notch windowing system. Even X is running pretty fast right now. If we trimmed it down and got it running direct to an API on the system, we'd blow Win32 GUI stuff away.
æeee!
I personally don't see that as "worse." I see that as giving users the choice of desktop managers. Motif is beautiful, and i can put up with Gnome. I used to run KDE and it was tolerable. The thing is, at the root, X is X and all your binaries will run on any of them. The way i look at it, you even GET to pick what your desktop looks like.
Basically, the impression i got from from this article is that ol' Monty wants to run Windows 95 on Unix! he wants a standard DE and i have to stand up and disagree. And if you still don't like X, run lynx and vi. that's the beauty of the *nixes. You don't HAVE to do anything you don't want to. That's why i like it, and that's why i use it.
-Superb0wl
-Superb0wl
It's not that I'm lazy....it's that I just don't care.
Well, X may not be the best thing out there (in fact, it pretty much sucks for a lot of things..) I've heard about things like Display Postscript and NeWS, and perhaps development should be refocused on rebuilding them and similar projects.
There is a Display Ghostscript project, and many people have heard about the Berlin project. I've watched Berlin a bit, and I'm not sure it's going in a direction I like (they seem to only want one widget toolkit, which is both good and bad).
Obviously, for any of these projects to take off as projects independent of X (right now, they are often used as a layer on top of X), framebuffer support in the Linux kernel must be improved. Therefore, before we go off trying to re-write the world, a good foundation of security and stability must be built into the kernel.
I know many people don't like the idea of having graphics in the kernel, though this can be worked around by having modules that merely open a pathway to the video registers and memory and grant you safe access to the hardware (i.e., no more suid-root graphics systems).
Blah, I'm beginning to ramble (plus I really need to get some work done...)
--
Ski-U-Mah!
Stop the MPAA
X windows:
Accept any substitute.
If it's broke, don't fix it.
If it ain't broke, fix it.
Form follows malfunction.
The Cutting Edge of Obsolescence.
The trailing edge of software technology.
Armageddon never looked so good.
Japan's secret weapon.
You'll envy the dead.
Making the world safe for competing window systems.
Let it get in YOUR way.
The problem for your problem.
If it starts working, we'll fix it. Pronto.
It could be worse, but it'll take time.
Simplicity made complex.
The greatest productivity aid since typhoid.
Flakey and built to stay that way.
X is running on a Compaq iPaq.
Don't piss off The Angry Economist
Well, the reason why X Window is so deeply rooted in the UNIX world is that, to quote one of my friends, "There are no fucking attractive alternatives!". I agree that X is a nightmare and should be killed off by a better competitor, but there is no better competitor.
And BTW, X has plenty of problems but user interface inconsistency is not one of them. X is low-level and user interface standards are clearly not in its domain. The fact that, say, a middle mouse click can do anything at all in an X application is not a drawback of X -- it's a side effect of the UNIX world being fragmented, idiosyncratic, and, yes, free to do whatever one wants.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
While X-windows might be slow and could use some optimizations, there is one thing that puts it way ahead of Windows and Mac GUIs: Remote Display.
I would never go from X to a hyper-accelerated GUI which only provides local display, and have to use third-party programs to display remotely! Have you ever tried to do serious work over VNC or PCAnywhere? (Hint: It's _dog_ slow.) And some of us still have to use slow lines from time to time, thankyouverymuch.
(Q3A isn't very slow using XF86 && glX either, now is it?)
Now I've seen many good points on here, and I've come to one conclusion. Why don't we make a 100% free, 100% original GUI system for Linux?
Sure, it would be a large project, but if you want something done right, you gotta do it yourself. So, let's organize a group to start working on something like this. Maybe even have sub-groups working to port X toolkits over to our new system. (I think this would be possible) Then anyone who wanted to could port their applications over to this, without having to worry about much at all.
Is anyone interested in this? Let's start a project, and do this. The time is ripe for something like this. This is your chance to make a big difference in the Linux or Opensource community. I think I may even register a sourceforge project. If anyone's interested, write me email.
Sure, QNX is lighter then linux. It wasn't designed to be like linux either. Linux does more for the programer then QNX. Now for embedded systems (which QNX wants to play) this is bad, but for a general purpose OS, or server OS this is good.
The parts of X that make it slow are also the parts I use day to day. The machine I'm typing on now has a slow CPU (68030 if I remember right), but I don't care because the programing I'm typing into is running on a 300mhz sparc (maybe faster I don't know) Desptie sharing the sparc 10 other users all my programs run fast enough, and the boss finds one good machine to be cheeper then 10 cheaper not as good machines. I like not having a fan on my desk.
Perhaps we should start blasting telnet for being slower then sitting at the console.
I've only twice seen situations where X was slow. The first was when running my sun3, which has a slow X because of the slow framebuffer. The other was when running across a 14.4 dial-up. (Needs to further explinnation, though it could be speeded up, graphcis still take a lot of time to transfer at that speed)
Bloat is not a valid arguement, at least not where you site Fred Brooks. For thsoe who don't remember, Fred Brooks was the leader of a project that turned out something an order of magnatude more bloated then anything else. I know folks today who swear at unix because OS/390 is so much better. (I have no expirence with OS/390, but I know it is a direct decendant of what Fred Brooks did) The point, bloat isn't to be aimed for, but you need to balance features with bloat. Each time you add a feature you add a few lines of code. Sometimes it isn't worth it, and sometimes you should step back and find a better way, but in the end you cannot get a full functioned program without many lines of code.
Bloat is not a problem if the programed is well designed. Each person knows their part, and how it fits in with the whole. I don't know what George and Suzie are doing, but when they completely re-write their part of the code from scratch (to make it better) I don't care because in the well designed program it doesn't affect me.
* checks *
You're right. ~14 years, modulo some preliminary work. Sorry.
The problem is not the X protocol, nor its extensibility.
It's the extensions.
Most of the core X extensions and related protocols (the ICCCM stuff is really the worst offender by far, followed by the font stuff) are incredibly poorly designed, and not themselves particularly extensible.
Try discarding all the existing extensions and then rewriting them properly, on top of the existing X protocol. Assuming you did it right (and with 14 years of experience to refer to, it'll be easier), you'll end up with a very nice, clean, extensible system.
The only problem is, at that point, you either have to take all the old extensions back, or you may as well not bother calling it X, because it won't be compatible with anything.
Otherwise, you may as well just redo the X protocol a bit to fix the couple (minor) deficiencies it has... and... hrm... if you're going to be doing that, why not just scrap it completely and redesign from the ground up anyway?
It should, of course, be extensible.
Extensibility is a very good thing, but, like customizability, if it has to be used too much, then there's something fundamentally wrong with your original design (in this case, primarily the core extensions).
DNA just wants to be free...
I believe the licencing issues you have mentioned are as of now, moot. Apple stated that the original reason that it could not continue with its Yellow Box system (a system that allowed almost any OpenStep program to be simply recompiled, and run on Windows) was because of licencing fees/issues from Adobe.
As I understand it, PS and PDF are very different beasts when it comes to licencing from Adobe. I do not know the details, but I believe it is quite possible to write a proper PDF display system without any help or fees from Adobe. I believe this goes for the name "PDF", as well, which anyone can use, whereas "PostScript" requires a licence from Adobe if you wish to use the name.
As far as OpenGL, there are no licencing issues there that haven't already been dealt with in the UNIX world. Just call it something other than OpenGL, like hmm... for example, MesaGL. You get the idea.
Once Apple releases some more documentation on their Display PDF system, it may become practical to re-engineer it. Apple may, in fact, support it in some way. I wouldn't expect them to give away ALL the crown jewels, but it WOULD be in their best interest if the rest of the world used system at least half-way to Aqua to make it fairly easy to port between the two systems.
Here's an article entitled the X-Windows Disaster written by Don Hopkins.
Anyone who reads this article may be inclined to yell FUD, FUD, FUD as has been written in comments to this article or MSFT supporter but not in this case.
Don Box is a migrant user interface designer and graphics programmer. Don received a BSCS degree from the University of Maryland while working as a researcher at the Human Computer Interaction Lab. Don has worked at UniPress Software, Sun Microsystems, the Turing Institute, Carnegie Mellon University, Kaleida Labs, and Interval Research. He ported SimCity to NeWS and X11 for DUX Software.
X-Windows has serious problems that are evident to anyone who has ever done any serious investigation but since it's *nix most people put up with it's clunkiness. Similar to how an alternative to GNU getopt(3c) has not been written yet, because getopt works well enough (or so people think).
--
The componentization of the window manager was in the abstract a good idea, but the execution (ICCCM) was an abortion. You say that X wouldn't have survived as long without it. But if X had died because it was stuck with one bad window manager, then we wouldn't be in this dead end prediciment that we're stuck with today!
X should have been designed to self destruct. Like shareware that expires after a few months. I wish somebody would patent X11, and sue everyone who tries to use it. Where are SGI's lawyers when we need them?
The ICCCM window manager protocol is like an emergency tracheotomy performed with a rusty crowbar, that's been inflamed and oozing infected pus for the last decade. ICCCM is the scab on a stigmata that will never heal. But people keep trying to fix the problem by enlarging the hole in the neck and sticking tubes down it! Isn't it about time to just cut the head off and bury the body?
There's nothing clean nor extensible about the X protocol, and to make such a statement ignores reality and history, and promulgates bad taste. NeWS had an truly extensible protocol that allowed clients to dynamically download code to the server at run time. X extensions just don't cut it. You could just as well call Perl a clean simple well designed language with an easy to learn syntax, if you're going to distort the facts so grossly.
-Don
Take a look and feel free: http://www.PieMenu.com
Why is X so large? It's the server, mostly. It has to respond to a number of basic operations, in a way that makes sense when you realize that the xterm that you have on your window may have originated on the same system, a Linux system on a local network, or even an RS/6000 at work.
X is a protocol that allows a number of different workstations to interoperate. That RS/6000 xterm will react to my window manager in the same way that a local xterm will. No surprises.
A program that uses the X libraries and the Intrinsics (Xt) toolkit can usually be recompiled on any other system with X Window support, and run as is. If the program uses GNOME, KDE, Motif, or any other set of libraries that run on top of X, the only requirement is that those libraries must also be installed. But the program runs the same on all of those systems where those libraries are installed.
Is X a large program? Certainly. It could have been designed differently and work well on a single architecture. A window manager could have been integrated into it. Hell, add a file manager with tree-views. Microsoft took this tack, but if you write a program using the Windows libraries, they will only work on Intel boxes (or maybe Alphas, prior to Windows 2000).
X offers configurability. Not generally very easy, but it is there. Don't like the fact that your window manager binds CTRL-F4 to "Window Close?" Change the parameters and restart your window manager. How easy is that on Windows?
X allows you to separate the fact that you wish to draw a circle from the actual act of rendering that circle. Send a graphics request to a display, and the display will figure out how to draw that circle. It doesn't matter that the program may be running on a different machine than where the display is. It works.
If you are running NT, try opening a DOS command prompt on your neighbor's box, with the commands appearing on your box. You can probably purchase a special utility to do this (and install it on both boxes), but that capability is not built into Windows. On X, all you have to do is to be able to authorize myself via the network (rlogin, rstart, ssh, xauth). Voila!
X reigns supreme when you wish to work on multiple computers, but don't want to hop around from keyboard to keyboard. It was developed for such a collaborative environment, and is machine neutral (works on Intel, Motorola, Alpha, HP, and many other chip sets), network neutral (it works with DECNet, TCP/IP, and Unix sockets), workstation neutral (just need an X server for the computer(s) you wish to work on), and operating system neutral (you can get X servers for Unix, Linux, Windows, Macintosh, and a lot more).
Do you wish for better graphics support in X? Well, if you have an anti-aliasing library that will render fonts better IN A MACHINE-NEUTRAL WAY, then donate code to the Open Group to perform the function and everybody wins! Bitstream offered their Speedo font technology for font scaling. Others have donated other technologies. XFree86 has done wonders with having it work on microcomputers.
It's open source. Add what you think is missing. Yes. This will make it even bigger, of course.
Smaller isn't always better. I can remove X Window from my Linux system, and have a character-oriented prompt. Doesn't take up much disk or memory space as X, but it doesn't offer me as much flexibility.
(void) lar3ry();
--
"May I have ten thousand marbles, please?"
One of the biggest problems I see is that the current generation of X GUI programmers don't understand where X came from. They are most likely using Gtk+ or Qt and don't know the first thing about X resources, app-defaults, and the other things that made X customizable and useful.
If there ever is a replacement for X, I hope it's done by people with the engineering know-how as those who made X. Look at it. It's survived and remained useful for around 20 years. It's been ported to platforms the original programmers never even imagined (handhelds, Windows, you name it).
For any system to last that long (X, TCP/IP, ethernet) it has to have been well designed and designed to be used in cases the original designers might not have imagined.
That's my rant... I like X. It works very well for me.
Hmmm ... the GUI in MacOS X is a fantastic technical accomplishment, but it wasn't created overnight. It stems from NeXTSTEP, which used a native GUI because X was not ready for the real world when NeXT needed it to be.
The trouble is that the MacOS X GUI relies on technology licensed from a number of sources: OpenGL from SGI and Display PostScript from Adobe. Open sourced alternatives are available, although GNUStep's Display GhostScript is a shadow of what it would need to be to provide a viable alternative to it's commercial brethren.
So the question is, given that Linux and the *BSD's have the basis of a GUI as good as Aqua in the form of X, where should development be expended? Should it go on creating a semi-clone of OpenSTEP/Aqua in the form of GNUStep, or on providing alternatives in X itself. I think we would be better served by XFree86 developers pursuing anti-aliased fonts, etc. in the existing X framework - the game of catch-up is far easier here than in trying to reverse engineer the Aqua GUI to a greater or lesser extent.
(And does anyone know if Aqua is network transparent like X? I've never used NeXTSTEP or OpenSTEP so I'd be keen to know).
Chris
Unfortunately, this particular baby's grown into an immense, slimy, tentacled beast that's strangling the development of graphical technology on Unix.
I would like to note that I don't agree with some of the criticisms in the article -- for example, I think the componentization of the Window manager and various other items is generally a Good Thing. X wouldn't have survived as long as it has if something like the 80s-era window managers were part of the standard server.
While X has a lot of good points (network transparency, platform independence, flexibility in window management), those doesn't make up for its defects. It IS possible to design systems with these characteristics that don't have the downsides that X does.
The underlying X protocol is incredibly clean and extensible, but there are now so many (effectively mandatory) extensions that the code required to support them makes the X server software absolutely huge. ICCCM is a nightmare in its own right.
Moreover, many of these extensions/auxiliary protocols (a prime example would be the X font system) were not designed in the same forward-looking manner as the basic X protocol, meaning that it is necessary to replace, rather than enhance them. However, since existing software still relies on the old extensions, it's not possible to drop them -- you end up with even more redundant code bloat.
X doesn't really give you any choice with regard to widget toolkits, either. You're stuck with the one the app was compiled with, or, more often, coded soley against.
With an architecture like Berlin (or a number of others), it's possible replace the widget set in any or all all apps with the one of your choice -- on the fly.
There's also the problem that EVERY primitive operation in X requires the request to be marshalled/demarshalled across process boundaries.
The address space separation (and consequent easy network transparency) between client and server is not a bad thing, IMO, as it helps stability, but I belive the X designers made a fundamental mistake when they cut the client/server boundary at such a low level.
Having to do this sort of low-level chatting across process boundaries really hurts performance.
Architectures like Berlin maintain the client/server separation, but cut down on the performance hit by communicating at a significanty higher level of abstraction. This means a decently-written Berlin app, even if using a chunky protocol like IIOP, would create significantly less IPC traffic (in bytes) than the equivalent X app.
Of course X has DGA. X has shared memory. Unfortunately, those only work locally. If you rely on them, you just shot network transparency. Whoops.
And, there's another problem: instead of writing graphics drivers independent of any one application class or GUI architecture (which means basic kernel support), everyone's been writing drivers directly for the X server. (Thanks, XFree86!)
This means that to even reach a usable stage, every non-X project has to rewrite their own driver suite from scratch (as a rule, X drivers make too many assumptions about X for the code to be readily reusable for other things).
Although we have fbcon now, fbcon is pretty much unaccelerated, and doesn't have that broad a range of hardware coverage. Berlin is still mostly tested on top of X as a result.
If you have to keep X around to run Berlin, or face severely reduced hardware support, then what's the point?
X has been repeatedly marginalizing other graphical efforts this same way. (Who here has heard of Y Windows, for example? How many of you know someone who uses it? What hardware does it support?)
Thankfully, due to GGI, Berlin can run on fbcon and KGI -- if KGI ever becomes more widespread, Berlin might finally be able to break free of X.
It's time we stopped relying on the X server for everything graphical.
It's too late to throw out the bathwater, baby or no. It's outgrown the bathtub and eaten your dog.
It's time to break out the napalm...
DNA just wants to be free...