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."
The astounding thing about X is how much code it needs to do almost nothing. Window management is up to a window manager. Hardware specific code is up to a device driver. Gadgets and such are up to higher-level libraries like Qt. Standard GUI niceties are left up to desktop environments, like KDE and Gnome.
The truth is that it takes very little code to do what X does. One of the most minimal windows managers for X, Blackbox, is approximately 12,000 lines of C++ (the author likes to give a line count). Think about that. 12,000 lines of code to simply act as an interface between you an X in a very minimal way. You could write an entire GUI, including hardware-specific code, in 12,000 lines. Maybe it wouldn't be KDE, but it shows how far off base we've become. Don't believe it? here is a functioning GUI, which doesn't use any external libraries for graphics, done in a few kilobytes of object code.
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 can't speak for Qt, but GTK+ is not built on X. It's built on gdk, and GTK+ apps will run on any platform that gdk does. Yes, gdk was originally built on X, but it has since been ported to Win32 and BeOS, and work is underway porting it to Microwindows/Nano-X.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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.
They can come up with such negative comments on it because they don't really understand it or the ideas behind it and also the idea of choice and being able to use what you like and not to be constrained to one persons idea of how something should be done.
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 has some...unpleastness, but it's also incredibly flexible and useful. Remote display absolutely ROCKS. Window manager independence makes be drool. Widget choice makes me horny. Etc.
I'm not saying we should keep the problems as some kind of testament to the good features--I'm saying let's not throw out the baby with the bathwater.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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.
http://www.berlin-consortium.org/
Still unstable, but getting there!
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
While some of the political issues you mentioned were factors in the community's decision to go with X, there were technical issues as well. It's been so long that I don't remember all of them, but some that come to mind are
There were plenty of great features in NeWS, and some of them are enjoying a comeback today. But it's worth remembering that NeWS wasn't a clear-cut technical win. X carried the day for a variety of reasons.
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
The X-Windows Disaster
What happens to XCalc when you resize it too many times?
Official Notice, Post Immediately!
The ICCCM Sucks
jojo on UI
Motif Angst Page
XBugTool Horror Stories
-Don
Take a look and feel free: http://www.PieMenu.com
XFree86 has already addressed the Bad Thing in two different ways - with DGA (much faster) and GLX. GLX is the future of X display - clients draw into an OpenGL accelerated window (woo hoo!).
Who wants to start porting gdk to GLX?
Ah, so you want a completely new system that forces every program to adhere to the same interface and everything will look the same, despite the users wishes. Now, I'm sure there's an OS out there already that does that...
Okay, X may have a few problems. But I happen to like the fact that interfaces can be different. I like the choice of different toolkits. What would be very cool is if some of these toolkits played nice together.
Maybe if there was some kind of keybinding database that these toolkits use by default, so that paste is always ctrl-v, for example, whichever toolkit and program you use. That would eliminate a lot of the problems. Surely this wouldn't be *that* hard to implement. Anyone like to comment?
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.
Until people move to languages and methodologies that emphasize runtime safety, runtime type information, and component based programming, these problems aren't going to get fixed. In fact, that's the real point of the UNIX Hater's Handbook.
Of course, people try to use dynamic loading in XFree86, the Linux kernel, and Microsoft Software. In fact, MS COM probably represents the best attempt at doing this kind of thing, but without language support, it is ultimately too complex to be really useful. Plan 9 has a different take on modular software composition, but they have not demonstrated that it scales (Plan 9 is pretty simplistic, IMO), and it pays for the use of C in a lot of context switches.
As long as the mainstream of free software writes in C/C++, this simply isn't going to change. Any new attempt is just going to get as bloated and complex as the previous systems when it hits the real world.
But as far as 1970's style, C/C++ systems go, X11/Linux is the best there is, and I'll continue using it until I see anything better come along.
These comments are the most interesting I've seen all day (talking about X and going out to see X-Men, any way, back to the point). Granted there are some inconsistencies in what old Monty has posted (i.e regarding QNX and Linux in the same light, although Linux is built to be more capable for programming, QNX is to be smaller and faster and not nearly as powerful...), Mr. Manely does have a point, the *someone* needs to come up with a leaner more effiecient GUI for the times, an X on steroids, if you will.
:-)
A good adjustment will be somthing provided that has what we all love:
a) Remote display capabilities
b) The guarantee that an xterm on my system will behave the same as an xterm on my boyfriend's system when I'm trying to get something done @ his place.
c) Configurability
d) *Thats all I could think of right now*.
I'm quite disappointed that we didn't take this opportunity, when someone has pointed out that this aspect of *nix is dying, to talk about the new, the more innovative and skillfull approach to creating a GUI in general. Now that we have better monitors, more memory, more developers getting excited about contributing to their community...more of everything... Since we couldn't do that, after such a simple article, I wonder what this means....?
To kill X doesn't mean we get rid of the good stuff, it simply means we improve.
Nuff Respec'
DeICQLady
7D3 CPE
Sample paragraph:
"Well, I hate to burst your bubble, folks: Linux (and even the FreeBSD to a lesser extent) is just as overweight as most other operating systems these days. The kernel alone (when compiled), can take up anywhere from 700K to 1.2MB, depending on the configuration and whether drivers are compiled in. The GNU C library is likewise huge, nearly twice the size of the comparable BSD C library."
1) 700K - 1.2MB is "just as overweight as most other operating systems"? I challenge ANYONE to run Windows95/98/NT/2K, any non-free Unix or MacOS with less. Yeah "most of that is DLLs/Systemware"--so? If the OS requires it it's part of the OS.
2) Bloat IS bad in a piece of software--but libraries are a whole different beast. It isn't a "piece of software"--it's a library of software that's largely non-interdependent. Larger libraries generally means more available subroutines--but the subs don't call themselves so the bloat isn't a maintenance nightmare.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Apple will have solved this problem in the next several months. OS X will have a great GUI, based on stnadards such as OpenGL, XML, and PDF technology. While this is not an open source solution, that doesn't make it a bad one.
Once upon a time the world took the GUI que from Apple Computer. Look what it did for M$. Give a little time and the Unix community can do the same with OS X. Whatever Apple does will be adaptable and maybe will give the community a few hints on what to do next.
To the statement that no original GUI work has really been done in X-Windows, I say this...re-inventing the wheel is great, but why not refine it to make it do what you want? Building iff of other people's ideas id how we humans got here, so why snub people for it.
The problem is that X (and unix in general) don't provide a smooth learning curve. For *normal* *users* it should be easy and intuitive to start doing basic stuff, and one should gradually be able to perform more complicated and powerful things as they learn. The problem with windows and the mac is that they have such a shallow learning curve, that there really *isn't* all that much powerful you can gradully learn to do. The problem with *nix is that the learning "curve" is actually a mile high cliff face on a plateau, which must first be entirely scaled before you can do anything, simple or complicated. It's this curve, or learning cliff, that offputs a lot of newbies. Smooth the curve. Nobody is saying DON'T allow people to do complicated things, but at least have some sort of interface so that a new user sees a facade in which they can get simple things done without having to immediately be exposed to and have to assimilate a lot of complexity.
The cliff might be useful in keeping newbies away but if you *want* to attract normal users you have to make that cliff into a decent slope.
It's 10 PM. Do you know if you're un-American?
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.
How could I perform this feat? Easy, really:
- Exclude ALL non-essential kernel options
- Compile in all essential options in, so module code isn't needed
- Recompile X with no debugging, and -O2 to minimize space. Shred the symbol tables, too. And only compile in the stuff needed by GGI
- Use GGI and EvStack for all graphics, and use the GGI X server. Better still, dump X and use Berlin.
- There are some -great- lightweight window managers out there, now. A WM doesn't really need to take a gazillion bytes.
- A browser is easy. Again, plenty of lightweight ones around. That really isn't any big deal.
- Shells! (Ooops, no, that's Pernese.) Shells are no big deal. You're talking about a 3-line program, which reads a line, then sends that to system(). Wow, this is going to take space.
Then, all you need to is remove all symbol tables, dynamically link ANY code used more than once, and statically link everything else.Oh, and minimise the number of directories. Those just waste space. You don't need them, except for organising thoughts. Also use a minimal filing system - inefficiencies there chew up disk space like nothing else. (You could stuff a 20 meg application in the dead space of most HD's.)
Last, if the gap is minimal, use 1-sector/track floppies. Then you don't have the inter-sector gap, which should give you about 1-2K per track extra.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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...
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).
--
He goes on to complain about window managers being broken away from X. COME ON! Modularizing code into small components is only a good thing. God knows we don't want to end up with a windowing system that is basically unchanged (except for the applications and the window chrome) since 1984.
I don't agree with ALL the criticism, but X must DIE - soon. A new graphics architecture (with a legacy plugin for handling old school X apps) is needed.
Gee Wiz graphics after he mentions FVWM in the paragraph before???? I think Apple's focus groups must have included my grandmother, chimps and those people who operate their computer by blowing into a straw. YUK! Every "serious" computer user I know hates the MacOS. Granted: They don't attempt to appeal to serious users.
I do think he's right. Big Linux Vendors: create a project to make the next generation windowing system with all those nifty features. Don't forget to invite the BSD folks.
If we really want X replaced, we have to deliver something a lot better than X has now in order to justify the trouble to developers and users to make the switch. Simply being "just as good" won't cut it. Perhaps Berlin will be worthy when it's finished, but we're not quite there yet.
Ita erat quando hic adveni.
Link here.
This is being developed for the embedded market. OTOH it also has development environments running under X. Therefore anyone who wants can develop real applications to microwindows, and let people run it on whatever graphical system they want...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
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.
X was developed in the MIT environment, which at the time consisted of big servers, pathetically underpowered workstations (no local storage, <=8 bits per pixel), and 10Mbit Ethernet everywhere. Thus, the architecture of X presumes that most of the computing power resides on the central servers, and the servers and clients will be able to communicate at high speed.
In the modern Internet, with massively overloaded servers, workstations capable of running Quake and Unreal Tournament, and dial-up modem connections, each of these assumptions turns out to be exactly wrong.
(You could even view the Web as an attempt to address the same problem -- distributed computing with a graphical interface -- and one far better adapted to existing environment than X.)
Widget sets should reside on the client side (I'm using "client" and "server" in the conventional sense here, not the inverted X usage). The application on the server shouldn't have to say, "draw a rectangle here with these dimensions, with this text here with these fonts, etc...", followed by events and drawing instrucitons traversing the net as the user drags the mouse. It should just say, "here's the menu description, don't bother me again until the user chooses something from it."
If that approach had been adpoted, we wouldn't have distinct Motif apps and KDE apps and GNOME apps. We'd just have X apps, rendered as Motif or KDE or GNOME (or Win32 or Aqua or AfterStep or...), depending on how your workstation is configured. And we'd be deploying these apps across the (low-bandwidth) Internet, not just across (high-bandwidth) LANs.
"I've never seen anything fill a vacuum so quickly and still suck."
--Rob Pike on X
Seriously, it seems that he doesn't understand the underlying flexibility of X - that the display and application can be in separate locations.
This is something that the Windows world lacks. So PC-Anywhere et al allow remote control, but these are limited to one simultaneous controlling user. (Ever tried to remotely connect to a NT box to run some admin utility that can only be controlled from the console, only to find that someone else is controlling some other application at the same time).
A window manager is a matter of choice - you don't even need one if only running one application under X. I currently run fvwm2, mainly to the small footprint and a cronic lack of disk space. I could be running sawmill/sawfish this weekend (he didn't mention that one), or maybe try the latest CVS snapshot of enlightenment.
His other main criticism was on the size of the code. The QNX installation he quoted is a very basic environment, I believe only using basic VESA modes with no acceleration. Yes it fits on a floppy, but then I ran Gem/DOS 3.2 from a single 360K floppy 11 years ago. X (and the Linux kernel itself) is certainly more complex in nature than the QNX demo software (which is only a demo after all, and not a fully featured OS).
Oh, and he got the name wrong - there's no such thing as X Windows. I have an instant distrust of journalists who get the name of software wrong - it never bodes well on the content of their articles.
Don't criticise what you can't understand!
Some alternatives to X11 that I've come across:
D11 - Proposed replacement for X11 (from 1995), but I don't think it made it past the idea/proposal stage.
Berlin - Under development, "Latest News: June 12, 2000: 0.2 is out".
See also: Berlin page at Sourceforge
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...