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."
Smaller and cheaper than the iPaq?? With 32MB ram and 16MB flash??
-russ
Don't piss off The Angry Economist
... to quote one of my friends, "There are no fucking attractive alternatives!"
Well, there IS NeWS. ("KNEE-wiss", not "news") Or at least there was. Built on Display Postscript. Nothing in the standard window management defined in terms of pixels (so the screen resolution didn't foul you up).
Big complaint is that, while it had a lot of handy capabilities it was somewhat slower than X. That was a decade ago, when processors were a LOT slower, AND NeWS didn't cache fonts. But that was then.
With today's processors the differential in speed might not be a problem. Either would "snap". And NeWS should be an ideal vehicle for taking maximum advantage of graphics accellerators, which might make it pass X.
(Or at least I THINK it would be good. I haven't been into the guts of it.)
Grasshopper Group (Gillmore, Henson, Daniels, in no particular order) did a quite workable one for the Apple Macintosh running A/UX about a decade back. When Apple wouldn't let developers know who was using A/UX OR forward mailings, they cut a deal with Sun to do an X/NeWS merged system. Which Sun then dropped, but wouldn't release the rights to their code.
Maybe, after a decade, Sun might want to reconsider and open-source it. That would provide a nice starting place.
If not, what was done once can be done again.
Name stood for "NEw Window System". Maybe it could be resurrected and renamed OlWS. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Sorry about the delay in replying - I rarely get time to check the web outside of work. But anyway, what is a 'corporate rock pig'? It simply means I pay the bills by working as a programmer, while wishing that my beloved band (killingmiranda.pair.com - sorry for the Shockwave nonsense, the guitarist did it) would get a *real* record contract ...
The pig part relates to our reputation (in the UK at least) for being alcohol fueled maniacs. This doesn't stop us selling several thousand CD's a year, or playing some quality gigs. In the last month alone we've played London twice, Leipzig in Germany and Oporto in Portugal. Fitting that in around work is a nightmare though.
Chris
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.
I think you've been taken in by buzzwords. It takes no planning for a windowing system to be able to "morph" into being able to use X Windows. Take a look at Microsoft Windows. Do you think they had X Windows or network transparency of any kind when they developed Win95? No, but there are X servers out there for Windows that will draw X apps as native Windows apps (so that they are indistinguishable from native Windows apps in terms of look and behaviour).
Personally, I think the correct approach would be for a windowing system to be completely local. That way, you can slap on a light-weight X server or whatever server if you need remote capabilities. No "morphing" required. This is what (I believe) the first incarnation of Berlin was, but unfortunately they've hopped on the remote object bandwagon.
That depends on your definition of success. The BeOS port is reportedly pretty flaky at the moment, but I'd say the Win32 port is almost there. Certainly it's usable today (it's good enough to run gimp under Win32), even if it's not yet quite as stable as the X version.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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.
No, we don't want windows. You can have themes without X.
---- ----
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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.
Why do so many people consider these to be diametric opposites? You CAN have both, you know. X is abstract. VERY abstract. And with plugins like DGI and glx, you can get direct access to hardware. Now, it still needs work, but there are ways of streamlining the pipeline giving you fast local hardware access while still giving remote displays.
"One or the other" seems like a very Windozy viewpoint.
--Elrond, Duke of URL
"This is the most fun I've had without being drenched in the blood of my enemies!"
Elrond, Duke of URL
"This is the most fun I've had without being drenched in the blood of my enemies!"-Sam&Max
Or at least, the band have played, even if you haven't
... The jobs now sorted (no more commuting for four hours a day) and the other thing seems to be moving to some kind of closure. So if you're going to be at Eurorock in Belgium for the next gig you'll witness the full five piece lineup again!
...
Yup. I've taken a couple of months out to sort out my career and a certain other matter
Unless of course Richard and Alien Dave do another impromptu electronic set in the meantime. Belle and I were barely able to contain ourselves watching Alien's two finger keyboard playing on Friday - although Richard did have to spoil the illusion by pointing out the keyboard wasn't plugged in
Chris
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!
the Win32 port is almost there
...
Time I took another look then. Until now I've had to use some god-awful Motif porting tool whenever a GUI app I've written on Unix needs to run under Windows. Being able to concentrate on the underlying code rather than the GUI would make life a lot easier. And coding in GTK+ rather than Motif would be great
Chris
Thank God for an X-less Unix environment. I mean, who wants the masses to use anything besides windoze? What better way to accomplish this than by destroying their only real way to connect to linux.
Bad spellers of the world, untie!
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!
An interesting article, yes. Considering its a part of the
... because it is in a <em>different way</em> that you should think of yourself, the user, as the client of the machine that holds all your software for you (the server). Being the client of a client of a server isn't that strange when you work in a manufacturing field, but for some reason, Comp. Sci. people have brain deficits in these ways and see normal human beings as stupid or silly.</P>
<blockquote>For some perverse reason that's better left to the imagination, X insists on calling the program running on the remote machine "the client."</blockquote>
<P>To help the author out, the server is the machine or more appropriately, software, providing a service. The client is the software needing the services. Labelling machines as clients and servers is not necessarily the 'right thing' unless you're running a large VAX machine with dumb terminals. At any rate, it seems obvious, when you understand how X was designed to work, that the software package needs a number of things to be able to work. It needs a screen to display on, and a keyboard to get input from or maybe a light pen or plastic rodent thing. It needs a font management utility and basically anything else that would help it talk to the user.</P>
<P>Putting most or all of those 'services' into a package would make it the 'server' software. Thus, X is the server and the software package is the client.</P>
<P>If you still think this is strange, you're not allowing for the possibility of multiple layers of abstraction
<P>To give credit where credit is due, the author does manage to pull out a lot of features of X that were added, naturally, as after-thoughts because the hardware didn't exist yet. That said, the 'other answers' (ahem, Windows or BeOS) don't really excite me much, and I'd be much more impressed with a ground-up redesign of X.</P>
- Michael T. Babcock (Yes, I blog)
An interesting article, yes. Considering its a part of the Unix Haters Handbook, I had a slight smile before even starting to read it. The writer's inability to understand why clients and servers are called clients and servers on X was what made me laugh first.
To help the author out, the server is the machine or more appropriately, software, providing a service. The client is the software needing the services. Labelling machines as clients and servers is not necessarily the 'right thing' unless you're running a large VAX machine with dumb terminals. At any rate, it seems obvious, when you understand how X was designed to work, that the software package needs a number of things to be able to work. It needs a screen to display on, and a keyboard to get input from or maybe a light pen or plastic rodent thing. It needs a font management utility and basically anything else that would help it talk to the user.
Putting most or all of those 'services' into a package would make it the 'server' software. Thus, X is the server and the software package is the client.
If you still think this is strange, you're not allowing for the possibility of multiple layers of abstraction ... because it is in a different way that you should think of yourself, the user, as the client of the machine that holds all your software for you (the server). Being the client of a client of a server isn't that strange when you work in a manufacturing field, but for some reason, Comp. Sci. people have brain deficits in these ways and see normal human beings as stupid or silly.
To give credit where credit is due, the author does manage to pull out a lot of features of X that were added, naturally, as after-thoughts because the hardware didn't exist yet. That said, the 'other answers' (ahem, Windows or BeOS) don't really excite me much, and I'd be much more impressed with a ground-up redesign of X.
- Michael T. Babcock (Yes, I blog)
X is not an OS. Windows and MacOS are.
X starts faster on my box, too, but Windows starts up faster than linux --> KDE.
The idea of an abstraction layer is that it's rewritten (as much as required) for each platform it provides an abstract interface to. Of course GDK would be rewritten, thats what it's for. It's primary purpose is to provide an API wherever it is ported to/written for, not to be even more legacy code that needs to be ported.
-- http://thegirlorthecar.com funny dating game for guys
X has shortcomings. Its only real strength is remote display. Nearly everything else -- drawing model, font support, speed, complexity/bloat/instability -- is NOT good.
VNC is faster than X over a slow modem. I regularly use Xvnc and a remote VNX client, because it works better. It's faster, platform-independant, and I can reconnect without losing work. If my modem hangs up, a true remote-X session kills all of may apps. Crufty.
---- ----
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
the lack of a GUI standard on the platform doesn't appear likely to be resolved.
I don't want you telling me how my windows, menus, titlebars, and desktop are arranged or operated, thank you.
UNIX is about being able to get your hands dirty and being able to design an environment that suits you. That includes what my X desktop looks like -- or how it works.
Gnome pisses me off. KDE pisses me off. The various OEM's CDEs piss me off. olwm sucks. They pretty much are all an attempt to wield the same GUI/HCI stratification and conformity that the Microsoft family of products enforces. I don't like it much there, either (though with the greater tweakability of Win98+'s GUI, my desktops are almost unusable by anyone else besides me. That's too bad for them, who shouldn't be using my computer anyway.)
X is too deeply embedded in the Unix world to be easily dislodged
Look -- you either want a strict GUI standard, or you want choice. If it's GUI standardization you're after, having more than one windowing system is just an ineffectual attempt to try and uphold your open-source cred. What is gained by having (say) five different windowing systems that all look and work the same?
My point is, if you want an alternative to X, don't complain that everything doesn't look the same. If someone does replace X, it better actually BE different, not just be made by a different person.
Keith "you can have my peculiar fvwm2 config when you pull it from my cold dead fingertips" Tyler
--
Terrorists can attack freedom, but only Congress can destroy it.
I think you've missed the point almost entirely. The GNOME and KDE folk are busy trying to gain some ground back from Windows on the usability front. This is a laudable effort to be sure but leaves all the original problems of X intact.
These aren't merely the things that it (perhaps rightly) doesn't address, like consistency of GUI. Authentication is still a prize pain. There is no mechanism for adding extensions dynamically making use of them in practice almost impossible.
Papering over a dubious API with n layers of toolkits and RAD tools is something that should be left to M$. Every time I hear yet another /. reader say something like: "that's the Unix way, it can't be improved upon - innovation, no thanks", I despair.
If a piece of software has had no real improvements in 5 years, then it's a sign that it needs a serious redesign. X is moribund: let it die in peace.
Yes. When I first installed Red Hat Linux 5.0, the biggest stumbling block for me wasn't the command line or unix "way" (I can use *nix just fine, although administration is another thing). It was X. Everything was pretty straightforward until it came to configuring the most important part of a desktop system. I had to run obscure configuration programs and scripts and provide carnal knowledge of my hardware, with the disclamer that my monitor may be destroyed, etc. I had to choose amongst myriad window managers, each with their own control key and window manipulation conventions. Basically the GUI on Linux is a trainwreck of klunky mismatched mixed up parts (or so it was at least from a user perspective).
A Linux GUI needs consistency. Repeat this. While inconsistency under the guise of "choice" is a good way to scare off newbies who are not 1337, it is just a major headache for anybody who want to *quickly* *accomplish* *tasks* without becoming intimitely familiar with the idiosynchrasies of the various parts of the GUI. Look - I may not be a super unix guru, but I'm not the dullest person either. I am a programmer, but I am *also* a user. There are times I want to wear my user hat but *not* my programmer/hacker hat. Unlike in star wars, everything good should NOT need hacking on to work well.
It's 10 PM. Do you know if you're un-American?
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.
No myth. X renders all fonts into BITMAPS, and programs use the BITMAPS. That makes, among other things, printing pretty screwed up.
---- ----
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Semantics, semantics.
Download GDK. Oh, you can't, because although it is a separate library it still forms an essential part of the GTK+ package. The fact that GTK+ hasn't been *successfully* ported to another system is proof of how many X-isms are in the GDK/GTK+ code. So my original comment is still valid, an Xlib emulation layer would still be required below GDK - or else a major rewrite of GDK.
Chris
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.
That doesn't say anything about its dependence (or lack thereof) on Xlib. The fact is that Xlib, and therefore X windows, still draws every primitive you see on the screen, whether you're running KDE, Gnome, or anything else. Gdk, GTK, and Gnome add successive levels of abstraction to form higher-level primitives, but basic commands like "draw a line" or "shade this box" all go back to Xlib. Gdk strings a whole bunch of these together to make drawing buttons & such easier, and GTK itself strings a lot of Gdk commands together to make columned lists, scrolled windows, and the like. But if you can somehow pull all that off without using Xlib, drop me a line and I'll send you a cookie. Because it's not gonna happen.
Porting gdk to other operating systems is a matter of changing from the Xlib API to whatever API Windows uses to do things like "draw a line" or "shade this box". GTK+ is "not" built on X only in the sense that it runs on better platforms, and in saying this you're not conveying the whole truth - X is your only option if you're running Unix.
--
I think there is a world market for maybe five personal web logs.
"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."
... and therin lies the problem. We've been doing this for the past 20 years, and it's starting to add up. Almost everything in X is an extension now, and the code required to support them is really adding up.
DNA just wants to be free...
I think at least half of this discussion will contain arguments about having a widget-set directly on top of the hardware. You don't want that. X is what makes us UNICS. It is network transparent. It is an abstraction layer that does not impose any look or feel. You can run Gtk or Qt or Xaw or Motif, or whatever widgetset suits you. Or build your program on bare Xlib. Yes, X may need to go awayt, but not to favor Gtk or Qt on framebuffer, but to favor another network transparent windowing system (not widget set) that features transparency, antialiased fonts and non-horizontal text.
--The knowledge that you are an idiot, is what distinguishes you from one.
--The knowledge that you are an idiot, is what distinguishes you from one.
---- ----
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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
... but GDK is still heavily tied to the X model. Porting it to some other system is not trivial, as is proved by the flakiness of the Windows port.
Mmm
Chris
Agreed. Wait and see.
So we should just keep working with it because it does remote display? No! Write a new standard that does remote display, better font support (like the article mentioned) and gets rid of tons of unneeded code.
There are a lot of things I'd love to see in a GUI system: You mentioned remote display, I'd love to see something that cuts down on the overhead (ever tried to do remote display over a modem?). Maybe some kind of two way communication where the remote system looks for the graphics binaries on the client and just sends data to update rather than data for the whole binary. (If the client has them). BTW: Windows can do remote display but it does suck, its even slower than X.
I'd also like to see some kind of standard widget set built into the server itself. (GTK would be fine with me). Its soooo incrediably annoying when I find programs that look really cool but don't run correctly (or not at all in my window manager).
I'd still like to see mulitple window managers to have different looks though. Some people need a Windows/Mac look. Personally I love BlackBox. Which as far as GUI's go I feel is pretty innovative.(and its really small. If anyone wanted to take the chalange in the article to put the GUI and kernel on a floppy, try BlackBox!)
Q3A isn't very slow using XF86 && glX either, now is it?)
I really hate to point this out but there was a benchmark at Linux Games that shows Windows beating Linux in 3d accelaration with several different cards. Personally I think this has a lot to do with X.
Never knock on Death's door:
The Anti-Blog
I would like to note that Berlin expects to have an X server component availible eventually. Obviously, you're going to have to be able to display X apps for a long time to come.
X support is a necessary evil, but that doesn't mean we should keep X as the primary desktop architecture.
Additionally, Berlin doesn't rely on any one kernel graphics architecture (or even there being one). I think right now they've got postscript, OpenGL and GGI display kits in various stages of completion. It's not really dependent on any one "Linux-specific" architecture.
Worst-case, on a commercial Unix with only an X server for graphics support, it can even display on that.
DNA just wants to be free...
No more worrying about re-draws, or where the window is on the screen in pixels.. just clean virtual co-ordinates, scaled by the windowing system at the display end. Buttons and input handled by the display and only important information sent back to the client as and when it it is needed, defined by the client's application when the object was created. Applications simple enough that in only a few lines of code an application can get a window displayed, scaled and controlled.
This is the dream of many a programmer. Instead, X is archaic, making the programmer at the application end do all the hard work, sending large pixel maps down the network every time a window is uncovered etc. all of which the display side of things should know how to control more efficiently anyway.
How many megabytes of code is written just to do the basic control of a simple window? Wouldn't it be better if all this is taken out of the application's hands, unless it asks to have that degree of control?
What's needed is a new windowing system which does all the hard work for the programmer and the application, is networked like X and gives an X api for backward compatibility.. but with the application being given it's own virtual display which is mostly managed for it by the windowing system.
This would solve three problems:
- Application complexity.
- Network bandwidth.
- Backward compatibility.
The downside would be that the display system on the computer displaying the data would have to be more capable..it would have to know how to redraw windows for it's clients, it would have to know how to scale, scroll and generally transform the windows and their contents. it would need a get deal more computing power and memory than X, in other words. The other side of the coin would be that the code would only be there once.. the applications would be FAR smaller and FAR less complex, helping with stability and speed, especially over a network.The only question is.. who is going to do the hard work and write such a system?
Agrajag: "Oh no, not again!"
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.
the X protocol is a rather heavy-weight one
...
True. This was probably a consequence of the Athena team's lack of experience in developing a networked system for windowing. A recent article I read (I regret taht I can't remember where) openly stated that some aspects of X were ill considered with hindsight. At the level of the X protocol it's probably to late in the day to do any major re-engineering. Or maybe not
Chris
Moreover, if you want to do an embedded device and don't want the X overhead, port or implement your widget set in GGI or something and don't use X.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You know I have read a lot of your arguments and I am not very sure they are well founded at all.
I have looked a lot of GTK code.. and yeah GDK is a little X centric.. but not really. I mean your GOING to have a hard time getting other ports working PERIOD.
Hello you are porting an entire graphics library to a totally new operating system, you have to account for all the nuances(read:BUGS!!!) and flaws and benefits of doing graphics rendering on that operating system
Its not pretty doing that in the Win32API which I believe accounts for much of the untidy unstable stuff. I like GTK a lot and I think that a key to success is getting something that CAN run very fast and have direct access to hardware.. Ive used the Gimp in windows and.. it works rather well if you ask me
Ive done minor work even and was not disappointed with the gimp..
The point is it is getting more stable every day and it is really a nice toolkit with a damn good design. So what if the middle layer is tied to one Platform that IMO is the point.
Tune it up take advantage of the OS's features so that once you got the middle layer working Viola the apps are ALL there and running beautiful and fast as ever. Is that not the point of the middle layer of the GDK?
Jeremy
If you think education is expensive, try ignornace
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.
"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"
But the real problem is not that we have themes that look as good as Aqua, and may in fact not have some of Aqua's shortcomings. The real gap is in the rendering. If we aim for Aqua, and neglect to also aim to duplicate Quartz, we lose.
Quartz is the real power for OS-X. It generates the OpenGL, QT and Postscript display. Aqua is just a theme, like Afterstep, Gnome, K. It's useability and power come from Quartz, X Window's real competitor.
Tom
Reality does not happen until you analyze the dots. -Don DeLillo (Underworld)
Have you even seen Mandrake? I'll be the first to admit that Linux is not for everyone, but one of the great advantages of Linux over MS is you can get a distribution tailored to your needs, and then you can tailor more precisely to your needs.
You obviously need a good visual user interface out of the box, with easy installation. So, try Mandrake. Not only does it do all the crap you want (like automounting CD's) and I don't know what the heck you're talking about "installing and icon quickly is not done". What the hell does that even mean?
BTW, if your bank had any brains at all they'd have web based banking from home on a secure server so ANYBODY can use it. That's how my bank is, and I jump back and forth between Windows, Linux, and Irix - they did such a good job it looks and works the same on all.
That is the future.
I'm sorry, I shouldn't have even answered this uninformed troll. My apologies to everyone else.
----------
Stupid sexy Flanders.
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 bloated? I really don't think so...
Checke this out
A linux distro that is about 8 MB. It includes X and networking capabilities.
If this is bloat then all the software in the world is bloated. And windows is just obese.
If at first you don't succeed, skydiving is not for you.
X is running on a Compaq iPaq.
Don't piss off The Angry Economist
Or the cut buffers....try cutting and pasting between an xterm, XEmacs, and Netscape. It's a mess.
If you're talking about the technically impared users that cannot configure anything, Gnome and KDE bloat the system to unuse. As a release to the masses system, you cannot say that the default X settings aren't slow. You could use Afterstep to cut out some of the performance loss, but you can't get rid of all of it. The article complains about trying to get a working system on a *single* floppy (with X), which i've seen easily done on 3, but the problem is not disk space and loading times. If we're trying to win over the populous that cannot program their WM, then we're competing against a 400~MB (?) default install of windows 2k. 3 floppies should be sufficient in this market.
There *is* a program I enjoy using on windows... It's called FDISK.
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.
It's time to bring a new GUI system to the world.
To some Extent, GNOME and KDE are helping to solve the problem, but IMO it's the wrong approach.
We really need a more sensible GUI system; getting an app up and running shouldn't be this difficult; sadly, all the futzing with Xresources and stuff is all too real.
One thing I think a replacement GUI toolkit needs is a standard window manager with standard widgets. This is probably the biggest barrier to most people ever accepting Unix as their desktop (even technical people where I work dislike X, because every program looks, feels, and works differently.)
Furthermore, a revised GUI system needs to recognize that today's clients are high-powered machines, not dumb monitor+keyboard+terminals. It need to let the client do most of the processing. It also needs to have working functionality for basic concepts like the clipboard (cutting and pasting between X apps is just silly....which cut buffer do I use?!?)
I hope Berlin truly improves upon the ideas presented in MSWindows/Aqua to deliver a new GUI system that is usable. Making any concessions to X for (compatibility) would be such a disappointment.
"all my friends say, you hate windows so much , you install linux, and then run X, isnt it the same thing?" people dont seem to realize the stability, remote display, easy multiple monitor support, endless array of free software, and the flexibility of X that lets you customize it to run basically however you please... none of this is available in windows, nor will it ever be.. lets see a windows box stay up for more then 7~10 days running the windows kernel and then we can compare it to linux boxes running X with uptime over a year... until then i dont see any reason for anyone to badmouth Xwin
You act as if the font system were the only area in which X doesn't meet my needs. It's not.
What's really required to fix X is that the X implementation needs to be stripped back down to the base protocol, and the extensions and auxiliary protocols rebuilt from the ground up based on the lessons learned from the past 20 years or so.
We're too late for that, though. We can't afford to jettison compatibility with X11 and its standard set of extensions; there's too much legacy out there. It'd have to be kept around in the codebase too.
I don't feel like doubling the size of the codebase for only an incremental improvement in functionality.
Assuming I had the time (or got enough people interested in the open source project), even if I only addressed the font subsystem, it'd be the same problem, only on a smaller scale.
I may as well just contribute to something to replace X, and get X11 compatibility through an X server component that didn't have to be part of the base implementation.
DNA just wants to be free...
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
Which in my opinion is something we can do better. That's why I like linux, because I think I can do it better. It's also why I hate windows - because I know I could do it better but I'll get sued if I try.
No offense.
Ctimes2
My cube. My friend. My solace. My prison.
This isn't FUD. It's worse. First of all, the article is actually chapter 7 of The Unix-Hater's Handbook. What do you expect from such a person? He is going through everything in Unix and exagerating every flaw, and then going on to claim every feature is actually a flaw, and then making up his own false flaws that never existed. Or, at least, that's what he does in this chapter. It is as if he doesn't actually know how to use unix. He quotes one e-mail from a guy who clearly had no clue what he was doing. The guy actually said that he could not fathom why someone would have to tell the X-Server who was allowed to connect to it. He wrote, "Oh, yes, you have have to run xauth... I give this ten seconds of thought: what sort of security violation is this going to help with? Can't come up with any model." Err... how about stopping other people from opening up porn on your display? He also didn't seem to get why his telnet session did not automatically know about X. Ugg. And then the author quotes the e-mail as an example of X's "security through obscurity". A little biased?
Sure, the article does cover many of X's actual weaknesses, but with all the mis-information around it, anyone who doesn't know about these problems already is not likely to be able to tell the real stuff from the lies.
------
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.
Sooner or later, Red Hat, Debian, and the other big distro players might someday agree on an ideal standard setup for a Linux GUI. I'm betting it will look a lot like Gnome/Enlightenment. If that's what the standard will be like, I say let's stick with the chaos we have now.
Information wants to be anthropomorphized.
I live in a house with several Win95 machines and several less-than-impressive computer users. My computer has the only scanner, CD burner, video capture card, etc. I find X to be absolutely invaluable to "idiot-proof" my computer. None of my family or friends want to learn a (GASP!) command-line interface. It's too complicated. They're too lazy. They still hunt-and-peck. With X, however, and (ick) fvwm2, I make it look enough LIKE win95 that they can use it. I use KDE, personally, but that can be changed for each user. The FLEXIBILITY is one of it's strongest points, and the reason that everyone uses it. If you don't *WANT* a GUI, don't USE one. I don't when I code! If you *WANT* a GUI, USE one. I play Arachnid on mine!
"I'm not even supposed to BE here today!"
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!
O.K.
let me get this straight
X ran on the Unix systems of long ago
Computer power doubles every 18 months.
Now X is too much for our desktops and embedded devices.
Did I miss something here?
X good
I like
Take a look at the Simula-67 and Algol-68 manuals (yes, those numbers refer to dates in the 20th century). Simula-67 looks not all that different from Delphi or FreePascal. Take a look at Smalltalk-80, Cedar, and the Xerox PARC workstations. Take a look at the MIT Lisp machines from the early 80's. They had powerful, easy to extend window systems, component based development, runtime safety, incremental development, and a lot of other features that even today, almost every environment lacks.
Yes, those systems had limitations and problems. But instead of fixing those problems, the whole research community and industry went on a C/C++/UNIX binge. The end result is that 20-30 years later, C/C++/X11/UNIX (and its inferior clone, Microsoft Windows) is still the only realistic choice for real systems. Alternatives like ML, Smalltalk, and Lisp aren't feasible because only a handful of people has invested any significant efforts in them over the last few decades. Java is the only effort to bring at least some of those technologies out into the mainstream, and you know what most OSS hackers seem to think about it.
The aims of the research and development community seem so low now that reinventing WYSIWYG word processing, computer algebra, or component-based software in C/C++ is considered innovation. Unless R&D starts aiming even just a little higher, things will continue to bloat and stagnate.
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)
Does anyone really want to consider developing something that has all X's strengths (and there are many) and none of its obvious weaknesses, right from scratch? I don't think so. It would take years.
What about the strengths of the other contenders? Does anyone have experience with things like, say, Berlin? Though, for a start, you certainly can't get that on one floppy :)
GROGGS: alive and well and living in
X does what it was designed to do *very* well. THe lack of conformity in Unix desktops until projects like KDE and GNome came along is an indication of how fragmented the Unix market is/was - not an indication of shortcomings in X. The CDE and Motif suffered from this fragmentation, as adjudged by their designed by committee aspects.
...
Projects like Gnome and KDE have simply given X the toolkits and desktop environents it always needed - driven by user requirements not vendor factionalism. It should come as no surprise that the successful alernatives to X (NeXTSTEP, Sunview for example) were the products of lone companies. Even OpenLook suffered once it became a 'standard' rather than an implementation - resulting in more than one toolkit
As for criticising X because it works over slow modems, well I'm thankful that it does. BEing able to ssh to a remote system on another continent and have X forwarding work is fantastic. Especially when I can do this from a dial-up at home rather than the T1 at work.
To paraphrase:
Those who don't understand X are destined to reinvent it poorly
Chris
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 the X font protocol had been designed extensibly, there's no reason it shouldn't be possible to add facilities for retrieving font metrics and so forth.
Why should outline fonts be dependent on a particular file format, anyway? Other systems manage just fine with a generalized abstraction -- there's no reason the introduction of a client/server architecture should change that.
If most X extensions were as extensible as the base protocol they were built on, there wouldn't be a problem.
By the way, what you describe is precisely what a lot of these apps that want their own font directories do.
DNA just wants to be free...
> In windows world, when a user finally figures out that alt-F4 closes a window they KNOW that no matter what box they sit down at alt-F4 will still close a window.
And any X box I sit down at here at work works identical for me. Why? Because my defaults are in my home directory, so any X I start looks at them, configures X to my preferences, then I use it like my home desktop (which it is). If you boot up X with your prefs, you get your prefs. Like alt-F4? Set it to that, and it's that everywhere. Like Alt-Q? Set it to that, and it's that everywhere.
Isn't network transparency wonderful?
Among other things, all window managers (ICCCM), and any X application that displays text.
Because we haven't replaced X yet.
DNA just wants to be free...
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.
What about pie menus?
Don't piss off The Angry Economist
I dunno, I think X is okay.
On days when I'm doing serious work, I've got 8 desktops loaded. On one I've got Netscape and an electronic calendar. On another, a CD player and control panel. On 2 others, development or analysis environments of 3 xterms and emacs. Another has xv, another has ghostview, xephem runs on yet another, and finally some game runs on the last.
Yes, there are some sucky things with X, and a better environment would help. Yet, I would find it inconvenient to do all of this from a virtual console. "screen", while powerful, isn't enough. Geez, sometimes I'll even be using screen in one or more of the devel/analysis xterms.
Once X is running, it is generally okay for me. It lets me do the things I need or want to do. To me, that's the point of using a computer. Imho, that is.
Graham
Graham
Linux - Fast Pane Relief
What player are you using? I've had really good luck of late with smpeg-gtv (smpeg is a playback lib from loki, you should be able to find it on freshmeat).
It is, however, the first player I've every found to do a decent job.
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Very little of QNX is written in assembler. The bloody thing runs on almost as many architectures as Linux, without the 50 million (exaggerated of course) coders that Linux has. Without a portable code base, that wouldn't be possible. A lot of OSs do that. For example, BeOS can fit into less than a 16 meg permanent disc (sans some features of course) its just that the code base is really small, (around 1.5 M lines) not any assembler tricks or anything (most of BeOS is C and C++)
A deep unwavering belief is a sure sign you're missing something...
Always thought it would make a comeback....
[NOT]
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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
try w3m (search on freshmeat). It's way better than lynx. It renders tables and frames.
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?"
QNX is available on... MIPS, PowerPC, and x86.
A deep unwavering belief is a sure sign you're missing something...
I love it when people throw around the fact that the system waits for the user. When I am running 3D Studio, the system is certianly NOT waiting for the user. It is busting a gut to redraw the screen. I don't want my windowing system taking up 40MB of RAM that COULD be going to my rendering package. I don't want my GUI sucking up CPU cycles that should be going to my renderer. Or if I am background rendering, I don't want the GUI to steal those cycles. Sure I could run TWM, or turn the GUI off when I'm rendering, but damn it, I'm not blind! As a graphics person I LIKE pretty pictures. I can tell you that Windows does a lot more with hardware than Linux plus X can. To get the same features as Win95, you have to run Linux + X 4.0 + KDE 1.91 (sure you could use TWM, but it doesn't have anything like COM, or embedding, or the cool features in Win95) A 486/33 will run Win95 decently, but will puke on the equivilant Linux configuration. Sure, you can pare Linux down, but why bother competing if you can't compete with an equal feature set?
A deep unwavering belief is a sure sign you're missing something...
Nobdy gives a damn about the program authors. Programmers are mere servents to the USER. That's right, the USER is the most important part of the equation. This is no way detracts from the programmer. Car makers take pride in designing cars that people like and work hard in making them easy to use. Most authors also like it when people like their work. The problem with the *nix user experiance is that it is too concerned with programmers. In the end, the power to totally customize the interface is useless. Sure, some programs can benifet from an unusual interface, but most can't. You may think your interface ideas are just peachy, but in the end, they are a pain in the ass to the user. I like the way Windows does it. Most software has a similar interface. If your software really DESERVES a unique interface (like Truespace's which works wonderfully for the package, and since it is a major application, the quirks are worth learning) then you can take the time to code it. However, most software doesn't deserve a custom interface, because the increase in efficiency is by far offset by the learning curve. Who gives a damn if my AIM client has a perfectly tuned, custom interface?
A deep unwavering belief is a sure sign you're missing something...
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.
No, this is really a problem with almost anywhere. It is not even really restricted to programming.
Not many people would choose maintaining an application over creating a new one, and the next best thing is adding features. Tracking down bugs is boring, hairy work that very likely will go unnoticed by 90% of the world.
You have an old, semi-maintained building and are given the choice: you can fix all the plumbing or build an entirely new gleaming wing; which are you really likely to choose?
This is just one of those annoying facts of life. People want to be noticed and the work that is likely to be most useful is less likely to get them any fame. No one likes to think of themselves as a cog, but without the cogs clocks don't run.
-prak
If you want really fast games, you're probably writing directly to the video memory. VNC isn't going to be able to work under those circumstances. So, having a super fast local display probably means no remote display.
Where I work, I can't live without remote display.
And while we on the subject I don't fight that stupid "say crackers not hackers" losing battle either.
See also the end of this amusing article...
on silly press releases
-----
Problematically, X does a lot of that too these days. Most of graphics laden stuff done by modern systems like Qt and GNOME often use shared memory, and in the end X ends up just pumping pixels back to the server. Of course, there would be a really easy way to prevent this all. Switch to a disjointed client/server model. For example, BeOS uses a message passing model. Client apps send requests to the display server. It is damn fast on a local machine (mainly because message passing is pretty efficient and highly optimized) and theoretically, the display server could be replaced by one that shunts the calls to a remote server over the network. Thus, you get two hops for a local system, and three for a remote one. True, the local server would have to be replaced by a remote one and the system restarted, but most remote display machines operate in one mode for a long time, so that is not really a problem.
A deep unwavering belief is a sure sign you're missing something...
You do realize what FUD actually mean, don't you? It means "Fear, Uncertainty, and Doubt" and refers to the practice of a business attempting to cast Doubt on the viability of competitor's products by instilling Uncertainty that it can compete with theirs and Fear of making the mistake of switching to a probably doomed product.
This wasn't marketing nonsense. This was pointing out several deficient features in X11. Have you ever tried to program for X11 or looked through code that does? It is a HIDEOUS beast. X11 is nothing but hack upon hack upon hack upon what once was a neat minimalist 2nd generation graphics and user event handling system with network exportability.
X is a lot like DOS in a way. It's a very minimalist system designed to meet certain limited needs on limited hardware with little or no planning for future expansion. It was really a neat little solution in its day, but it has proven to be extremely inadequate in modern environments. Creating a X11 program is all about working around the system, not working with it. It's a lot like writing code for Windows -- working around DOS via the Win32 API, not with it.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
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
what did you do 15 years ago that couldn't use some updating now?
nothing, huh?
well, maybe instead of bitching you could help XFree and PI come up with something a bit lighter.
byatch.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
So X is buggy, so it's slow and lacks features that would make it ideal. Perhaps the choice is to completely replace it with more efficient, smaller code. I completely agree with that.
The only catch is: Make it look good. I doubt very few people want to sacrifice the customization and beauty of X. I spend a lot of time getting my desktop to look great, to make people who use the boring Windoze GUI stare and wonder what I did to my computer.
People (including me) are visual, and I don't want to give up aesthetic quality I currently have in X in trade for a smaller code base.
But, hey. If we can make it look good, innovative and efficient, I'm all for it.
-- Breaking Windows: Not just for kids anymore KDE
The primary problem with X isn't that it's the worst display server man ever created. The problem is X applications which are in total chaos. There are two methods to tackle this problem: the MacOS method and the NeXT method. In MacOS the toolbox doesn't force any programmer to follow any UI guidelines whatsoever. MacOS would have been in total chaos much like X except Apple published UI guidelines, and when a programmer failed to follow them Mac consumers would let them know in every way possible, even if they put a certain command in the wrong menu. FYI: UI guidelines have absolutely nothing to do with looks, or one's theme, or application switcher or window manager. Window manager does not a UI make. In NeXT programmers used an OO framework to build their applications, so they had little choice but to follow the UI guidelines. In fact you can replace the UI with another by moving the standard menu items around or changig how text is selected etc. The difficulty with X is nobody is going to use one application framework because UNIX programmers are lazy hackers who don't give a hoot about users. Truth is most X apps looke like Windows freeware. With all the millions of X toolkits (and programmers who don't even use toolkits) I do not see any way to use the NeXT model. The community's abandonment of GNUstep just about sums that up. The only solution that I can see if to write up or adopt some guidelines like menu item placement, ICON shape (although admittedly not all mac apps folloow Apple's guidelines which state applications ought to be diamon shaped, although I wish they did), text handling (unfortunately OpenStep and MacOS are almost completely different in every way text is handled, from the way arrow keys and pgdown/pgup/home/end are used to the way text is selected and the way the cursor is positioned), standard key shortcuts (I HATE the way windows apps use up the F-keys when I prefer to program these for global use!), etc. I don't know if we can adopt Apple's guidelines since they rely on so many tools available in the OS. For example all preferences are stored in a runtime-defined directory. All files have a type and creator allowing all file ICONs to display what app and what kind of file it is at the same time. There are other file attributes like 'kind'. Plus some things like drag+drop can't be universally had without a toolbox or framework. MacOS for example supports ubiquitous drag+drop text whereby any selected text is a draggable item. This can be implemented in OpenStep, and perhaps GTK but not in X generally. I guess they can adopt Apple's guidelines and programmers will just have to adopt the subset they are able to, not that I have much confidence that they will give the effort. After all most of them behave you shoud be thankful they program to begin with, and kiss thier feet no matter what a piece of crap it is.
---
>80 column hard wrapped e-mail is not a sign of intelligent
>80 column hard wrapped e-mail is not a sign of intelligent
>life
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!
Food is not politics, and windowing is not a protocol, yet we have vegans and X.
IMO, tools like VNC obsoleted the "power" of X ages ago. 99% of the time, the X client and server are on the same system. The overhead is wasteful, and the terminology annoyingly confusing for newbies. I'm sure there would be significant performance and appearance improvements in GUI Un*x applications, especially games, if X were replaced with a standalone graphical system.
I registered my hate for Jon Katz
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
I have no opinion one way or another about X in general. I would just like everyone here to sit back and notice that this debate could and would never take place regarding any other "part" of any other "OS". See, the system *does* work! God bless the GPL and peer review.
"Reactionaries must be deprived of the right to voice their opinions; only the people have that right." - Mao
Why not start with a efficient design, and provide a X compatiblity module?
X is slow enough as it is, will running as a emulation module on top of something alot more snappy be too big a price to pay to ween ourselves off it?
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...