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."
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.
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
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 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
Lemme see. To summarize, X is the "greatest graphical platform that I've ever seen" because:
- Aqua doesn't have the flexibility, user base and developer base of X. (huh?)
- It's the only thing that runs on Linux. I've no choice. ("I can't install them on my Linux and FreeBSD boxes at home.")
- No one has managed to do better (on Unix, that is) ("Sure, there are a bunch of things that could be improved on X but I don't see any other initiatives out there that is even remotely close to accomplish what X has done. ")
Wonderfully convincing.
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.
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).
--
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.
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...