Slashdot Mirror
Is X The Future?
Future Linux-Guru wrote in to tell us about an essay thats running over at OS Opinion that talks about
X11s Future. Not an issue we talk about much: Sure, X solves
the problem, and in many ways, its very elegant, but is it really the
standard that we all want to be using for our GUI coding in the future? This essay argues that we should. Do you agree?
Uhh, yah...and that GUI is coming complete with its own operating system called MacOS X.
> Each of CORBA's on the wire requests has a big header which includes the name of the remote function name - in ASCII no less!
This isn't so much a problem with CORBA so much as it is with IIOP, which I'll admit is a pretty well entrenched part of CORBA. It did boggle my mind how stateless they tried to make IIOP. A real world analogy would be like doing away with pronouns. John went to the store and John bought some raspberries and John put the raspberries on John's cereal and John thought the raspberries were rather tasty. (and to top it off, you're John). Now that CORBA 3.0 has interface versioning, maybe we can say "okay you refer to function xyzfoobarbazmumbleblah as 2, ok?" I wouldnt count on it though.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Not in my experience. Motif programs that have missing or corrupt .appdefault files are totally useless (like, the buttons have no labels!). I 100% agree with the initial author that these have the same problems as the windoze registry. I have never seen a Motif appdefault file that is editable, they are just "part of the program" and have to exist, unchanged from how the author wrote them.
And even if they did work, this is a horribly user-unfriendly way to customize a program!
i don't really totally get what this article was trying to say. it seems like it could be condensed to "X 0WNZ j00!!" the only arguments i could find in it are "we ought to make an upgrade to X11" and "we shouldn't try to replace X". The idea that everyone should stick to X since 'it is standard' does make sense, but it's still kind of stupid to dismiss alternatives out-of-hand before those alternatives have actually been created. I mean, once Berlin has reached the stage of being usable then it makes sense to argue not to switch to it; but bashing a technology before it has a chance to prove itself is just kind of arrogant.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
As for the GNU project, some of what they do is possibly defensible in the name of innovation ( eg they've added useful features to many of the utilities ) but in some cases, they seem to almost willfuly break compatibilty ( eg bash which includes extra features even in "posix" mode ), which is annoying.
Fortunately, the GNU software is all free, so you can install it on anything, and it's become something of a standard ( and in some ways , a good standard ) in it's own right.
Um, exactly how do you change all these 23 applications using an entry in the .Xdefaults file? In my experience, even if every one of them is using Motif, I cannot even get the background color to change with a single line of .Xdefaults.
Real mode = 16 bit mode, which only dos runs in
Protected mode = 32 bit, Linux, windows, etc. run in this.
I guess the Vesa stuff uses video bios functions, which are only available in real mode. And Linux is *never* in real mode.
You are wrong.
1. X clients on the same machine as the X server use the shared memory extension and not translated over the wire.
2. CORBA is largely a glorified RPC hack that requires socket round-trips for each remote request (can you say slow?). Oneway calls don't help you here as they are unreliable by design - read OMG's CORBA specification. Each of CORBA's on the wire requests has a big header which includes the name of the remote function name - in ASCII no less! The longer the name of the remote function - the longer it will take to process the remote request. This cannot possibly be more efficient than a finely tuned graphics-specific protocol such as X11.
3. A CORBA call will only be native if the server code is physically linked into the client binary - either shared or staticly. This would make the process size of your CORBA clients much bigger than the current X client/X server model, and resultantly with many process - much slower.
Do your homework before you spout such nonsense.
Actually this is precisely why we reproduce.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I'd suggest that that is not the situation we're facing. The situation we're facing is more akin to a group of passengers pointing at nicely sealed portholes and saying "See - that could let water in, and if water gets in we'll sink." Meanwhile, nobody's bothered to point out that the portholes are _NOT_ leaking, and that they're as strong or stronger than when the ship was built 20 years ago. The passengers, positive that they're right, go looking for proof. They find water in the form of ballast. "My god, the ship is taking on water!" They bail the water, and in so doing, throw the ship off balance, causing its demise.
That ship called X is _not_ leaking. It's _not_ sinking. Its design lifetime is _not_ coming to a close.
Motif is not really feasible on linux because linux distributions ( unlike commercial UNIX ) do not come with run time motif licenses. Lesstif is *not* adequate. I don't know how many times I've seen some idiot report a bug for a motif app because it doesn't work properly in Lesstif. ( they really should report the bug to the Lesstif people ... ) Lesstif is NOT acceptable as a standard. We are much better off with QT ( for which we get runtime and a restricted developers license ).
I did some research, and you're right.. It's only on the INTEL platform, I stand corrected..
Open Mouth.. Insert Foot.. ECHO INTERNATIONALLY.
-- I'm the root of all that's evil, but you can call me cookie..
Seriously, how many people routinely modify the resources of their X proggies? If the programmer wants certain UI behaviors to be customizable, she should just add a "Preferences" dialog or the like... Those things are really no better than the Registry in Windoze...
.Xdefaults/resources/whatever
What happens if the Windows registry gets corrupted? Your machine's fscked, never mind your application.
What happens if a
file gets corrupted? Your application starts up with a perfactly usable set of options.
K.
-
How come there's an "open source" entry in the
-- Proud descendant of semi-nomadic cattle-herders.
Fast operation string hashing algo or not - nothing beats an int lookup as is the case with X11's protocol. You cannot dispute this.
Indeed, I cannot; nor was I trying to do so. The thing is, though, one string hashing operation can probably pull even with about fifty int lookups or so.
While one operation over IIOP is slower than one over X, Berlin aims to use much fewer of them.
There's another factor to consider, too, which I just remembered something about -- if I remember correctly (and I could in fact be very wrong on this), IIOP is only used for inter-ORB communication. Intra-ORB communication doesn't have to use IIOP, and my understanding is that it generally doesn't -- i.e. each ORB has its own more optimal protocol, with IIOP being used as a more generic "fallback" for compatibility with other ORBs. Depending on the ORB, the ORB-specific protocol may compare more favorably with lighter-weight protocols.
Does Fresco use normal blocking (non-oneway) CORBA calls (forgive my ignorance) for most of its operations? If this is the case the socket round-trip time latancy will kill your remote performance. If use use oneway calls, on the other hand you risk not delivering the request. You lose both ways.
Whoa whoa whoa... I thought we were still talking about Berlin ... the widget hierarchies and aspects of layout control were taken from Fresco, but from what I understand (I need to read up on Fresco more) Berlin modifies it a little and has an entirely different drawing model (much more like NeWS), and a somewhat lighter-weight event model. Based on my understanding of things, Berlin's guts are not that similar to Fresco at all.
As to your actual question, pretty much everything Berlin does over CORBA is two-way, to the best of my knowledge. FWIW, I'm really more of a hanger-on to the project than an architecture guy, so take my architectural statements with a grain of salt.
As for having the complete Fresco GUI lib linked dynamically via a shared lib into the client: true, the code of the shared lib is common to all processes, but the data associated with each "instance" of the shared lib is not. I concede this point is probably not much of an issue.
Yeah, that's what I meant about WSS. It's probably not large, but it is admittedly significant.
You may not believe this - but I like the idea of Fresco - it seems to be a rather elegant design. I merely disagree with its transport mechanism. Good luck with the project.
Thanks, but unless you meant that you liked the ideas which Berlin had inherited from Fresco, I think you have the wrong project in mind: Berlin != Fresco. You might be able to call it "Son of Fresco", but I'm not sure. :P
---
DNA just wants to be free...
I think a lot of people are confused about what a GUI is, and what constitutes a user interface.
X is an attempt at distributed computing (compare with Plan 9, a much more developed and sophisticated distributed computing architecture), and a primitive graphics system.
X is not a user interface -- a user interface is a command shell (and 'shell' does not necessarily imply command line). The Mac OS Finder and Windows Explorer are mature graphical shells (GNOME and KDE are still just hacks, and feature-incomplete). A graphical shell embodies a command language just as much as a textual shell is (bash, ksh, et c.)
X has no native support for user commands to the system (Mac OS and Windows have built-in scripting languages -- shells), thus it is not a command shell. It's graphical, but not a UI.
What is needed is a true graphical user interface for Unix. KDE and GNOME, as handy as they are, are incomplete band-aids sitting on top of a bloaty, slow network protocol/graphics library. So I say: Lose X! Write something new! Develop a graphical shell language and implement it on an existing graphics library.
It's a little OT, he's making a reference to Linus's comments on micro-kernels. Search dejanews for "Linus on micro kernels" , where the man himself has quite a lot to say ( but not about GUIs )
To apply you're argument to X, would be to say "XFree86 is the standard, and it's a good standard. Who needs AccelX when we have XFree86."
UNIX is not the standard, POSIX is the standard. Linux is a POSIX compliant (for the most part) Operating System. If Linux wasn't POSIX compliant, you would have a good argument, but it's probably more POSIX compliant than some actual UNIX's.
Because Linux is POSIX compliant, most software written for Unix will compile on Linux and most software written for Linux will compile on a UNIX. This is yet another reason why it's good to stick to standards. You can write a better implementation, without having to worry about porting software.
We need to replace X with a... gui that runs on the framebuffer device.
-----
:blinks.
Who says that an X-implementation can't run on a framebuffer device?
Graphics-toolkits should only need to support one medium, too: graphics.
-rozzin.
X is not a GUI. I don't know how many posts above have said this already, but its just not sinking in.
What X does is perhaps more like what people think a video driver does. Its an interface to a display. It lets you draw things etc. The job of presenting a GUI is split between a window manager and a widget set. They talk to the X server to get things displayed.
So, if you don't like the look and feel you see, its the window manager and the widget set.
If things are slow and eating memory, it could be X itself, or it could be your particular X server.
X is standard and it is just that, standard. It is incredibly difficult to set a simple standard let alone and industry wide standard that is supported by all of the *nix's. Although it can be a pain at times to code, it is so well established the any tampering could result in a mess of arguments and lack of connectivity amoung the not MS OS's. We must look to the future and keep and realize that its not the GUI that needs to be looked at but the entire OS itself.
Do you need to look up your car's enginee manual in order to shift a gear?
Linux morons: shut ya' beer hole.
Xah
xah@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
and repeat after me: "X is a shit pile."
- haters/x-windows/disaster.html
http://art.net/Studios/Hackers/Hopkins/Don/unix
Xah
xah@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
> But it is very likely that Berlin will have an X compatibility layer (it won't get any widespread adoption otherwise). Then, GTK/QT will work, and so will all the apps, then you can start porting GTK/QT to Berlin if you want, and there ya go, a group of developers don't ever notice the transition.
/once/.
/heard/ about it was Rasterman and he told me he couldn't grasp its API. Neither could I.
Meaning you get even slower and more bloated double-windowed system. At least extending X means you do things
Not that it's really needed. X has builtin image processing. Ever heard of Xie? No, not the X Input Extension, there is another one called X Image Extension. Unfortunately the only person I talked with who
The point being, why bother? X has it all. XFree86 doesn't support antialiesed font rendering, however, that has been worked on (I read somewhere that the code is currently commented out because they lack developers). And also, don't whine. If you don't like X, help XFree people to make it into what you like.
I refuse to use
That article is from the Unix-haters handbook. Sorry, but taking the advice of people who hate Unix on a fundamental level on how to improve it seems kind of stupid to me. Especially when you consider that many of the contributors aren't even Mac or Windows people but former users of antique proprietary systems that Unix killed, like TOPS-20 or Lisp Machines (forgive me, jwz, but the LispM interface makes X look intuitive and pretty by comparison).
There are certainly things about X that suck but I have yet to see a design that fixes all the mistakes but still provides the same benefits.
sorry you're wrong.
if you write an OpenGL app you don't need to know anything about DRI or GLX or whatever. The call to create the viewable is an OpenGL call. It's then up to the OpenGL library to do whatever is needed, be it using glx/dri or plain X to create the window. ie:
app opengl library screen.
OpenGL is incredibly portable for this very reason cause you do not need to worry about glx/directX/whatever - that part is handled by the library.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Do you have any proof for this? Both protocols have their advantages and disadvantages, but empirical evidence suggests ICA is slower than X, and LBX is faster than both. Certainly, both Wincenter and Terminal Server are slow as hell for me over ethernet. I'd hate to think what they'd be like over a 14.4 modem (in comparison, X over said modem is slow but usable).
"The invisible and the non-existent look very much alike." -- Delos B. McKown
dammed html..
App {- opengl functions -} OpenGL Library {- glx/dri/X11/directX/whatever -} Screen
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
I think the future is interoperability, X or otherwise. That's what the various toolkits such as GTK+ and QT can give us - an abstration from the underlying protocol.
yes my ass.
- haters/x-windows/disaster.html
http://art.net/Studios/Hackers/Hopkins/Don/unix
Xah
xah@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
hahahahahahahahahahaha!
"If you don't like Fords, help Ford make a better car!"
Screw that. We'll write our own windowing system and let X people back-port our code to their lame-ass "UI".
;)
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
We need to replace X with a media-ready, true-color-plus-alpha, image-compositing gui that runs on the framebuffer device. ATI will be releasing FB drivers for its cards... other vendors are sure to follow.
A *pretty* easy-to-configure GUI (X is NOT easy to configure) is the single most important thing Linux needs to get to the desktop.
Just imagine the glee people will have when they can run Unix and have it be a better "graphics platform" than the Mac! A better "video platform" then the Mac or the Amiga!
The GUI should also support anti-aliased Type1, Truetype and OpenType fonts.
And be remotely viewable -- using the VNC protocol to remote-view an entire desktop (or just a single app! - -try that, windows!) would be appropriate.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
That hasn't been my experience at all. I've seen three basic sets of opinions:
I'm in camp #3, obviously.
This thread is going to re-hash everything that was discussed here last week and the week before then, is it? I guess that's appropriate, since the article that started these comments also seemed to disregard it.
Right on brother! Xah xah@best.com http://www.best.com/~xah/PageTwo_dir/more.html
I think the real future of th GUI lies in web GUI. I admit that most of them look clumsy right now but things are improving rapidly (mozilla, xml and stuff like that). The problem with X and other GUI systems is that they are inherently platform specific. While it's more open and standard than the rest, you won't find X on many propietary OSes like windows, os2, BEOS (?, i'm not sure here).
I think that more and more applications will have a web interface (thus allowing for greater portability). On the long term I don't think any current propietary windowing system has much chance of survival. If they survive it will be as lower level layers tucked away in the OS with more abstract stuff running on top of it.
Jilles
x has problems that can be fixed with either better implementations or a slight change in the design.
far better then building everything from scratch again. particularly since most projects seem determined to repeat the mistakes x fixes (namely platform independence).
US Citizen living abroad? Register to vote!
Not 100% true. Linux is in real mode for a little bit during it's initilization, but by the time it spawns init, it's in protected mode and it's staying there.
-matt
It's not as bad as I probably implied in my post, but neither is everything peachy-keen. The X design (and that of the current set of extensions) is hitting a wall. Rather than argue with you further, I'll simply ask you to consider the following:
Here are some situations that illustrate the problems I am talking about. I would suggest that you carefully research the problems inherent in doing each of the following:
Most of these things are possible, but all of them are severely non-trivial to do. Study the relevent X standards, and try and figure out how to accomplish these things, learn what the problems are, and you will understand why I say what I do.
---
DNA just wants to be free...
I like X. I first used it when introduced to FreeBSD. Now I use it with Linux. The improvements in supported hardware have had a tremendous impact. X is really what has brought Unix back to the fore as a contender against Windows. I have always contended that it was the Graphics that brought a following to Windows. This doesn't mean I don't think someone should create "Y". What if Linus had said "hey, there is already too many Unix systems out there. Why can't we just use one of them". I could give numerous other examples in both the OpenSource and commercial enviornments. If someone beleives there is a better way and wants to pursue that course than I support him. I only hope that it will be compatable with existing standards.
Let me start by saying I am not really a programmer, nor a regular *NIX user. Just a somewhat educated observer, who has dealt with the other end of the screen, by setting up a lot of NT stations, some UNIX Boxes and even some Macs for CAD, page layout etc.
Seems to me that X is a little too far from the hardware to perform well. It's also terribly inconsistant. That's one reason that CEOs, CIOs and other have relegated Linux, *BSD and other unicies to the highly technical user or the server room. They want productivity, they want conststancy, they want to be sure someone can sit down and get to work right away. The NT4 GUI is consistant (though ugly) and fairly close to the hardware accelerator, which is a major reason people use it. Also, it has very consistant APIs and graphics libraries. And if the hardware driver is written properly, it's even stable.
I look at X, and think "An X server. K. Why?" With all the hardware accelerated graphics out there, I want my display on my own machine. Only a machine that has no display capabilities should need an X server. The X client should be able to directly hook into the hardware driver. If I were to design a graphics sub-system, I'd do it like this:
Driver>Shim>GUI. Why the Shim?
On an App that serves out graphics:
Driver>Server>Protocol>Client>GUI.
Every system that runs X DOES NOT NEED to be able to send graphics through a network.
And BTW, pick GNOME, KDE, Motif or something, and turf the rest. Or at least pick a standard library - again, like NT. Make the UNIX GUI a known quantity, and users and developers will flock to the screen...
"Depression is merely anger without enthusiasm." - Anonymous
The big missing feature in X is networked sound. Sure, there are other hacks and seperate API's to do networked sound, but they are not an integral part of the X protocol and therefore will never be universally supported.
and when you graduated from kindergarden, people will be more impressed with your trivia.
http://art.net/Studios/Hackers/Hopkins/Don/unix-hMy problem w/ X is the size, it would be nice to have the same code (or a subset) of it running on my pda and on my desktop and to be able to share apps, etc.
You'all should look at the white page on the QNX photon gui. Really small and allows neat stuff like dragging an app from one system to another and have it still run.
The downside is that it is not anyway near open source. It would also need an Xlayer to be backwards compatable but if you presented an Xlayer as a module that was used w/ old code and no Xlayer w/ new code neat things might happen.
My biggest gripe is that it seems that _nobody_ cares about performance much anymore (just buy fast hardware/network or more memory is not caring).
Actually, I've spent a fair amount of time wondering why X uses the terms 'client' and 'server' to mean the opposite of the normal usage in any other context. Would you mind explaining how it makes sense?
I found berlin at:
http://www.berlin-consortium.org/
But does anyone have a link to Y ??
There's a name for this: shit pile. Once it starts to stink, pile another on top. It works! and that's all it really matters. (X fans, please feel free to quote me on that)
Xah xah@best.com http://www.best.com/~xah/PageTwo_dir/more.html...or at least we don't know the ending yet.
There comes a time in every man's life when he must say, "No mother! I do not want any more Jell-O!"
there's another mode, vm86 mode, which is spefically for running 16bit code within a protected mode enviroment. it provides a virtual real mode.
windows9x/nt use it for dos compatibility. Linux supports it to a certain extent to help dosemu. Freebsd has more generalised support for it iirc.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
A machine with no display doesn't need a x server as there is no display to serve to programs. Most people get confused about this terminologiy at first (it does seem backwords) but after you look at it closely it make sense, and you soon realise the other way while more obvious is wrong.
Maybe you don't need to send your graphics over the network, but I do, and I need it often. Here at work for instance every one of us requires a top of the line Sparc machine for some graphics tasks, but we only need them for a few hours a week. I got a sparc on my desk, 8 other people use X to access my machine when they need the cycles. Since they are already on my machine often, they do the rest of their work on it too, allowing them to have cheaper machines on their desk. (unless they are doing this CPU intensive activity they never put much load on the machine, there is plenty of power, and we are not wasting an expensive machine on one each desk)
You seem to be stuck in a home enviroment with one high power comptuer to person. It appears you want to play games [a guess, there is noting otherwise to indicate that]. If that is your situation, X leaves a lot to be desired, it is slow. It isn't my situation though, I have one high powered machine at home, and many low powered machines.
BTW, most X servers support not sending graphics through the network when the display is local, this capability should be enchanced and taken advantage of by games.
I also don't understand this weird belief that users are somehow "confused" by buttons that are different colors or have somewhat different patterns of pixels around them. I would like to see an actual example of such a confused user. In fact I think having the applications be somewhat different in appearance helps considerably in identifying which window belongs to which, and avoiding the gray mess that is a Windoze desktop.
This is not to be confused with the "different actions" problem that plagued X, like toolkits disagreeing about what each mouse button did in a scrollbar, and editors that disagree about what each key does. This was (and still is) a horrid problem for X, but it *is* being solved, mostly by the deletion of stupid things from toolkits, and without making the X server enforce it!
The news articles between Linus and the Minix guy (forgot his name) can be found on the kde site last year I checked. It's probably still there. In essence, Linux is being moronic in the usual unix tradition.
Xah
xah@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
It would take YEARS to replace X....YEARS! It has a decade and a half thus far to build it, how are you going to replace such a thing over night???
This argument is specious. Unix has been around since 1970. Yet Linux matured into a viable alternative to commercial Unices (SCO, for example) a mere 5 or 6 years after it was born.
The time it takes to duplicate or surpass the functionality of a system bears little relationship to the age of the system.
maybe 10 years from now it will have surpassed the X of today. But then were is X going to be, and were WOULD it have been had those people added some input and made X better?
Another specious argument. The GNOME/GTK people could have decided to make, say, an extended version of FWVM/Lesstif. However, they didn't: they decided to write something better from scratch. I think most people would agree that RedHat 6 demonstrates that they made the right decision. If GNOME isn't completely up to spec yet, it soon will be.
OTOH, I believe X is here to stay, for the same reason that the x86 instruction set is here to stay: momentum. That doesn't mean that good hackers everywhere can't have hopes and dreams about creating and using something more technically elegant. Eventually, the next-generation window system may even take over, just as Merced/McKinley and its successors may eventually make the x86 a thing of the past.
~k.lee
(remove nospam for email)
It's really strange. If someone said "is Linux ext2 the way of the future?" then nobody would pipe up. People would realise that they don't understand the issues well enough to comment. But ask "is X the way of the future?" and suddenly everyone has an opinion, whether they've ever written X code in their lives be damned. Writing a DOS starfield demo in assembly does NOT make you the leading expert on platform independent windowing systems.
But look at the "reasons" given by the X haters and the revolution wanters!
X is hard to setup: here's a clue, this has nothing to do with X, it has something to do with PC hardware, changing windowing system isn't going to solve this.
Xlib is hard to write: it's hard to write anything if you use the lowest layer possible. Try using the appropriate API layer for the task, not the absolute lowest layer possible.
X doesn't support (alpha blending, multiple keyboards, 3d window managers, virtual 3d glasses, my thrustmaster joystick, insert crackpot feature here): guess what, X version 1 didn't support colour! Things evolve. Linux 0.4 didn't have a TCP/IP stack and Linux 1.0 had flaky support for pretty much any hardware you had available, would you have been crying "Linux is not the future!" back then?
X is slow because of (crackpot self-formed opinion that has never been verified by tests, and never will be because crackpot suggesting person has no idea what they're talking about): here's what illuminary Keith Packard has said about the matter.
Now Keith doesn't stop there. He points out that half the problem with X isn't X itself, but the very stupid widget sets (Xt, Motif, even GTK) that waste too much time in expose events.
If people who whined about X performance ever had some figures to backup their claims (and not just lines/second under WinNT and lines/second under a XFree86 driver, I'm talking definitive proof that X is the fundamental slowdown, not a badly written driver, or a badly implemented X server) then they might have an opinion worth listening to, but the "X is slow" crowd seem to have nothing to offer but hot air and loud mouths and NO HELPFUL IDEAS OR PATCHES.
Here are some real clues. XFree86 4.0 has support for TrueType. It has support for multimon (multiple desktops over multiple monitors). It has support for Xinerama (single desktop over multiple monitors). It has Xinput (joysticks, tablets, mice and whatever). It has DGA 2 (resolution AND depth switching on the fly, direct framebuffer access as fast as SVGALIB). It has DRI (bypass X pipe to avoid layers of inefficiency when doing hardware accelerated graphics). It has Xv (X knows about hardware which blits over your framebuffer, like TV capture cards). It has modularised drivers (so you can easily add support for your video card, and the documentation on how to do so is easy to follow). It has one of the most efficient ways possible of communicating in an ORDERED fashion between many clients and a single framebuffer (local sockets). It has some of the smartest brains in graphics history working on it, and these people know what they're talking about, unlike half the rabble who have replied to this slashdot topic with their own uninformed opinions.
Afterall, Linux has it's flaws as well (and I'm not talking INSTALLATION or PENGUIN GRAPHICS WHEN IT BOOTS, I'm talking about the SCSI MIDLAYER and the ISDN LINKLAYER) but would the proper fix be to throw Linux away and write a brand new kernel? Of course not, yet a windowing system is 100s of times more complicated than the Linux kernel and it seems that people think throwing code away is appropriate here. All that implies to me is that the X haters have no idea what they're suggesting.
I advise people shutup about things they don't understand. If there is a problem in X, try fixing it, rather than complaining about it, or suggesting that the proper fix is to reimplement the 100s of 1000s of man hours of design, testing, coding and fixing that has gone into X.
Well said.
If Windows9X or NT used XFree86's X server as its GUI, there would be more people pointing this out. You have to truely love Linux to be able to point out it (and its components) flaws in order to make it better.
Imaging Windows running with XFree86, people would say that it is running on an arcane legacy code that MS kept in because they cannot truely innovate anything from scratch. And that it is so slow and clunky. That it is difficult to use because of its poor design.
I feel that this extend X can only make it worse. I also don't know why anybody pointing out a problem in Linux is always flamed for being to stupid and that they should be smarter and overlook what they think is a problem in Linux because it is Linux.
Just my thoughts on the matter.
Oh, for that you can thank people like slash dot and OS opinions, where cheesiness are preferred over quality, and rumors and stupidity are encouraged to replace thinking.
Thank you slash dot for spreading the unix way of things.
Byyyy the way, lovely slash dot does not support the 'pre' tag, but supports the fucking obsolete 'tt' instead. Good work rob and hemos. Party on. Drink more beer. Live long and prosper.
Xah xah@best.com http://www.best.com/~xah/PageTwo_dir/more.html1. X clients on the same machine as the X server use the shared memory extension and not translated over the wire.
Wrong. Show me something other than a game that does this for anything but displaying bitmapped images. Local or not, most operations still take a trip through a socket, Unix domain or otherwise. The only way you'll get the majority of graphics operations in a typical application to go through XSHM is to reimplement the entire set of X drawing primitinives yourself in your application, and scribble on the shared bitmap directly. And if you do that, you don't get to take advantage of availible 2d acceleration, either. It might actually end up being slower on a good accelerated X server.
2. CORBA is largely a glorified RPC hack that requires socket round-trips for each remote request (can you say slow?). Oneway calls don't help you here as they are unreliable by design - read OMG's CORBA specification. Each of CORBA's on the wire requests has a big header which includes the name of the remote function name - in ASCII no less! The longer the name of the remote function - the longer it will take to process the remote request. This cannot possibly be more efficient than a finely tuned graphics-specific protocol such as X11.
Variations in function name length aren't going to have an appreciable effect on performance. Worst-case, you look up the function in a hash table, but most common hashing algorithms are _not_ slow. I can see where some of the other header crap might have an influence, but again, the whole idea is not to couple the client and server as tightly over the network as is done in X.
X11 isn't exactly finely tuned either (although it's certainly lighter than IIOP for what it does) -- that's why we have lbxproxy and friends. But anyway, the point is not to have to do an over-the-wire request for each drawing primitive. Look at the design of something like NeWS if you don't believe that very very minimal communication between the client and server is possible when drawing things on the screen and related things.
3. A CORBA call will only be native if the server code is physically linked into the client binary - either shared or staticly. This would make the process size of your CORBA clients much bigger than the current X client/X server model, and resultantly with many process - much slower.
Actually it's the other way around -- things get loaded into the server, not vice versa. (*cough* NeWS *cough*) (which is not to say that everything must be in-process)
Additionally, you are aware that shared libraries only get loaded once under any self-respecting Unix? Memory usage from the text segments of the library isn't going to significantly increase after the first couple processes load the library. Admittedly, I'm not sure about working set size in general.
Time and benchmarks will determine which of us is more correct with regard to performance considerations, but I do know you can throw out the sundial right now.
---
DNA just wants to be free...
Depends on your definition of "fine," I suppose, and whether you're on 10baseT, 100baseT, gigabit, etc. Anyway, I wasn't saying that Quake2 doesn't support remote display, but it generally is a bunch of suck.
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
You've bumpoed into the 'Rolls Royce over night' problem -- one person alone can't code that much...
John
John_Chalisque
How exactly does one extend X with features such as
- Elegant minimalism
- A single unified font subsystem that understands font metrics correctly...
In short -- extending an existing architecture CANNOT make it any leanerJohn
John_Chalisque
The other (IMHO better) approach, taken by NeWS, was to allow the server to be dynamically extended with a (Postscript) VM (like the way that JAVA classes can be dynamically loaded).
The window management was customisable, but ran inside then display -- rather than over a network connection
My take on this would be to represent most GUI controls abstractly, let the display handle drawing them, and then allow for high performance streaming through the display system.
John
John_Chalisque
>Mark Stanford should be ashamed of himself ...
and there's a saying that programer cannot write. We have Larry Wall, Tom Christensan, and slash dot folks leading the cause. Now we must add Mark Stanford. Congrat, Mark!
Xah
xah@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
If Linux wants to dream of world domination it will have to account for the fact that most users
are "stuck" in a one computer home environment, and worse, the majority of them are interested in playing games.
I'm not arguing against X, I don't know enough to make a case. Speed and bandwidth issues are probably going to be less important fairly soon anyway. I do think that there is a lot of interest in high performance graphics in the worldwide computing community, both by home users and scientists.
If someone like Rob Pike calls X bloated and slow, you just think, well, he would say that, wouldn't he?
But if jwz thinks it's bloated and slow, well, there's someone who knows bloated and slow inside out and backwards.
Me, I think I can live with slow. If Netscape wants to wait a minute and a half before it gets around to drawing a page, that's fine; I'm sure it's doing something vitally important, and I can always use another cup of coffee. Gods know I can't go for coffree during compiles any more these days, what with 10k lines built before my finger leaves the return key.
But if it wants separate I&D, it's too damn big for my taste.
http://terror.hungry.com/products/Ywind ows/
Not much there yet, it seems.
I've done almost all of my X programming with either Tcl/Tk or TeleUSE, and haven't really dug into X itself. There's a reason for this -- X is huge. I'd have to erase 15% of my brain to find room to store all that information.
Maybe they should think about cleaning up the API a bit, and deprecating all of the less useless stuff. It's starting to look like the Windows API.
TedC
Couldn't the framebuffer drivers intialise the gfx card, allowing a fb X server to use the VESA modes?
> X is not THE future, but X is a future. It is
- haters/x-windows/disaster.html
...And so is a molten blob of pig iron. But it's getting better; at least now you don't hasve to use your bare hands.
...And Iran-Contra wasn't Arms for Hostages.
/* Black. */
/* Whoops! No, I mean: */
/* AAAYYYYEEEEE!! */
> extensible. It is modifiable. It works well.
> The things is does not do, it can be made to
> do.
Yeah, and being conquered by Castro and eating dirt for a living is also a future.
> You're all going to repeat after me 100 times:
"X is a hunk of shit."
...
Excerpts from:
http://art.net/Studios/Hackers/Hopkins/Don/unix
If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that.
- Marus J. Ranum, Digital Equipment Corporation
...
* The Motif Self-Abuse Kit
Recipe for disaster: start with the Microsoft Windows metaphor, which was designed and hand coded in assembler. Build something on top of three or four layers of X to look like Windows. Call it "Motif."
...
X Is "Customizable"
...
Myth: X Is "Portable"
Even if you can get an X program to compile, there's no guarantee it'll work with your server. If an application requires an X extension that your server doesn't provide, then it fails. X applications can't extend the server themselves -- the extension has to be compiled and linked into the server.
...
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4.
...
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0;
favorite_color = BlackPixel(display, DefaultScreen(display));
(client dumps core & falls into the chasm)
...
Programming X-Windows is like trying to find the square root of pi using roman numerals.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Milton Friedman was right about that. Is X the best possible GUI? No, and I don't think anyone here will argue that it is. However it is a dman good one, and while I don't understand the tech details all that well, it has the following advantages from the user point of view: * strong programmer support (lots of apps, utilities, windoze clients, etc) * established standard * portability, both in itself and in its apps * flexibility * stability (at least compared to its major competitors) * maturity * wide range of widgets and window managers available An upstart would have to have massive funding and brilliant design to even approach that set of advantages. And the relative advantage would be small. In addition, the two most common gripes about X, that it is ugly and difficult to configure, are not fundamental characteristics of X. The first is the fault of the most common widget set. The second is fixable with a well-designed setup utility, which is a whole lot easier to build than a whole new GUI, and much more fundamentally useful.
> I'd really hate to try running Quake2, even
... lead to the exact same
> through GLX, on a remote display. The latency
> would be absolutely *horrible*...
Yes, you may find it too slow. Someone will, someone won't. But if the program code complain and exit immediately on servers without share memory, the user has no choice. He won't even be able to see whether it is "too slow" for him.
> (since there's absolutely no way to do that
> server-side without relying on GLX, which, if it
> doesn't exist on the server, needs to be done in
> software on the client leading to - guess what -
> bandwidth! AND horrific CPU/memory usage!).
Then why don't implement a GLX module on every X implementation instead of building a new thing? And of course, if the lack of GLX lead to large bandwidth requirement, that "large bandwidth requirement" is the "minimum requirement" for that system, and nobody is going to charge you wasting bandwidth.
> any extensions
> situation, namely a shitload of X servers which
> won't be able to run these programs.
The difference being that at least I can continue to run my old applications, and I can hope to be able to run the new program together with the old ones. If I want some new extension, I just need to write that, instead of a whole new windowing environment.
> you can't talk about its total acceptance and
> suggest making new protocol extensions either
You can. Not every people need the same set of extension. I, for one, never need any input extension, and never load the PEX module into my server. That doesn't mean either is not being accepted. I'll find it when the need arises. Being extendable is a beauty of X, not a baggage.
Which are Linus' comments on modularity?
I'm developing a higly modular application and would like to read them. Could someone please point out where can I find them?
Thanks.
Alejo.
Okay so actually I do run X, but only over VNC. If the connection fails (modem hangs up, isdn brainfart, cable modem block sync failure, whatever) I can just reconnect and all my programs will still be running. That for me makes all the difference between a usable system and an unusable one. I mean, it takes long enough for my desktop to load over a slow link (even with LBX), having to restart all my programs too is just too much. VNC fixes that fine and as a nice bonus it can also share Windows desktops. Clients are available for Unices, Windows, Mac and Java, so given half a web browser there's really no place you can't use it from. And it's just a snap to set up, compared to X' security, and probably more secure at that, at least authentication is encrypted. It's relatively speedy too, using compression by default, and to top it off the source is available.
If you don't know it, here's the link to VNC> . I am completely in love this program. What does this have to do with X? Well, even though X may be a whole different beast from a design point of view (VNC just transfers images from the frame buffer, no remote graphics calls), VNC through its pervasiveness and ease of use is much better at showing just how useful networking computing really can be. It also highlights some of the biggest problems with X (or at least some of mine).
Motif and CDE "beautiful interfaces"? More like baroque, committee-designed monstrosities.
"Stick to just Xlib and Xt?" Eugh. I'll bet this guy has never written a real GUI program. (Xt is painful to program in.)
X makes a decent, functional substrate, but it must evolve. In particular, the GUI toolkit layer needs improvement. And the market has spoken; most new applications use Gtk or Qt, rather than Xt-based systems. Motif itself appears to be, mercifully, on the way out.
X superbly designed ... hmm, the forgot to include couple things that make programmers life very difficult ( like for example much better ways to query current WM ,etc)
But Merced is deigned to be backwardly compatible with x86... you're defeating your own argument.
I have an interested vest.
Vested interest in what????? X is a free standard....no profit to be made off of endorsing it....
I have to say I agree with guy who is arguing that Berlin will be slower than X ...
The way I see it it's quite simple:
CORBA is appropriate for high level stuff where transfer optimisation is not an issue, but no matter how much you try to reduce the frequency of events in your model, for something dealing with low-level GUI, you are just not going to get away with this.
CORBA is RPC based, X is fully streamed.
Okay streaming is generally less well understood and harder to implament, but gives you much better performance when you do it right...
My feeling is that you have to start out with the most appropriate tools for the job i.e:
RPC for application level IPC etc.
Streaming for low-level/heavy-load stuff...
"If you don't like Fords, help Ford make a better car!"
Screw that. We'll write our own windowing system and let X people back-port our code to their lame-ass "UI".
Great attitude - considering that most of the work that goes into the only usable free windowing system from Unix is done by volunteers, your attitude demonstrates at once a lack of both respect and clue.
What you are referring to is a toolkit. The problem is in X itself. X doesn't specify how to draw complex items, like buttons and scrollbars. The X protocol lets you say "draw a line here, put a white pixel there, etc." The layers existing on top of this (Xlib) are things like Xt, Motif, Gtk, and Qt, which as you've already mentioned, don't all look alike. With the X design, the only way to have a consistent appearance to widgets is to use the same toolkit for each and every application, which isn't likely to happen anytime soon. The problem is that the X protocol just isn't high-level enough. It's extremely flexible because it's so low-level, but this flexibility has led to the great discrepancies in widget appearance from one application to the next (if they use a different toolkit). The real solution to this sort of problem is to not communicate requests to the server in terms of pixels, but common objects that any windowing system should support. A button is a simple thing. You should be able to tell the server, "draw a button in the middle of the window," and it will draw one. Now the application can no longer control the actual appearance of the button, but this isn't a bad thing. Now the user has that control. Just tell your server what you want buttons to look like and then all clients will have consistent buttons (or any other widget). The main problem with this approach is that you have to assume that the server will support every widget type you could ever want to use. This is actually less problematic than it seems at first since most new widgets are just compositions or specializations of existing ones, so that given a good enough starting set, you can construct what you need, and if it seems like something that would be genuinely useful to many, you can submit it for inclusion in the server. If you've read anything about Berlin, this should be familiar.
I agree that the X11 protocol is not optimal, but each message is on average 25% of the size of the IIOP/CORBA equivalent. IIOP's request header is ridiculously large for what it does. Fast operation string hashing algo or not - nothing beats an int lookup as is the case with X11's protocol. You cannot dispute this.
There's one thing you don't realize: Berlin's exposed API easily reduces the number of calls that need to be made, in a stringent case, by a factor of ten. In most cases this number is much more generous. One marshalling op and IIOP header can easily win in comparison; all that's needed is a little foresight in designing as coarse an API as is practical.
Remember, we're transmitting calls on the toolkit level here, not meddling with primitives of the drawing engine (like X forces you to). With a bit of hindsight, some of us have decided that the interoperability we gain by using CORBA far outweighs the overhead of the protocol.
Also keep in mind that nobody ever spent any great deal of time profiling and optimizing interviews or fresco. These were both developed during the time of 386s and 286s, and being way ahead of their time, were purely theorhetical. So please don't cap Berlin's potential in your mind by looking at Fresco's ineffeciency.
Don't blame the Open Group directly - blame the stakeholders in the Open Group, aka the commercial UNIX vendors (Sun, IBM, HP, et al.)
There's a good argument there that the UNIX boys have decided to roll over and play dead on the desktop. Stagnating X development is just part of the problem. Why bother improving the capabilitites of your clients when you can make boko bucks selling huge database servers to serve Windows clients? Nothing, until Microsoft starts to eat your server lunch.
--
Business. Numbers. Money. People. Computer World.
Excuse me, but since when does a programming language make code inherently object oriented or procedural? There is nothing preventing any decent programming language, including C, from being used for object oriented design.
For instance, note that GTK+ is a truly object oriented toolkit. It's written in C because C++ is truly horrible and would prevent it from having lots of bindings it can have with C. The bloated class system of C++ is simply unnecessary for anything.
GTK+ is wonderful. It provides a fast, flexible, pretty (see GTK+ themes), and very portable. Don't try to explain that something cannot be object oriented because of the language it's written in. Think about it: any language will be used as machine code. Machine code can be anything you want, object oriented or procedural, depending on how it's written. It does not depend on C++ or any other "object oriented" language.
Brian Fundakowski Feldman
This article is laughable. I will debunk myself only a couple of its claims, but do yourself a favor and read the X11 chapter of the Unix-Haters Handbook . They do a much better job than I could even if I really tried.
X [is] beautiful from an engineering standpoint. It functions excellently on networks and uses shared memory to efficiently coexist with programs running on the same machine as the X server.
[...]
A specialist in California can run a program on a computer running IRIX in Japan and display it in the comfort of his own home on his Mac--complete with high quality 2D and 3D imaging--securely and even over a low bandwidth link.
Ahahahahahahah! This one is actually funny! What do you think he calls a "low bandwidth link"? I hope it's not some kind of phone line, because last time I tried to use xv (your basic image displaying program) with a modem, I almost threw the computer out the window. Try it for yourself, it's impressive... in slowness. Even with custom "compression protocols", X is a bandwidth (and memory) hog.
"Securely"??!!! You mean that the ugly hack known as MIT-MAGIC-COOKIE is considered secure? Who are we trying to fool here?
I'm sorry, X sucks. I've never seen anything quite as bloated and slow. The only reason everybody uses it is because there really isn't anything else. The only good thing about X is that it's not integrated in the OS and I can do without if I want to. Oops, wait, that's because it's running on top of Unix.
I tried this out and it worked fine with several generic X apps (xcalc, xterm, xmessage).
Granted, it doesn't work with every app, only with those that follow the prescribed X usages and protocols, in this case in terms of resources - but that was the guy's point, anyway.
--
An esoteric scratched itch:
Homeworld Map Maker Tool
They don't. See themes.org for more information.
This is an example of bad, nonstandard programming for X. Programs should have compiled-in fallback resources such that if the defaults file is deleted or renamed, then app will have a usable, if vanilla, interface. If the app requires an external resources file to function then the developer was just lazy (and yes, I have come across such - it's very annoying).
--
An esoteric scratched itch:
Homeworld Map Maker Tool
There's one more camp in there.
4. Was brought up on Command line, and thinks that _all_ GUIs are bloated and mostly unusable, and doesn't like X programming because it is so damn complex and slow.
Besides, the vast majority of things are better done on the command line (the notable exception being graphics applications). Oh well, I guess I'm just a heretic of sorts (even though I'm only 17 and I'm one of the newer generation of Unix nutcases...).
Yes, they can. Use vesafb and XF86_FB. The drawback is that you can't change the modes anymore (since mode changing is a real-mode-only function).
This is handled better by toolkits like GTK, because you can use a standard widget if you want, or write a custom widget, both of which will be globally themable (to coin a buzzword). You don't need to submit your widget for inclusion in the standard distribution if it won't be of use to anyone else.
FACT. The current Berlin project has nothing to do with the original Berlin project. The original Berlin project (of which I was a member of their mailing list) was a fast, highly optimized system written in C with its own graphics kernel. The two founders of the project left years ago. The original system even had a crude graphics kernel with Japanese characters in its test page and a heap management system for managing applications (like Win32). FACT. The current project is a fraud perpetrated by people that had no authorization to use the name Berlin, neither did they invent the project, nor did they contribute any code to the original project, nor does it even come close to any of the goals of the original project. The current project is a cheap "piece-meal" of other projects (corba, OpenGL, etc.) to produce a windowing system, NOT an original implementation of a windowing system from the ground up, as was the original project. DO NOT SUPPORT BERLIN.
I concede not all X11 operations use XSHM, but the most important/bandwidth expensive ones do, like bit maps, etc. (Qt, for example, is not slow with client and server on the same machine)
I agree that the X11 protocol is not optimal, but each message is on average 25% of the size of the IIOP/CORBA equivalent. IIOP's request header is ridiculously large for what it does. Fast operation string hashing algo or not - nothing beats an int lookup as is the case with X11's protocol. You cannot dispute this.
Does Fresco use normal blocking (non-oneway) CORBA calls (forgive my ignorance) for most of its operations? If this is the case the socket round-trip time latancy will kill your remote performance. If use use oneway calls, on the other hand you risk not delivering the request. You lose both ways.
As for having the complete Fresco GUI lib linked dynamically via a shared lib into the client: true, the code of the shared lib is common to all processes, but the data associated with each "instance" of the shared lib is not. I concede this point is probably not much of an issue.
You may not believe this - but I like the idea of Fresco - it seems to be a rather elegant design. I merely disagree with its transport mechanism. Good luck with the project.
This feature is abused.
Actually I used to play Quake2 remotely and it worked fine, up till about 800x600, then things start getting sluggish. Running 2 copies of Quake on the same machine (don't do this unless you have plently of RAM) and displaying one on a remote machine and one on the local machine is no problem.
cya
How exactly do you propose that 'web GUIs' actually draw graphics on the screen? You still need an underlying graphics protocol. The article was spot on - X is superbly designed. The coming extensions from Precision Insight, SGI et al, such as Direct Rendering and GLX, should eliminate the need for alternatives like Berlin, Y, etc.
Brian Blackwell
-- briggers Remove blinkers to email me.
Well, if the Linux community is gonna switch to a new GUI, we should do it either now or as soon as possible, the longer we wait, the greater presence Linux will have, and the harder it will be to change over the entire user base. Especially when the desktop battle with M$ is on the horizon, switching GUI's might not be the best thing for Linux right now. I'm not saying we should switch, I definately would, but think of the trouble it might cause newbies to have to switch to a new GUI right after they learned one "not-so user friendly" GUI. But I do think we need something better, and we could come up with a GUI that would blow all the others away...
-- My neighbors dog has a four inch clit.
But Merced is deigned to be backwardly compatible with x86... you're defeating your own argument.
Oh, dear god... I hope you're kidding... I thought maybe Intel would *finally* drop the whole "backwards compatibility" thing and design a chip which is free from all the shit that Intel chips have been plagued with until now.
Of course, this is not to say that they shouldn't provide some sort of x86 emulation program (but in SOFTWARE, not in HARDWARE) so that the drooling idiots could still run the Windows 98 version of Word on their new Merced boxes, but users who don't need this (eg. Linux users) won't have to deal with the 20 year old 8088 baggage (seriously, is there a real need anymore for the Pentium III to start up in real mode???)
"Software is like sex- the best is for free"
You can get X servers for Windows. X ought to compile on anything that can run a standard C compiler. If it doesn't, it ought to be ported.
Standards are great, but they should never hold back technology. The clincher for me was at the end of the article where the author plead that we stick with Motif/Lesstif.. there are reasons why GNOME and KDE are around, and there will most likely be thousands of other toolkits invented after those. And _this_ is why X is so great, because we can make gazillions of toolkits/windows managers/desktop managers/etc.
Sometimes it seems questionable of whether X should really be so network happy. Its not that its not a cool thing, but its definately a _slow_ thing. Other methods (for example, a Java scheme where applications are downloaded, and run locally) could speed things up, and allow for much much faster protocols to be used (right now everything is done through a TCP/IP stack).
I will end by saying that the authors questioning of why we would write games with GGI/etc. shows the ignorance at hand. Obviously, as with any OS, people want high performance graphics. It is ridicolous to say that we should not allow this because the standard is there. As far as I understand XFree86 will implement direct draw, and I beleive this to be a good thing. THIS is how standards get made, and perhaps other companies/groups who make X servers will look at this, and add this feature as well. While I am in favour of standards, I am even more in favour of new and better standards.
"On the other hand, sometimes a product has been kludged as far as it can to work as well as possible. At a certain point, the developers need to reassess the product and how well it meets the users' expectations. When the users expect the software to perform tasks that are impossible in its current implementation, sometimes a complete rewrite is required to add a feature."
With the full intention of igniting a flame fest, I submit that not only X, but all UNIX-based operating systems and their dependent applications have been gathering useless features, badly-designed protocols, limited IPC interfaces, hacks around limited IPC interfaces, competing standards, cruft, bloat and ugliness of all kinds for far too long, and that it is time to start again from scratch.
I mean really from scratch. No POSIX compliance, no backward compatibility with X, no shell scripts, no teletype-style terminals, no filesystem, no vi, no suid programs, not even a lethargic penguin for a mascot.
Hackers wanted.
All I can say is it is about fucking time someone said all the things which I have been saying all along. "Stick with the standards!" And X is a damn GOOD standard. I especially like the part about Adhering to the ICCCM and being compliant seems these days noone cares about adhering to standards anymore...lets all invent 1000 different ways to pass data back and forth, each requiring a different set of libraries, and forget about the standard way here that actually functions and comes as part of the system....or better yet, lets not talk to anyone but ourselves and everyone will just itch to run our system because it communicates so well.
Granted, X is stable and relatively bugfree, but it is old. It is often handy to be able to run an application on one machine and display it on another machine and this is the major strength of X in my opinion. There is no question that it could do so more efficiently, however.
The problem I have with X is sound. There is no standard way (that I know about) to have the sound from an application play on the display that the output shows up on. Granted, most run the applications on the same machine as the X server itself, but is that because of the lack of sound propogation or just because? (Probably a little of both actually.)
I agree that the excess bagage that X has carried along with it through the years should be conveniently misplaced and leave a much more easily debugged and more efficient system. (That's not to mention the security needs to be rethought.)
Well, that is by $17.42 worth for today.
If it works in theory, try something else in practice.
personally I hate programming in X. I sure HOPE its not the future.
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
jdube is who
Could it be possibly that they don't want you using , because you could screw up the presentation of the entire comments page with it?
Could it be that has it's uses for things like, well, HTML tags?
Before you complain, try to figure out why it is the way it is, ok?
-- The act of censorship is always worse than whatever is being censored. Always.
Will programs written for Direct Rendering or GLX still run remotely over a network?
- Far ahead of its time, X has always been first and best.
...beautiful from an engineering standpoint. ...there is a large infrastructure of companies and developers supporting X. This means that any improvements that go in are going to be good improvements, not bad ones.
Add to this a dash of hyperbole: ...and not the Microsoft-reminiscent idea of throwing standards out the wind. - We must not turn to crackpot "alternatives".
It sounds as if he has a vested interest, and it's always a good idea to know where people are coming from when you read an article like this.In the beginning I was getting moderation points everyday (I was up to 15 at one point.)
;)
I complained that something must of been broken, but got no response. Then I went away for a long weekend and lost the 15 points. Since then I have never been a moderator since, so I'm starting to think I'm on some internal "shit list".
Just as well I guess - I rather bitch than read other people bitching anyway.
X is an almost ideal graphics environment in that it can be used both locally and remotely. What X needs is local graphics performance that can rival that of MS platforms - and the direct rendering interface should make that possible. Improvments should also be made in the X network protocol to increase network performance, while possibly maintaining backward compatability. As far as configuring X goes, application software can always be created to provide a simple configuration interface. It is better to keep the ability to customize the X environment then to have some simple windowing soloution, like MS OSes - which can only be run locally.
...but is X a GUI? From my (admittedly limited) understanding, X is the stuff underlying the GUI. Can somebody who KNOWS clarify?
Tusind tak.
------ "Darn floor. Big bite." (Koko the gorilla's best attempt at explaining the experience of an earthquake.)
I don't even know where to begin listing the ways this article stomps on my buttons. Could it be the Linus-is-God mentality and if he says "modularity sucks" then it must? His opinions lost a lot of credibility with me after his rantings against microkernels.
Or perhaps the "it's good because it's standard" mentality that drives the author to plug bloatif. Hey where's my grid control for motif? How about a tree list? News flash: they don't exist.
Or maybe "well X really *can* do this because it has extension y and extension z". Great, extension after extension after extension, while fonts can STILL only be passed around as 1-bit pixmaps. Hey the Windows API has a lot of extensions too, are you happy with that?
Or perhaps it's the "newness is unbellyfeel doubleplusungood, our leaders have taken us this far, petition them with our cries that they may take pity on us." This could just devolve into a whole new sub-rant, but I'll ask the $20,000 question: how much does membership in The Open Group cost? (Around half the cost of the question, I believe?)
This is personally my best hope for replacing X, or giving it a sorely needed wakeup call.
I've finally had it: until slashdot gets article moderation, I am not coming back.
If it is necessary, then, to create an autoconfigure tool and either maintain a database on graphics cards and monitors or (if the hardware supports it) query them directly for the info, then why not take the easy way out and develop this on top of X?
You realize there's a difference?
If the programmer wants certain UI behaviors to be customizable, she should just add a "Preferences" dialog
So, I get to go through twenty-three applications' preference dialogs to tell each one that on my double-headed console I want to use 16-point Lucida on a LightSteelBlue background (I don't really, that's just an example!), while on the quiet little monochrome terminal in the bedroom I want one of its built-in fonts on a white background.... Or more likely, I don't get to do that because it doesn't occur to the apps' luser programmers that I might want to run the thing on different displays with different properties.
That's part of what the article's author meant by the "PC-centric" attitude of many X opponents. X sucks, but how can people come up with better answers if they don't even notice that there are questions?
As the article said, why replace X when you can simply extend it? Have a look at the feature list for XFree86 4.0 - it's pretty amazing. Direct access to the hardware with DRI, 3D accelleration from SGI, TrueType support....
A complete shift to another windowing system is just not going to happen. Are the GTK, QT, Lesstif guys willing to rewrite their stuff? Can we persuade UNIX vendors to use Berlin? Not bloody likely.
Brian Blackwell
-- briggers Remove blinkers to email me.
Also, just sticking to Xlib and Xt is not a Good Thing. Do we really want everything looking crappy and having the reinvented-wheel look all the time? Not to mention that raw Xlib coding is a *bitch*. There's a reason for Motif and GTK and Qt and CDE, which he feels perfectly justified in extolling at the beginning of his essay.
Even his "do it with X" mandate doesn't always make sense. Again, games don't always benefit from X, particularly ones involving realtime rendering. Even scientific visualization applications tend to suck like that, particularly if they require zbuffered rendering (since there's absolutely no way to do that server-side without relying on GLX, which, if it doesn't exist on the server, needs to be done in software on the client leading to - guess what - bandwidth! AND horrific CPU/memory usage!).
His last preachy bit is just plain laughable...
X is here for a reason. It is an excellent standard. It is by far the best graphical system available. An ingeniously designed, expertly implemented system, X has served Linux for years.
I agree that it's an excellent standard, but there's far too much baggage. Yes, it's already got plenty of acceptance, but any extensions - which this guy is proposing we do, instead of a rewrite - lead to the exact same situation, namely a shitload of X servers which won't be able to run these programs. It's not ingenious, any moreso than telnet or, at an extreme stretch, NFS, and although the implementation of the current specification could be considered expert, the current specification itself isn't. When was the last time you saw an X9 or X10 program in actual use?
I'm all for consistent, open standards, but this article is just too preachy and has an extreme case of tunnel vision, not to mention quite a bit of self-contradiction (you can't expect someone to use X11 to its fullest and use Xlib at the same time, and you can't talk about its total acceptance and suggest making new protocol extensions either).
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
Wait till Apple ships MacOS X with the impressive Quartz graphics engine and a redesigned GUI. Then, true to Linux form, write a blatant rip-off. That's probably how it will work in the end.
--
Linux - reinventing UNIX since 1991.
It would take YEARS to replace X....YEARS! It has a decade and a half thus far to build it, how are you going to replace such a thing over night??? Why not spend that time improving upon what ALREADY EXISTS so that the end result will be BETTER and HERE?? 3 years from now maybe Berlin or Y will be useable enough that some people can actually use it as a desktop under optimal situations, maybe 5 years from now most people will be able to use it...and maybe 10 years from now it will have surpassed the X of today. But then were is X going to be, and were WOULD it have been had those people added some input and made X better?
I do not agree with the article however, mostly because of the too positive comments of speed. X is slow:
- Slower than other remote display protocols, especially ICA (which has HUGE disadvantages of its own, but is a lot zippier).
- Slower than direct access to the video hardware, which is a huge problem for games.
Unlike the author who only seem to be concerned with mindless raving, the developers of XFree86 are addressing these concerns.By all means, create competitors for X. Competition is good, and I'm sure X will massacre anything it meets on its path!
...because I sure didnt see it in his article.
To quote from the article :
"First, the idea of replacing X. Recently there have been several groups making claims that they are creating a new windowing system that will take the place of X. There are cries of "modularity" (see Linus Torvalds' commentary on modularity and why it is flaky). There are cries of "Let's create a new system!" And mainly these cries are just that. There is really no reason to replace X."
What the author goes on to say is that X is an existing standard, so we should not bring up a competing standard but choose to work on the existing standard. It seems to me that he hasnt really addressed the question of whats wrong with the competing standards. What were Linus' comments about modularity, and how do they apply to X's competitors? Why is Berlin bad (according the the author)? I was hoping for information in the article and just got a rant.
Again, later in his article, he rants on about development tailored to PC's. Fragmentation of a standard is a bad idea, but again, I'm sure there is a plus side to what these developers do (or else they wouldnt do it). The author has not addressed the question of what these plus points are, and why they are just not worth it. Can someone enlighten me?
There is no such thing as luck. Luck is nothing but an absence of bad luck.
AFAIK, GLX can run remotely, but I'm not sure.
I see several people saying things to the extent of "We need a new GUI" or "X is a great GUI". This is a misconception - X is not a GUI at all. A GUI (Graphical User Interface) is the collection of buttons, menus, etc... that comprise the part of the program that the user interacts with. At its heart, X is a protocol and the implementation of that protocol. It takes requests for services (through Xlib) and performs the request. Projects like Y and Berlin would do well to examine the X protocol closely. It is extremely well-thought out and efficient. The implementation may (or may not) leave something to be desired at times, but deep down, X is by far the best thing we have.
Yes, I know, "Berlin"...a piece of software that can do nothing more than render polygons does not an X replacement make.
I've used X on many platforms, and compared to Windows, it is far far slowed in both window dragging, and games, and windows refreshing, etc. X needs to be slimmed down and sped up. BeOS has an amazing GUI which blows away Windows speed. I think Linux needs to do this as well if we want more developers to jump ship.
I really don't understand this recent fad with making user interfaces like web browsers. This a bad idea. No, HTML should not be inside a GUI or even mentioned. Bundling a web browser inside a desktop is very unscientific. Remember every program does one thing and does it well? That was a good idea. A file manager is not a web browser is not a word processor is not a mail reader.
Programs are not documents either.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
The fact that X is the only game in town has contributed greatly to the success of unix. Just look at the mess we're in with GTK and Qt - think of the todal wave of apps we might have today if we had *noe* standard instead of n.
Rushing to develop because of competition is VERY BAD THING. Any PHB's are sure to endorce rushing development: that's proof. Do what's technically best, not what is best for Red Hat's marketing drones.
Gnome is a perfect example. EXCELLENT PROJECT. But what is 1.0 should have been 0.1. Be patient. It might be a few years before we have everything together. Maybe GNUstep running on Berlin?
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
Although I suppose that this goes back to ESR & RMS's ongoing debate about open source v. free software, last year's aborted X11R6.4 licence change makes me somewhat sceptical of The Open Group as any kind of reputable open source (nevermind free software) developer. Although they seem to have recanted, (see www.xfree86.org) I think a suggestion to developers that they go and clear all their ideas via the The Open Group and try to get them to initiate X12 to integrate them in; is going to leave a bad taste in many people's mouths.
As for the suggestion that using Motif is a good path for open software development (even with Lesstif coming on apace), try telling that to the Mozilla developers.
However I do agree that as a mature standard X11 has a lot to offer and further would respectfully suggest that many of the more vocal "let's get rid of X" proponents don't understand exactly what they are proposing to chuck out (as opposed to the developers etc. who are doing less talking and more coding).
I and several other are having mouse problems. Althought they seem to be kernel related, they only happen when I am in X. If they go away, I will have a nice machine that will be up and running X all the time. If not I amy have to switch to another OS, like Solaris or Free BSD.
Only 'flamers' flame!
I think it would be a mistake to diverge from X, it's networkable capabilities are unique and is one of the reason's I'm interested in Linux.
The author implies that Linus has some damning comments on modularity and asks the reader to look them up. However (using Google, natch) all I can find are comments from Linus on how great modularity is. Does anyone know what the author is talking about?
I can't help but think that X is lacking one thing that would really help the situation. (Though this could be done, and X is still great, regardless.) There ought to be some layer between X itself (Xlib and friends) and the window manager. As everyone keeps pointing out, the window manager is what controls the interface, but it's usually more complex than that. Nowadays, it's a combination of the WM, and the toolkit used to write the app. I may be silly, but I'd like a desktop with a consistent appearance. And when I'm running apps written in three (or four, five, six...) different toolkits (raw Xlib, Qt, GTK, fltk...) I get the feeling that things just aren't tied together. KDE and GNOME help somewhat, but only so long as you're running their apps.
If there were some layer of abstraction that dealt with general user preferences on how windows should behave/look but with enough freedom for toolkits to provide real added value (ie speed of widgets -> Motif moves like molasses uphill in January, whereas GTK is snappy) I'd be in GUI heaven.
This idea isn't really fleshed out fully, it just hit me while reading other people's comments, but I think X has the necessary basics to be a next-generation GUI. (Though it could certainly use a "cleanup" stage whereby unnecessary features are removed, and the important ones are made more universal -> shared memory)
-Brian
How old is X11R6 anyway? I've been using it as long I've been using UNIX and Linux. It's got to be at least 5 years old now. And development has gotten so slow that they are adding decimals: X11R6.1, X11R6.2, ...
I just can't believe how slow The Open Group(tm) has been at making progress on anything!!! Look at Motif! How long did it take to go from Motif 1.0 to Motif 2.0? Ten years, maybe? COME ON!!! No wonder why people got fed up and wrote GTK+ and Qt! It's almost as if they've given up and don't care if MICROS~1 has 99.9% market share.
Can't we do something about it? Can we use the Linux momentum to take control of the standard? How about re-working X and calling it G-Windows (GNU-Windows), giving backward compatibility to X11R6?
This sort of thing has cropped up before. And it has always been due to human error.
--
This sort of thing has cropped up before. And it has always been due to human error.
HAL9000
This whole 'debate' thing is bogus. If you think X needs replacing with some better standard, then go write this better standard, and release it. Who is stopping you from doing that? No one that I can see. Rather than debate this, debate it by writing code and SHOWING us why its better.
Reading the X debate, on OSO and elsewhere, I've read the same two opposing opinions again and again:
:-(
1. X is an extremely capable protocol that does all the things you could want it to do, so why change?
2. X is an inelegant, slow behemoth.
The first argument seems to come from experienced X developers who are used to the way it works; the second from people who've written a few small applications and found it amazingly ugly.
I count myself in the latter category, and accordingly dislike the X Window System with a passion. (NB: being a cynical, bitter type I hate almost everything with a passion. Even Linux. Sorry. Don't even mention Windows.)
As a developer, I was repelled by the way chunks of text were copied all around the shop, seemingly needlessly, and the multiplicitous complicated ways applications, libraries, and the server has to communicate to get even the simplest of operations to work.
As an X user, I am annoyed by the laggardly response time to do anything at all in X applications and the amount of resources everything takes to run. Also the lack of simple usability testing in window managers and most X applications bugs my balls. I end up doing what most people seem to do in X - I just run a brace of xterms, running command-line applications in each.
(And when I do run a GUI application, it takes twenty seconds to start up, and then when it does appear it eats the input focus and claims the last twenty keypresses I had hoped would end up in an xterm. And then it usually goes beep-beep-beep to tell me it has done it. The malicious little sod. I'm rambling now; I'll stop.)
Also Sun optical mice are horrible. That's not strictly speaking relevant, but adds local flavour.
The problems affecting X as a protocol are the same problems that hinder most big, old system designs: they're built as layers on top of layers, with the cruft accumulating as more extensions are added.
I would like to see a much more responsive, much less baroque alternative to X. But it'll have to be able to X apps as well I guess.
I've looked long and hard, and have never been able to find an X Server for Be.....does anyone know of any?
Okay, throwing away standards is a Bad Thing. But we're not even a year past the Halloween docs and we seem to be advocating Embrace & Extend. I'm not sure which is worse.
On the one hand, working with the Open Group and taking the time to create new extensions properly would enable users to run new and more powerful applications on their X servers. However, when the majority of applications require that these extensions be installed, the developers are leaving out a chunk of their potential user base. This is, in part, how Microsoft got into the trouble that it's in now.
On the other hand, sometimes a product has been kludged as far as it can to work as well as possible. At a certain point, the developers need to reassess the product and how well it meets the users' expectations. When the users expect the software to perform tasks that are impossible in its current implementation, sometimes a complete rewrite is required to add a feature.
The problem comes down to this: which way is better for product development - constant kludges and upgrades or a complete rethinking of the project? It is up to the developers to decide when a rewrite is needed, not the users. For myself, as a user, I'll suggest features that I want to see and leave it up to the developers on how best to implement them. If that requires a complete rewrite, so be it.
--
Sean Lamb
"A day without laughter is a day wasted." -- Groucho Marx
What's happening with Broadway? Is anybody out there using it? Is it mature?
I thought Broadway sounded like the best thing since NeWS (grin), but I just don't see it in use much.
I saw a list of the most used plug-ins awhile back and Broadway was way down the list. I don't know how it fares on those lists now, I don't keep up with that stuff.
It still seems like a great idea, but it's orthogonal to Java/AWT that gets all the hype.
The problem I always saw with X was fragmentation. How many extensions and app developer suites and interface standards have we gone through? Are there X apps that work together well? If there are, what % of the market do they have?
The MS apps win because someone dictates standards. They aren't any good, but everybody's working to try and use one set of tools and one set of standards. It seems to be falling over under it's own weight as more and more things are bolted on to make it the universal standard.
The same thing could happen with Web standards too. The Web standards have simpler, and thus better, underpinnings, but these days a browser has to support a bunch of application/scripting languages, style sheets, plug-ins for audio, video and XML.
It seems to me that things are being pulled in too many directions in the application interface world.
Technology markets have been driven by change, even change without a compelling purpose. It seems to me that a lot of productive work can be done with perl (or other language) and forms (like this posting! uhhh... is this productivity?).
Reengineering gurus like to talk about recognizing the 80% solution and when it's good enough. In technology, it seems that we're only interested in the 110% solution that will be here tomorrow.
Maybe that's the real problem with X Windows these days. It's great, but for remote stuff the Web is seen as good enough.
I don't know about this guy. He seemed way too committed to something that at best is a good idea that got screwed up somewhere along the way. And anyone who says that we should all use Motif frightens me. Makes me wonder if he's ever seen Motif. "I know! Let's make all the widgets HUGE and CORPSE GRAY! Yeah, that'll be kick-ass!" Phew.
There is no K5 cabal.
I am not the real rusty.
tsia, but, monochrome fonts? No way to access the outlines of fonts via X? Having to use a different X server for a different video card? That's stupid!
If X is a "media-savvy, compositing GUI", then so was DesqView! So is Windows!
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
X is stable, and X is mature. Those concessions out of the way, let's get the heart of the matter.
It seems that all reasonable people concerned with Linux acknowledge that X has some fundamental performance problems on the desktop. While linux screams on a minimal PC when working from the console, when you add X to the mix it can make the same PC almost unusable.
The fact that you can pick an choose you're window manager is great, but as I see it, running X is the functional equivalent of running Windows 3.x. It sits on top the real OS. Adding a modern WM like E or KWM with the baggage of either KDE or GNOME is the functional equivalent of running Win3.x on top of Win3.x.
X was a product of the first wave of GUIs. In the last decade a number of advances have been made in both computing in general and in the way people work when using a GUI specifically. New operating systems have come and gone and "advanced the art." The research has been done. It is now time to sit down and determine the future of the UI for the next decade.
The linux comunity has a choice. Either choose now to build a new GUI that has a small footprint and speed, but still allows for the choice of WMs. Or have it forced upon you at a later date.
This date could be sooner than you imagine. If MS is broken up in such a way that the OS group is separated from the Office group, you may as well forget charting your own path. The Office group has been responsible for all the "advances" in the Windows UI and if untied, and forced to maximize profits on it's own, after a period it will look to enter the world of the now-alternative OS. If their top dog in the Mac and Windows world (as well as the profit center for MS), you can be that if they enter the linux market, they will set the terms as well as the standards.
X can still exist as a client application on the OS (as it does on Mac and Windows today).
To those who say that XFree v4 is the magic pill that solves all of these problems, pull you head out. I'm sure v4 will be better, but it cannot be the best. It is what it is.
You don't need to have different Servers for different cards.. The SVGA server will work on nearly ANYTHING.. The additional servers merely take advantage of the capabilities of individual cards..
-- I'm the root of all that's evil, but you can call me cookie..
All the other GUIs are not client-server based. Their display is intended to have no interaction with network entities. With AppleTalk or NetBIOS, when you execute a program that's on a remote system, you have the program instructions fed back to YOUR computer for execution; whereas with X, the program executes on the system where it is located, and ONLY the graphical displays are sent to your X server. This enables people to make 386 dumb terminals with 8MB video cards that hookup to one powerhouse computer (say, something spiffy from VA Linux) and provide a powerful graphical computing infrastructure.
When most people call X ugly, they're not actually referring to X. They're referring to Motif. And while I would agree that Motif isn't as pretty as some others, it's important to remember that Motif looks the way it does so it can be used with Monochrome displays (not that those are all too common these days, but it helps to understand). But Motif isn't the end all/be all widget set for Unix/X. There's also GTK+, QT, Xclass, Xaw, Athena, etc..
Others complain that X isn't easy to configure. Well, the problem here is that X lets you configure too much. The idea is to allow you to get the maximum performance from your hardware -- So X lets you tune your display. Other GUIs (Windows for example), don't allow you that fine a control over your display: they predetermine what hardware settings will be used (even if they're underperforming) and you're stuck with it. I believe this is an area where X/Unix can compete. Much like the Caldera 2.2 installation has the various skill level options, I believe an X config utility can be written which has the options (1) "Use the standard setting." (This will adjust the hardware to adequate or slightly underperforming rates (just to be safe) and set the resolution to something like 800x600x24M -- this setting would be intended for people who know absolutely NOTHING about computers). (2) "Use a custom setting." (This will still adjust the hardware to adequate or underperforming rates, but it will allow the user to customize their resolution -- this is where most Windows/Mac users feel comfortable). (3) "Use an advanced setting." (This is full bore xf86config and all the customizability that goes with it, with a nice GUI frontend and probably an option to edit the XF86Config file directly).
X is a wonderful protocol. X allows graphical applications to be run over TCP/IP from across the internet or right at your PC. X provides a uniform means of graphical communication between the Unices, and it's importance cannot be overstated.
Yeah, it'll work like CRAP on nearly anything. Whee! almost totally unaccelerated graphics! Welcome to 1987!
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Mark Stanford should be ashamed of himself for turning what should have been a helpful positive advocacy piece for X into a mean-spirited informationless attack. His points about X's strengths I agree with, but then he stoops to slinging stereotypes in place of further thought. Example: "they seem to be doing what they are doing simply in order to create something new and get their name on something". They are "egotistical types". How does Mark Stanford happen to know what is in the mind of these people? As pointed out by other posters, Mark Stanford is also completely wrong to demand that others work on whatever projects Mark Stanford wants them to work on. Even if they are wrong who is to say they won't learn something to guide them towards a better free source project in the future? Psychologically speaking, it seems to me the history is that criticism simply makes coders dig in their heels and persist (KDE). Just leave them alone to do what they want. And is there anything wrong with essay writers giving examples of what they are talking about? It seems to me Mark Stanford's piece would flunk any high school writing course. Is he talking about the Berlin effort?
The need to have different X servers for each video card is a deficiency in the way XFree86 was coded, not in X itself. This problem will be fixed in XFree86 4.0. Some commercial X servers have just one server with loadable modules for each card, some have multiple servers, it's purely an implementation issue.
While every other OS is trying to become distributed, Linuxers are trying to go back to the one computer/one user stone age paradigm. No thanks. There is no reason that the X server cannot be written to be highly optimized if it detects it is using the same machine as the display. I know XFree86 does this to some extent with the shared memory extension. It certainly could be extended and enhanced for even better performance.
Because I was interested in coding some Xlib as a programming exercise, I wrote my first X app (XTux in raw Xlib (uses libx and libXpm only) and I have to say it is a bitch to do.
Color management is completely horrible, as are fonts. Toolkits and higher level abstractions do not decrease portability, they increase it, because your programs can run on other windowing systems.
Summary of this topic :
1) A quarter of people will say that X is a slow, bloated lumbering elephant of a program that deserves to be shot. They will blame it on the network, and ask why the networking isn't removed.
2) They will be pounced upon upon by a third who tout Xs networking capabilities as the best thing since sliced ham, and waffle inanely on about how X saved them 28 yeares of work in their last job. They will carefully ignore the speed issue.
3) Another sixth will enguage in a discussion of why 'mY X $3r\/3R c@n'7 d1spl@y f0n7z. 1t $ux.' and ignore everyone carefully trying to explain it to them.
4) Another sixth will hold private flame wars about Qt/GTK, E/WM/BB, MS/Lin/BSD, vi/emacs, God/World, Tellytubbies/Pingu, flames/discussion
5) The remainder will try to persuade you to look at Y or Berlin. They will be ignored as they are clearly trolls.
CloudWarrior . "I may be in the gutter but I'm looking to the stars"
Yes, there are X servers for lots of platforms that aren't Unix.
Unfortunately they tend to be:
The OSO article makes play of the fact that X will run under Macs, Linux and even - no! but yes! - RISC OS. But fails to notice that the RISC OS X server is totally useless for any real work, being slow (even for X ;-) ), unconfigurable to different screen modes, and not interacting with the RISC OS desktop in any way.
For my crash-prone experience with eXceed, I don't think much of even the Windows X experience, either. Give me X on Unix or give me death! Erm, if you want.
Berlin and Fresco are CORBA based. As result, they are even slower than the X protocol. If you don't believe me - have your sundial ready and run some benchmarks.
:-)
Last i heard X wasnt reall a GUI, ensetad its a graphical subsystem, but that is splitting hairs... X is here today. and its standard ( more or less ).. lets keep it for better or for worse.
uhmmm... GLX = OpenGL for X.. it uses the same mechanisms to talk to the X server as anything else.
Also, you don't write a programme for DRI or GLX. You write for OpenGL.
OpenGL is the API, and DRI/GLX is the backend. So you write an OpenGL app, and the OpenGL library implements the DRI/GLX part, using whichever one is available at runtime. So an OpenGL app doesn't have to know anything about how it actually get's displayed, be it via DirectX/vendor driver/DRI/GLX, doesn't matter.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Re:No X -- we need a media-savvy, compositing GUI
The phrase 'media-savvy' makes me want to vomit.
For the purposes of this class, X == XFree86.
You're all going to repeat after me 100 times:
X is not a GUI.
X is a programming framework, a set of libraries. I can guarantee that the number of people reading this message who have actually used X as a gui, with no external widget set, probably numbers less than 10 or so.
Every X windows application is remotely displayable.
X does not support fonts. X makes calls to an external font server. That server may be cleanly integrated into what the user thinks of as 'X,' or it may be a cleanly deliniated sister application.
You can use one font server for many instances of X.
The actual GUI is supplied by something a 'window manager.' This can be as simple as a set of primitive widgets, or as complicated as a message-passing framework under a rich widget set, as in the case of KDE or GNOME.
X is not THE future, but X is a future. It is extensible. It is modifiable. It works well. The things is does not do, it can be made to do.
All that aside, yes, programming for the X libraries does suck. Programming with GTK, however, is like swimming naked in a moonlit lagoon with Bo Derek. (As in, it does not suck.)
--
Blue
i browse at -1 because they're funnier than you are.
Sure, X does some things well, but it's got a lot of baggage. In particular, to do any GUI programming one tends to use a layer on top of the Xlib/Xt/etc. stuff like Gtk or Motif because that part of The X Window System is, frankly, a big pile of doo. So you've got Nice toolkit layer, Xt/Xlib layer, X protocol layer, X server. That's a lot of junk to go through! Developing Xt/Xlib apps is such a total joke I won't even dignify it -- look at the way Swing or, *gasp* MFC, does things and tell me X in any way compares for developing a UI. I'd love to see a replacement for X that more directly supported a modern widget set. Dump some at least one of the layers! The notion that because X does some things well and should not be replaced is utterly ridiculous and smacks of some sort of "vi forever" neo-Luddite movement. That is the very thing that is destroying Unix's ability to compete in the marketplace. We should not get so attached to our systems that we ignore progress! Look at the BeOS GUI/development framework. X is stuck in the dark ages. Man, there is so much opportunity for change that is being ignored to serve the almighty X. -Kevin
Yes. By design.
Perfecting the UI is probably THE most important thing in gaining mass user acceptance of UNIX. Joe User doesn't care about whether he uses IMAP or POP3, but he does get frustrated with the total lack of UI consistency among all his apps.
But I think that throwing out X might be the wrong way to go about it. Maybe we should start from the highest level. Is there an X Application UI Style Guide document? If there were one, would it be followed?
Yes, I know, "Berlin"...a piece of software that can do nothing more than render polygons does not an X replacement make.
You should check by more often. We've got text rendering and widgets, now. OOohh... clicky buttons. :)
Yes, agreed, it's been pretty slow, but things are beginning to pick up now. It'll still be a while before it's ready for primetime though; I sure hope nobody's suggesting we abandon X until then :P
---
DNA just wants to be free...
If its so easy, fix it.
sucks. Caused a whole bunch of instability. I know the FAQ addresses this, but I think it's a cop-out (it's not our fault!). I have since been using an X Server with integrated TrueType support, and my system is rock-solid now.
You can certainly use Berlin under X (which is mainly how it's being developed right now). It's also conceivable that someone will write an X server for Berlin in the future, so the transition would not likely be that painful. If Berlin turns out good and people want to adopt it, anyway. Which I think it will.
---
DNA just wants to be free...
I think the point of this article is: X has the ability to do everything that you describe natively or with a few extensions?
However, the design of the original interfaces means that these extensions need to have completely incompatible interfaces. If you want antialiased fonts under X, for instance, you can't just extend the existing font stuff to do antialiasing -- its design won't permit that.
So, you have to create an entirely new font API, font server protocol, etc etc. Then you have to support two font interfaces for the sake of compatibility. And there's no way for legacy apps to take advantage of anti-aliasing, as they'd be using the old API. Some apps would get antialiased text, some wouldn't.
You'll eventually end up with three or four APIs and implementations of the same thing, and in fact that's already happened to X in some areas (study ICCCM sometime). To make it worse, any modern program or X server is going to have to support all of them for the sake of compatibility.
X servers are not lightweight things; it's this accumulation of extensions and interfaces that is one of the major reasons why. It can only get worse -- due to the same factors that have allowed X's rather broken initial design to be "fixed" and survive for so long, throwing out older extensions and interfaces is NOT an option.
---
DNA just wants to be free...
That's all I have to say.
> X is already a mature standard, an excellent
> standard, and above all, an industry standard.
> In addition, there is a large infrastructure of
> companies and developers supporting X
don't get me wrong--i really like X windows, but don't these arguements (and many others in the article) sound dangerously like the comments of someone speaking on behalf of windows?
while windows is by no means excellent (or even good) it is to some extent mature and is certainly *the* standard OS in terms of overall market share.
It boasts the largest availability of applications and developers, and many companies (foolishly) rely on it.
These things are by no means the reasons that X is great. X is great because it is powerful, stable, and capable. It is scalable and built for the network environment of modern computing. This is why we should support X. not because "everybody's doing it."
I hate windows as much as the next person (assuming he hates windows as much as i do...) but if we were all to support a single industry standard, it would have to be windows. hopefully, we can ditch this and support software that actually works. (i.e., X)
If you're just looking for something to coordinate the colors and fonts and similar properties, then the .Xresources mechanism works well for all things using Xt (motif, Athena & co.). If GTK and QT also respond to X resources, then the basic problem is already solved.
How many applications really benefit from a GUI? This is more or less what I want to do: code create documents surf the web email play games I don't want (or need) X. I want a wysiwyg word processor, graphical web browser, and good games ported to fbcon. p.s. I've got a clock on the wall, I can adjust the stereo with the little knob, and I don't need a background of Pamela Anderson (although she is kind of cute).
IMHO having a console underneath the window system is a good thing. DOS/Win3.x is much better than Win9x (though they're both horrible because they're from Microsloth) I like being able to have no graphics running at all if I want. With Linux' virtual terminals, you can get the same effect as having 6 xterms open (which is hard to fit on my desktop) If only there was a good console editor... but I won't get into that.
Oops-should have used the preview button!
How many applications really benefit from a GUI?
This is more or less what I want to do:
code
create documents
surf the web
email
play games
I don't want (or need) X.
I want a wysiwyg word processor, graphical web browser, and good games ported to fbcon.
p.s. I've got a clock on the wall, I can adjust the stereo with the little knob, and I don't need a background of Pamela Anderson (although she is kind of cute).
X lets me run programs over the network. This isn't a big deal for most one-computer linux users, but the minute you put another linux box on your home network (You DO have a home network, right?) it becomes important. Or if your room mate wants to run a Linux program on their Windows box, they can get one of the commercial X servers and do so. I use this feature every day at work to run Lotus Notes from an AIX box and to run assorted Linux programs from various machines in my lab. Any replacement for X would have to offer this functionality for me to even consider it.
X presents my windows the way I want to see them. I can pick any window manager I want based on either speed (9wm notably fits in a meer few K of RAM) or looks. I personally run E on pretty nice hardware at work and pretty modest hardware at home. Again, any replacement for X would have to offer similar functionality to compete.
X is intuitive to program and has some damn nice toolkits. I've always found X to be more intuitive to program than either OS/2 or Windows. It's laughably easy with GTK. And since GTK's being ported to assorted other non-X systems, my programs have a pretty good chance of being portable too.
Despite what people say about it being slow, I don't tend to find it to be slow. It is quite snappy on my hardware (Even with E and Gnome running) and very rarely slows down. I hear tell that both OS/2 and Windows run the GUI at a high priority compared to the rest of the system so that the GUI will seem more responsive even under system load but you know, you're draining CPU cycles from SOMEWHERE when you do that. You might experiment and renice X to -10 sometime and see how that affects the performance of the system.
One quibble though. I find that Motif completely blows and GTK is quite obviously on the fast track to replacing it as the standard for X programming. This can't happen fast enough to suit me. GTK offers infinitely more flexibility and looks a lot better too. The sooner everyone (Even commercial companies) move to GTK, the better off the industry will be.
Besides, why should X need to be told about it when Windows 9X & NT, MacOS, BeOS and others can figure it out for themselves? I submit that it is an itch wh. no-one cares about scratching; you get your system running with baling wire and duct tape and then it never bothers you again.
As a general rule, as little input from the user as possible should be required. The CPU has enough idle cycles to figure nearly anything out. Let it.
>As the article said, why replace X when you can simply extend it?
Bloat mean anything? By replacing X you can design out X's deficiencies and design in its limitations.
>Can we persuade UNIX vendors to use Berlin?
I say who friggin' cares? Screw all the other vendors. If they don't recognize a better framework, it's a shame. Just because it's a standard doesn't mean it is good. I thought the point was to have the best software? But it is very likely that Berlin will have an X compatibility layer (it won't get any widespread adoption otherwise). Then, GTK/QT will work, and so will all the apps, then you can start porting GTK/QT to Berlin if you want, and there ya go, a group of developers don't ever notice the transition.
I agree with everything the author said, except that I think it's stupid to try to prolong the lifespan of Motif.
X is part of what made Unix great, Motif is what almost ruined Unix forever.
I can't take any serious criticism from someone whose main argument is that we should not make new things because they're new and new things are worse than old things. New things are fun. New things give you something to play with, demonstrate, fix, extend, etc. They might even (gasp) have features the old things don't.
The point (I suppose) he might be trying to make is that berlin development (or GGI, Y windows, console DPS, YAX, or any of the others playing around in this field) "takes away" developers from other projects. This is imo a load of hooey. The more enthusiasm there is for a category of work, the more work gets done. This is free software and we _cross pollenate_. The "vanishing developers argument" is like the lame-ass argument that Gnome and KDE take away from one another. Hello! The one was invented to compete with the other, and they've been going at it like _mad_ specifically because they feed of one another's ideas. Developers work on what they're interested in and always have. These new GUI projects are the clear manifestation of peoples' desire -- not business sense or strategic planning but straight up desire -- to work on GUI software and their disappointment with what they see in X. You can't make someone un-disappointed.
I mean, almost everything we now use started off as a new playful toy in some developer's spare time. Is this really a linux user saying that we should avoid "crackpot alternatives"? how many months ago was linux considered a "crackpot alternative" to mainstream OSs? this is just the most absurd argument.
-graydon
Compared to mobile code systems like NeWS. Just think about the following and tell me what sounds more elegant and efficient: 1) draw rectangle, draw image send mouse events, when mouse click down, draw rectangle, draw image. when mouse up, draw rectangle, draw image 2) define a procedure called mouseDown, transmit to server. All drawing handled in server. Only interesting events like mouseDown/Up action are transmitted. #1 is lame ass X, or old protocols like Doom, Quake 1. #2 is mobile code systems like NeWS or Quake3 (or Unreal). The idea is to save on bandwidth (which is far more precious than CPU) by using a safe VM with mobile code that is transmitted between client/server to scale down on network traffic. It's patently obvious that it is better to trade off CPU speed in a VM so that your windowing system will be more snappy over a modem connection or even a LAN. Hell, NeWS and Display Postscript ran great on old 50Mhz CPUs, and now the average person has a CPU 10 times faster. What else sucks about X? Font support. Pathetic, bitmapped monochromatic non-antialiased fonts. Do you know how frigging easier it is to code up a great drawing/text app in GDI, Java2D, or on the NeXT compared to X and the X libraries? How about printing support? Color profile support? Color matching? Gamma? 3D? The fact is, X forces a programming paradigm on developers (and even widget libraries) that totally fucks you when you want to do high quality 2D graphics, layout, and printing. It can be done, but only by extending X or writing HUGE amounts of do-it-yourself custom code. Sure, you can say "X is just a network protocol", but the fact it, it does too little for programmers and the result was a plethora of competiting widget libraries, extensions, and hacks to get around limitations, contributing to the bloat of X and Linux apps, and the general suckiness of the X UI. Take off the rose colored glasses, roll up your sleeves, and replace it. GTK and QT could be recoded to use whatever new protocol is developed, and most apps would port cleanly. You could also run an X server on top of whatever new protocol you developed, or keep one around just in case. Needless to say, X sucks and definately needs replacement, NOT extension, to overcome it's design flaws.
(damn HTML format)
Compared to mobile code systems like NeWS.
Just think about the following and tell me what sounds more elegant and efficient:
1) draw rectangle, draw image
send mouse events, when mouse click down,
draw rectangle, draw image. when mouse up,
draw rectangle, draw image
2) define a procedure called mouseDown, transmit
to server. All drawing handled in server.
Only interesting events like mouseDown/Up
action are transmitted.
#1 is lame ass X, or old protocols like Doom, Quake 1. #2 is mobile code systems like NeWS or Quake3 (or Unreal).
The idea is to save on bandwidth (which is far more precious than CPU) by using a safe VM with mobile code that is transmitted between client/server to scale down on network traffic.
It's patently obvious that it is better to trade off CPU speed in a VM so that your windowing system will be more snappy over a modem connection or even a LAN. Hell, NeWS and Display Postscript ran great on old 50Mhz CPUs, and now the average person has a CPU 10 times faster.
What else sucks about X? Font support. Pathetic, bitmapped monochromatic non-antialiased fonts. Do you know how frigging easier it is to code up a great drawing/text app in GDI, Java2D, or on the NeXT compared to X and the X libraries? How about printing support? Color profile support? Color matching? Gamma? 3D?
The fact is, X forces a programming paradigm on developers (and even widget libraries) that totally fucks you when you want to do high quality 2D graphics, layout, and printing. It can be done, but only by extending X or writing HUGE amounts of do-it-yourself custom code.
Sure, you can say "X is just a network protocol", but the fact it, it does too little for programmers and the result was a plethora of competiting widget libraries, extensions, and hacks to get around limitations, contributing to the bloat of X and Linux apps, and the general suckiness of the X UI.
Take off the rose colored glasses, roll up your sleeves, and replace it. GTK and QT could be recoded to use whatever new protocol is developed, and most apps would port cleanly. You could also run an X server on top of whatever new protocol you developed, or keep one around just in case.
Needless to say, X sucks and definately needs replacement, NOT extension, to overcome it's design flaws.
The future == JavaOS. Stop kidding yourselves! XFree86 is a disgrace to the Open Source movement. The non-OSS commercial vendors have done a much better job writing X Servers than XFree86. Let's face it, X is hard to program. The X Window programmers have become Java programmers because that's where the money is. It's just a matter of time before the "suits" take over with JavaOS and Linux/X are no more.
True for DRI, not true for GLX. You have to write your windowmanagement code in GLX (or in something else if you don't have GLX). OpenGL is for the graphics in the window.
So you have to no something about your display to use OpenGL.
I have to say the storyline to this game sounds wonderfull - sorta like XBill, but more graphical. I will have to download it and try it out someday...
Reason is the Path to God - Anon
Your reasoning seems to run something like:
therefore:
therefore:
That doesn't wash: the first argument is flawed. X was not the first, nor was it the last, network-transparent "GUI" (NeWS comes to mind). Even Win32 is capable of network transparency -- without breaking the existing APIs! I've used Windows Terminal Server before; if it weren't hamstrung by NT's other architectural issues, it'd be every bit as useful as X.
I think it's a realistic expectation that anything that could replace X would have network transparency. Certainly, all of the alternatives I'm aware of that are currently in development do. (Y Windows, Berlin, etc...)
As far as uniform means of graphical communication between Unices, again, all of the alternatives I'm aware of build on quite a few different Unices (Y Windows, Berlin, etc...)
X and related protocols are really horribly designed; their extensability and network transparency are their only redeeming qualities. People seem to cling to these features irrationally, in the face of all the other deficiencies, as if they were some marvel of engineering. They represented some degree of foresight on the part of the designers, but they are most certainly not unique to X.
---
DNA just wants to be free...
GTK accesses X via GDK, which can be rewritten.
How IMLIB interfaces with X I dont know, I expect it has some direct connections to help speed the process.
QT is availible for other operating systems, so rewriting it for another windowing system should be easy
-Yarn - Rio Karma: Excellent
I assume he means that anything selected automatically goes into the primary paste buffer, to be pasted via ctl-ins (usually) or the middle mouse button.
-Yarn - Rio Karma: Excellent
XFree requires practically nothing. They don't have to comply with the X standard : they just choose to do so.
1) Bullshit. Anyone can join XFree86, who wield substantial influence.
2) X consortium tried to make X11R6.4 proprietary. They failed. Want to know why? Because they didn't want XFree to fork their own release, as they knew that everyone would just ignore the X consortium.
5) and 7) (which are the same point, really).
It will be as hard to push Berlin onto unwilling users as it is to push gtk+ / QT / whatever onto unwilling users.
Yes, you are biased on the subject. Please stop spreading lies about X.
Anyone know WHY X feels slower?
IMHO X feels slow because you can see separate widgets being redrawn in cases when Windows does double-buffering that works simultaneously on multiple widgets in the same window. Redraw time may be the same, but looking at static picture that changes at once makes it feel that the whole process happened faster.
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
This happens because you use relatively high-latency or slow network without lbxproxy or compressed ssh X forwarding.
Contrary to the popular belief, there indeed is no God.
11 is not a version number.
#define X_PROTOCOL 11 /* current protocol version */ /* current minor version */
#define X_PROTOCOL_REVISION 0
Contrary to the popular belief, there indeed is no God.
If I remotely start Applix-UNIX on a SUN it runs faster than a remote Applix-NT. Whether this is just my imagination or real, I dunno. I don't think this is important anyway, since it's always subjectivity that counts.
Most likely you run it over low-latency line, forwarded over ssh X proxy in compressed mode while other have high-latency line and no proxies.
Contrary to the popular belief, there indeed is no God.
When you say folks think that X is outdated and should be replaced, that doesn't really say anything about what's wrong with it. Yes, X is very old, in computing terms, but I think its longevity has proven something about its incredible capability. Not to mention, nice projects like GNOME and KDE have definitely alleviated the ``ugly and difficult to use'' situation.
Despite any problems I've ever had with X, all that goes away when I start a remote KDE session on my Windows box using the MicroImages X server. The whole remote display thing is pure genius as far as I'm concerned. And using Xnest to get a session on another box is just rockin'. I don't even know about another windowing system that can do anything like this. If there is, I'd like to see it.
My Freakin Blog
X has never looked better. We already have two excellent desktops, window managers that cater for just about everyone's tastes and are soon to get an OpenGL DRI and Xinerama.
:)
While it is a pity that X still lacks alpha channel and anti-aliased font support in the server, there is no reason that this cannot be added because X is fully Open Source. It also has the distinct advantage over its "challengers" in that it is not just vapor
There's an old saying:
"X is the second worst window system ever invented.
Everything else is tied for first."
How true that is!
Sig (appended to the end of comments you post, 120 chars)
Posted by Nr9:
bwhahahhaha
NT has MDI applications
ahahhahahhaah
MDI microsoft invented MDI
i hate MDI. don't u hate it when ure running a word processor and typing in two documents and can't have a web page on top of the bottom document and typing from the top document?
One of my friends told me that that was an SGI machine and that they really do have a 3d fm for it...he wants to see one for Linux, matter of fact...
Who am I?
Why am here?
Where is the chocolate?
What is your Slash Rating?
Actually font aliasing blurs the font out, most often making it harder, not easier, to read (IMHO). It's helpful for lines, curves, etc. but definitely not for fonts. Unless you don't value your eyesight that is.
Antialiasing doesn't sharpen anything. How can it? It's blurring it to make it smoother. And it's not a really trick of the human eye either. I've yet to see a computer graphics book that properly discusses the reasons for antialiasing. But a lot of that is because many CS types don't have a good background in Fourier analysis. The human eye, much like a monitor, is a point-sampling device. However, the human eye has much higher resolution than any monitor can hope to achieve. As a result, the lower sampling frequency of the monitor is visible as the so-called "jaggies" (high frequency transitions). Anti-aliasing attempts to reduce the impact of the jaggies by interpolating pixels to produce smoother (lower frequency) transitions graphically.
You are correct, according to their recent technology brief Amiga is using X, and AFAIK they haven't changed their mind. This makes a lot of sense, and follows along with their plan to integrate existing technologies instead of reinventing everything.
I suspect that the only Amiga specific additions will be a Workbench window manager and desktop environment, and probably a new gui toolkit as well. It will be interesting to see if they base their stuff on Qt/KDE or GTK+/Gnome, or if they do something new. There has to be something new and different in order to interest people enough to buy, and it's probably a safe bet that they're going to concentrate on the visible elements, and leave the "below the surface" stuff alone.
TedC
The good bits of NeWS seems to be one of the design aims of the Berlin project. However, so far as doing it the right way is concerned, consider that they used 'Object Orientated Postscript'!!??
John
John_Chalisque
There are a number of design flaws with X, though I think the commonly claimed ones are pure madeup nonsense. Here are some of the real ones.
--
1) X doesn't let you store "methods" on the server side. This means, for example, to draw a rounded box you have to draw 4 arcs and 4 lines. Need to draw another rounded box? That's another 8 drawing operations.
More modern windowing systems (such as Display PostScript) let you store procedures/methods on the server. You can create a method DrawRoundBox which performs the 8 operations. Then you send only 1 command to draw rounded boxes.
Server stored methods don't seem to be popular though. Probably because the server is far more complicated, needs far more ram, and in practice the overhead of the device independent language outweighs the benefits of reduced pipe traffic.
2) X uses a client/server model. All instructions pass over a single pipe. This is often (correctly) accused of being X's most significant bottleneck for performance. But most people incorrectly think the solution is to throw the pipe away.
However the pipe is only truly a hinderance when doing large bitblits, such as for games or doing an animation. The X pipe isn't a problem for any normal windowing operations (drawline, drawtext, createwindow) which constitute 99% of normal work.
If you think about it, all systems need some way of synchronizing multiple client requests to the display, and a pipe does so neatly. No serious windowing system uses clientspace functions which directly modify the framebuffer!
So the actual problem is how to keep the pipe but decrease the time spent copying pixmaps over this pipe. And remember, this is only for the benefit of programs which heavily blit the display (quake or xanim are perfect examples).
MITSHM tried to solve the problem by letting you draw directly to pixmaps on the server's side of the pipe, but you still needed to copy that pixmap into the framebuffer. No good.
DGA solves the problem by giving you full access to the framebuffer. You write directly to vidcard memory. There are no wasted copies. No problems with the pipe getting in the way. DGA wins.
Take note that MacOS/Win32 (the components which can be compared to X11) work exactly like X, with queued messages to communicate between clients + display and a direct graphics access mode for any apps that need high speed unencumbered blits.
3) Font handling in X is ancient. There isn't any way of arguing against this. X fonts were designed before scalable fonts gained popularity. Scaled fonts in X are a nasty hack onto a system which doesn't understand them.
Font and cursors were also implemented as bitmaps instead of pixmaps. This means you get black/white fonts with no anti-aliasing against the background colour. It also means that cursors look ugly and have limited capabilities.
The only solution here is to extend the protocol (ie start coding X12).
4) X has tonnes of legacy baggage. This can't be argued against either. XResources? Great idea, but don't seem to be used very much. XIntrinsics? Not a bad idea, no widget set seems to use them. XPrt? Exactly the same as GDI or QuickDraw printing, but nobody in the X world wants to use it. Support for DECNET? Throw away that baggage!
--
New extensions to X are fixing problems that have been caused by advancing hardware. DRI, XKB and Xv are all perfect examples of new advances in X that have loads of functionality and in some ways have been implemented better than commercial windowing system alternatives.
Most of the problems in X are honestly a problem with users and developers, or people's failure to understand that the X way of solving a problem is no worse than competing windowing systems. A good example of people not understanding the problem and the solution is evidenced by the neverending complaints against the X client/server pipe.
I could be talking out of my ass here, but I believe the icons are actually 48x48. Of course, the screenshot link was bad, so I couldnt check for sure... I do know that a lot of mac users were bitching over the initial rhapsody stuff when they found out NeXTStep/OpenStep/Rhapsody used 48x48 icons rather than the 32x32 icons of traditional MacOS.
Damn... and I was so particular to NOT use the term "X Windows" in the body of my text too. Gotta watch that, too easy to slip in it.
--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)
"People will pay big bucks for the luxury of ignorance."
X eats bandwidth for breakfast...sends lotsa primitives
Stating on Slashdot that I like cheese since 1997.
Hrm...about Netscape...I use Netscape with an XFree server and notice no problems when scrolling. What kinda card are you using?
:^)
:^)
;^)
15 toolkits to run *8* apps? Is this New Math???
I use apps from different toolkits, and they're all pretty consistENT, but that's because the toolkits all mimic Motif. (Ever heard of it?
I'd personally like to see the Windows machine that can run flawlessly for 8 hours
Are you a Microsoft troll or what?
Stating on Slashdot that I like cheese since 1997.
'Nuff said. :^)
Actually, no...with XDPC ( I think that's the name) X over a dialup line is quite bearable...try doing much of anything over a dialup using VNC 8-P
Stating on Slashdot that I like cheese since 1997.
We're not talking Linux, we're talking X. While we're at it we're talking advantages, not selling points. :^P
:^) that Wine on X could blow the doors off of Windows.
Quite frankly, it amuses me that, all told, despite the fact that EVERY connection to an X server is a network connection (even if the client is on the same machine) that benchmarks are comparable to Windoze systems.
I love the fact that X doesn't seem to be too much of a bottleneck for projects such as, say, Wine. I'd say, given more development (hint, hint, developers looking for a challenge
Stating on Slashdot that I like cheese since 1997.
Looks like D11 is actually a proposal for an X11 replacement, but I'll bite...
Would this be possible, what the original author of the post proposes? Would it be possible to add a special case for "localhost"? I've always wondered about this. I know that some of the paleolithic "network computers" used some kind of special localhost-only X server; perhaps something like this could be done...
Just idle ramblings.
Stating on Slashdot that I like cheese since 1997.
XF86Setup is part of XFree86, not part of FreeBSD. I use it on Linux all the time.
Confusing user interface
:) I want to see that extended to more data types in the next X iteration..
:) Putting widget sets and stuff server-side, if that's what you're talking about, is kind of interesting. I'm not sure how I feel about it :)
X doesn't have anything to do with a user interface, it's a display server. I fail to see the point. Separating the mechanism of display from the things displayed is a *good thing*.
Too much versatility, leading to overly complex or impossible interprogram communication: "cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text)
I agree, cut-and-paste with X is problematic. On the other hand, middle-button paste is way cool.
X is a non-extensible window server - in contrast to NeWS. X was based around the concept of a dumb graphical terminal, and it uses a lot of data to achieve that.
I don't know much about NeWS, but:
-> I like the iea of a fairly dumb display server. A display server just display
-> I'm not sure what you mean about non-extensible. That sounds like a problem with particular implementations -- there are various X extensions floating around (such as OpenGL, shared memory, and other things)
X programs have lots of nasty user interface problems, including X configuration.
That's an application problem, not X's fault.
X has bad hardware support - This is out of place, isn't it?
Sounds like a problem with particular implementations to me.
X isn't device independent, or maybe has a limited graphical toolkit? "Drawing arcs is probably impossible in a portable fashion."
They may be referring to colordepth handling, which is a definite problem.
Other criticism I've heard that the X protocol should take advantage of the locality if the client and server are operating on the same machine. This only makes much sense to me if the cpu overhead in dealing with the network protocol is noticeable; being able to transparently work from another machine is too nifty to throw away.
I really think this is a baseless comment -- I haven't heard any solid explanation of *how* X would 'take advantage of the locality'. Given that we have a client-server model, there must be a mechanism of communication; this is almost certain to be a stream protocol, and indeed X uses UNIX-domain sockets. These tend to be extremely efficient for almost everything; those programs that really need more bandwidth can use DGA or SHM. (even on a totally non-accelerated server -- fbdev -- SHM gave me a good framerate in the Myth2 demo)
In general, I feel that the UNIX-hater-handbook folks are a lot of people who were frightened by sh as a child or something and now feel that their purpose in life is to make snide remarks about UNIXy systems without offering any real suggestions for improvements. Which I guess is why it's called 'the UNIX Hater's handbook'
Daniel
Hurry up and jump on the individualist bandwagon!
No! No, no, no, no, no! This is the job of a printserver and a printing library (maybe the widget set) -- not, I repeat NOT the display server! The display server displays. The print server prints. The mail server mails. The foo server 'foo's. This is a Good Way to do things.
:) But it's not X's fault.
Gnome's solution here is (IIRC) to make the drawing canvas support multiple targets, one of which is Postscript to be sent to the printer.
That said, print support in Linux sucks.
Dnaiel
Hurry up and jump on the individualist bandwagon!
Um, this has absolutely nothing to do with X itself. X just draws what programs tell it to, if they don't tell it to draw menus when the user clicks that's their problem. You want more integration between the WM and the programs.
Daniel
Hurry up and jump on the individualist bandwagon!
HOWEVER X really doesn't "feel" as fast as my win95A partition (needed for school) on my computer. The mouse seems sluggish and jerky (very much like when playing 8 player starcraft on it (p120)). /dev/mouse. I think reaction time to mouse clicks is no more in X than in Windows, but the mouse seems like it's moving more slowly.
:)
Anyone know WHY X feels slower?
Probably because X is just a normal process, while the Win95 GUI is partially integrated into the kernel. This means, in particular, that the mouse doesn't move until X is allowed to read from
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
As I keep pointing out -- given a client-server architecture, no-one has suggested out a realistic alternative to some sort of stream protocol to communicate between them. UNIX sockets are extremely efficient for most cases, and SHM is available for things (ie, big pixmaps) which need more bandwidth. Once you have one stream protocol, though, you can generally support TCP with a trivial code change (most operations have the same semantics on any socket-based connection). The small bit of extra code won't be loaded into memory if you don't use TCP so it's not a loss that way. In other words, network transparency really doesn't hurt a local-machine situation much. Now, you can argue about what is transmitted over the network (some people think the display should be abstracted at the widget level..I don't, but..) but network transparency itself is a Very Good Thing. [tm]
Also, i think it would be a good idea to wait for V4 to come out before we switch to a faster windowing system.
AFAIK, X is currently at Version 11, Revision 6. (hence X11R6) So you're a little late
Daniel
Hurry up and jump on the individualist bandwagon!
by starting over again with hardware acceleration on every drawing function and modern programming techniques like multithreading and message queues, :) )
:-/
The only thing I can see helping them is multithreading..message queues, AFAIK, aren't much different performance-wise than pipes/sockets like X uses and probably are worse than SHM (although I'm sure Berlin supports SHM) -- and I believe X can already hardware-accelerate everything if it chooses, no? (yes, I don't fit your criterion for replying, but the thing about message queues was too much
BTW, how is Berlin coming? Last I heard there was celebration because they'd gotten it to draw two overlapping triangles on the screen or something..
Daniel
Hurry up and jump on the individualist bandwagon!
2. Device transparency which has true WYSIWYG support for all devices. The code which talks with the screen should also be able to talk with my printer, plotter, network, etc. What I display on one device must look the same on another device within the bounds of that device's capabilities.
I think this should be the job of some document-rendering engine (like GnomeCanvas) rather than the windowing system. X is just a server to draw on the screen. Trying to make it replace lpd is a Bad Idea..
Daniel
Hurry up and jump on the individualist bandwagon!
It's worth noticing that the network model IS being worked on in X4, with the Direct Rendering Infrastructure (Interface? I've forgotten already.)
:)
Wow, I must be really advanced..I seem to be running X11 here..
We have QT and the GTK, and Motif, and some other toolkits, but there's no unifying conceptual interface.
Whether this is good or not, this soapbox is (or should be) totally irrelevant to X itself. X's strength is its simplicity: it draws stuff. This is a fundamental concept in UNIX: make small, specific but general within a specific area, and powerful tools. If X is to be replaced it should be with another general-purpose display server, not something which thinks that the only thing you want to draw is a button.
Daniel
Hurry up and jump on the individualist bandwagon!
No sound support in X stream. I can export my display to a remote machine and work great from there -- until I want to do audio/input or output. Then my sounds comes out halfway across the universe. Great. ...)
X is a display server. It shouldn't be in the job of playing sounds. You need a sound server (NAS, rplay, ESD,
No 3D support. You can graft OpenGL on top of X, but then you've got this kludge with two APIs. The OpenGL API has nothing in common in the Xlib API. Weird. This should be unified.
No! OpenGL's strength is that it code for it can run on many systems. For example, it can be integrated into X..or Win32..or BeOS..or Hurd (well, not yet)..or..or..
Gross design. Does the protocol *really* need that many things in it? Can't we abstract some of that into a higher layer? Ugh.
My impression is that it is intentionally general-purpose and low-level; it's a protocol for drawing on the screen. Widget sets are for higher-level operations. (there are some interesting ideas of 'widget servers'..berlin being the most obvious one..but I don't think you can cut out the low-level stuff without hampering the client's ability to decide what to do)
Daniel
Hurry up and jump on the individualist bandwagon!
[compression snipped..it would be a good thing although it's not critical]
:) )
And from what I hear other people saying about the protocol, there is some room for simplification.
I'm generally careful about what I hear people saying..there are always people who dislike a system and then come up with explanations. (not that that's necessarily the case here, but in general
Efficiency. The protocol needs to make better use of information already sent. Invalidate-areas would be great. Additional primitives to do basic stuff like BitBlt could help things along.
Maybe I'm confused, but Expose events already give the exposed area and there is a pixmap-copy operation unless I miss my mark..
Common controls aka widgets. You shouldn't need a toolkit to draw the standard user interface. There is a lot to be said for a few simple controls built into the standard. (This might be a "layer" issue--do they go in the window manager, the toolkit, or the GUI?) I think widgets belong in the GUI so every programmer can depend on them being there. I've seen 10 different shapes of buttons, 3 major types of scroll bars, etc. etc. Make it standard, so the programmer doesn't have to worry about it, and the user understands what they see!
Repeat after me:
X IS NOT A GUI!
X IS NOT A GUI!
X IS NOT A GUI!
X just draws stuff on the display. Agnosticism about GUI style is one of the things that makes it so flexible.
Daniel
Hurry up and jump on the individualist bandwagon!
Excuse me, but this is completely irrelevant. X is a network display system and has nothing to do with your sound card. NOTHING! If you want a network sound server that's great and I think it's a worthy goal, but it is not a deficiency in the X server that it doesn't have a sound server welded to it. If nothing else, people using text-mode or other windowing environments might want sound as well!
Daniel
Hurry up and jump on the individualist bandwagon!
(I'm using traditional, rather than X notions of client and server)
Um. A server is something which accepts connections, takes requests, and Does Stuff (possibly returning information to the client). This is exactly how X works: a client conencts to the server, requests that the server do things for it (in this case, draw on the screen), and the server does it. There's nothing backwards about this at all.
Daniel
Hurry up and jump on the individualist bandwagon!
This has nothing to do with X. X just displays stuff on the screen. Saving state is the job of the client libraries/session manager. (none of which work right but that's a separate argument)
Daniel
Hurry up and jump on the individualist bandwagon!
X is, currently, pretty much as you say, "a network [video] display system". But it's also the core piece of software for user interfaces. Audio I/O is an important component of the computeruser I/O interface. And it's only natural that X should be extended to be a truly multimedia display system.
:) The only benefit of putting audio into X is that you could easily coordinate audio and video. This is something that should be addressed, but putting audio in X is a nasty kludge; some sort of general way to synchronize X with other systems is a better way to do things IMO. Small discrete systems are more correct, and a more correct system is more user-friendly *in the long term* because of flexibility and stability even if a hack will be better in the short-term.
:)
No. That's Windows thinking
And I still want to be able to play audio from another machine without running X.
Daniel
Hurry up and jump on the individualist bandwagon!
I haven't had a chance to see the shared memory or OpenGL extensions; I heard that extensions have to be compiled in and I postponed it indefinitely.
:) (although this doesn't work in a window) I don't know how DRI works; SHM needs at least two copys (app to SHM segment, SHM segment to display). I'm not sure you can really do much more (someone could correct me of course :) ) without jeopardizing the stability/security of the system. (non-exclusive direct writes to video memory are really dangerous)
Which distribution are you using? I think Debian ships them either as modules or compiled in (I think XFree doesn't support modules yet so they're probably compiled in)
Hardware acceleration/locality: Playing Quake2 over 10baseT is awkward; that's an area where client/server could definitely use an intelligent terminal, and avoiding streaming over a socket if possible (yes, bypass client/server entirely). It's a bit of an extreme, I know, but video and games should be no challenge whatsoever for Linux and X.
Video and games can use OpenGL, SHM, DGA, etc to bypass the usual mechanisms. SHM and DGA speed up blitting on the local machine; OpenGL (as you know) provides a graphics-drawing interface with much support for hardware accel. The really nice thing about OpenGL is that (er, I think) it can actually (!) be run network-transparently; I don't know exactly what sort of performance you get with (eg) Quake but some modeling programs at Brown run quite nicely over the LAN.
I have been wondering how multimedia (specifically, video) can be added to Linux and X. Streamlining seems necessary to me; a video extension, perhaps? Or a window manager (see NeWS) that handles different protocols? Or would you guess that shared memory can handle these efficiently? I just want to see the multimedia capabilities of Amiga added to Linux, and I'm curious about what is preventing that.
I think that things like DGA/SHM and DRI can help a lot. Since with DGA you're basically writing to video memory directly, you can't speed up much more than that
Daniel
Hurry up and jump on the individualist bandwagon!
It wastes some. It goes as much as 5 to 10% slower because of it.
That is about it.
Ha! Try ``an order of magnitude.'' Where did you get this idea?
For that matter, where did *you* get *this* idea? Have you benchmarked?
Further, exactly what do you mean? I agree that communication speed may decrease by quite a bit, but that's not directly correlated to *display* speed. Individual pixel operations are slow, Quake shouldn't use the X pipe. That's obvious. It's slightly less obvious that this is a significant problem for other programs. Sockets are slightly slower than direct memory copy, but unless the video card is *really* fast I suspect the time spent servicing a request far exceeds the time spent in the request. (I haven't benchmarked this either)
Finally, it is my observation after using it that X is not an 'order of magnitude' slower than other display systems -- at worst, 5-10% is a reasonable estimate.
Do you have a constructive suggestion for improvement or are you just getting a kick out of making snide remarks? Having a well-known email address doesn't mean you can simply make insinuating remarks with no explanation to back them up.
Daniel
Hurry up and jump on the individualist bandwagon!
WindowMaker- Quick, feels light and stable. Just not that flexable. For instance, you can't maximize a window to full screen and then back to a small window. It just doesn't have the features of GNOME or KDE.
:) I switched to Enlightenment for a while, but it didn't seem as solid, either in terms of widget layout/animation, design, or features. WindowMaker's themability is enough for me.
Actually, you can do that. You can also hide all windows associated with a program, something incredibly useful that I haven't seen anywhere else. The dock is also pretty cool -- it's similar to the panels. WindowMaker also has Gnome-compliance; in fact I have Gnome panels hanging around on my screen right now
Daniel
Hurry up and jump on the individualist bandwagon!
I actually like this..it drives me crazy to have to go and select paste. On the other hand, it is sometimes a nuisance the way X does it too. I wouldn't say 'dated' as much as 'different'.
I think it would be nice if support for both mechanisms could be added, but that's nontrivial..
Daniel
Hurry up and jump on the individualist bandwagon!
GNUstep is almost to the point where serious OpenStep porting and debugging can take place. (The text system is in flux right now; when that's over, I think it'll be ready.) This means that people writing new Macintosh applications will have a relatively easy time also targeting Linux; Macintosh software developers are the best in the industry when it comes to building usable, consistent interfaces to high-quality end-user applications. (Hey, I'm allowed a little egotism, aren't I?)
What's my point with all of this? It means that X isn't necessarily as entrenched as you think it is. GNUstep runs on X right now, sure, but it could also be made to run on a sane display subsystem without affecting application-level code. So the situation isn't quite as hopeless as it seems.
My prediction: If there is half as much effort put into Display GhostScript and GNUstep as there is being dumped into XFree86 and GTK and GNOME and Qt and KDE right now, X can be put on life support within two years. And there'll be a resolution-independent, device-independent, network-transparent window system with a sizable base of consistent first-tier end-user applications and a very elegant programming interface to show for it.
Most of the time in OpenStep application development you don't need to write real PostScript code. If you do need to do drawing, you call functions like PSmoveto() and PSlineto() that send messages to the DPS server. You can also write "pswraps" -- PostScript procedures that get compiled into a chunk of code that you can call from C, which when invoked send the whole chunk to the server at once. (This can improve performance because you reduce the number of round trips/context switches required.)
In Mac OS X, because it uses Quartz rather than Display PostScript, the PSxxx() routines should still be usable but pswraps are going away.
Incidentally, one of the reasons Apple is dumping DPS (besides Adobe's outrageous licensing fees) is to get better performance. They're doing this by making most of Quartz a client-side library that draws directly to the screen (or the backing store). They say they're leaving hooks in so remote display can be added back later; of course, some people are freaking out about that, but IMHO Apple has their head on straight. Optimize the common case, make the uncommon case possible.
X? A standard? What planet do you live on?
There are two standard graphical interfaces in the personal computer industry. The Macintosh interface is the one every other interface tries to be, and the Windows interface is the one most people use. X isn't even on the radar.
(And yes I know there are people who will insist that it isn't X that's the interface, it's KDE, or GNOME, or CDE, or some other crap. They can bite me. X refers to the whole ball of wax now, no way around it, no matter how much semantic BS you try to invoke.)
I'm glad to hear that.
The last time I mentioned something about Berlin and its strong linux ties, I was told that all the commercial Unicies are gonna fall by the wayside and only Linux mattered.
- Over-reliance on bitmaps.
- Context switch on all drawing apps.
- Lousy color handling. IMHO X's replacement should ONLY support 24bit color. Let the server decide how to draw 24bit colors on a 256-color display, not the app. This might cause problems with graphical programs, but would be a better interface for the vast majority of apps.
- Primitives are too low level. Higher level primitives allow the X server more optimization opportunities with fast video cards.
- Wonderfull usefull cruft that is no longer used, like the stuff that supports resedit.
- <FLAMEBAIT>No sound support!</FLAMEBAIT>
That should do it for me...This is the root cause of the no-anti-aliased fonts problem. Since a lot of the primitive Server-side objects are bitmaps, including fonts, they can't be extended once better ideas come along.
Since you have to tell the X-server what to do even in the local case any drawing requires a context switch. Not doing things synchronously helps, but the answer is that the Xlibs should be able to do some of the drawing directly. I believe that this is a partial goal of XFree86-4.0, but I'm not sure.
Seriously, that's not an X issue but a clean networked sound standard would be a good thing. Especially one that allows dynamic mixing.
Doug
There is definitely a lot of mileage variation there. I'm a lot more productive on my Indy (running fvwm2 rather than 4Dwm) than on my NT box with four times the horsepower.
The NT interface is great for its emetic properties, though.
"Be nice, veer left, and never stop thinking" Iain Banks - Walking On Glass
What in the world do you mean by this?
Genuinely curious,--Q
Beer recipe: free! #Source
Cold pints: $2 #Product
UNIXUX: click on the cursor
The X-Windows Disaster
-- http://www.cs.mcgill.ca/~zibalatz/
The reason I am asking as I proposed this as a possible bypass to a complex remote Citrix setup at work, but it doesn't seem to be available on the target Sun machine(s) (where the X applications live) - and so I never had a chance to try it out...
--
An esoteric scratched itch:
Homeworld Map Maker Tool
PM had numerous technical problems, the SIQ
being most notable. Most of the good parts
of PM were very high level, and could be
done by a well-written window manager.
For every problem, there is at least one solution that is simple, neat, and wrong.
1) Better network transparency -- something akin
to ssh should be built-in, except modified
so a single channel can transparently
have new applications connected through
without needing to do it via the shell
on the other end. This would eliminate
the need to ssh multiple times. Ideally,
the connection would be handled by a
library instead of a terminal application.
Also, ideally sound would be handled by
the same mechanism.
2) Window Manager agnosticism -- We've all gotten
too used to our favorite window managers
to move to a single one, no matter how
wonderful it might be.
3) Ideally, more of the frontend of applications
would be run on the client, to minimize
communication. This could be accomplished
a number of ways, but a simple way would
be to have multiple application modes, one
of which would tell the client (I'm using
traditional, rather than X notions of
client and server) where widgets are and
only generate events when the mouse is
over the widget. Several other modes for
different kinds of programs would be
needed (consider Xeyes)
3) Automatic dithering and a single color API that
acts like truecolor.
4) A way to nicely disconnect a running
program's GUI from one client and then
resume it elsewhere (to some degree this
relies on #3)
For every problem, there is at least one solution that is simple, neat, and wrong.
What an excellent suggestion.. it seems like the best way to get to a better place would be to extend X to X12 and include a more rational color and font system, and to include audio, and retain X11 compatibility for existing apps (an absolute must, really.
No, this won't get rid of X bloat, but it will allow programs written to GTK/QT to have a better substrate to operate on. Of course, high-color displays and the sort of stuff coming in XFree86 4.0 is already going a long way towards a better tomorrow..
- jon
Ganymede, a GPL'ed metadirectory for UNIX
No, it's not entirely X's fault, but X doesn't lift a finger to help. Windows and Mac both have a common graphics model for printing and on-screen imaging, and it's silly that X has nothing similar. Yes, you can go up the chain to GTK for this, which is good enough, but it's silly that we've had to wait 12 years to get libraries that will allow on-screen display and printing.
It wouldn't hurt my feelings at all to have a display model based on PostScript or PDF or something sane, but junking X totally is not an option. If we depend on GTK for a high-quality imaging model, though, that means that a lot of the rendering decisions will be made on the wrong side of the client-server pipe. Java 2 does this, and it lets you have a nice and powerful and consistent rendering model cross-platform, but performance on X sucks beans because the X server is basically acting as a dumb framebuffer for pixel-level operations.
That just doesn't cut it. There should be a rich drawing model that can be effectively supported by the rendering server and which can be retargeted in library code to PostScript or any other printer imaging language.
I wouldn't mind seeing Java 2's imaging model made part of a next-generation X protocol, but I don't know whether everyone has enough experience with Java 2 and whether its Graphics2d model has stabilized enough to re-implement it with pixel-precision in C for a graphics system.
If Java2's Graphics2d model was stable enough, and if the ownership terms could be worked out, I'd love to see Java2's model supported on an X type server.. would speed Java code greatly, and would provide a rich and powerful (PostScript-level) imaging model.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
It's been 5 years since I've done any Xlib/Xt coding, but the biggest problem I remember is that the color model blows chunks on palletized displays.
With Windows, each app indicates what colors it wants, and all graphics operations are done using a handle to the color returned by the graphics system. If another window is in front, the windows rendering layer will automatically dither and/or approximate colors in the background app to maximize color fidelity using the common color map. A similar process is done on the Mac, I believe, with dithering and approximation done for the coder by the graphics layer.
X Windows is different. With X, a program on a palletized display allocates color cells which come straight out of the hardware palette. When a program asks for RGB FFF083, it will get back a simple integer, '5'. From that point on, all rendering done by the program is done using color 5. If the 256 colors are exhausted, the system may try to return color '16' if it is close enough to the requested color, but the system can't change how the program does its rendering behind the scene to give the front window a better color fidelity than the background windows.
This is why Netscape users on 8bit displays are stuck between either running into color starvation extremely rapidly, or forcing the Netscape window to use its own color map, causing horrendous false-color flashing when the window is selected or de-selected.
This problem may thankfully be a thing of the past with modern video cards, but it was always one of the big ugly achilles heels of X. The Athena widget set, font system, and Xt resource complexity were the others, but fortunately we're finally getting away from Xt and all that ilk.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
--
"Convictions are more dangerous enemies of truth than lies."
I don't suppose you feel like writing a simple app that uses all of the XShape extention features so that I can figure out how to use that one as well, coz that one has me beat entirely, the man pages and xc documentation on them are scanty to say the least,
C.
I sometimes write stuff
This D11 idea is a new one to me until i saw it posted here earlier.
C.
I sometimes write stuff
Some of us uses laptops (like mine IBM 600E) that only has 2MB builtin vidoe memory. NON-upgradeable. And I like 1024*768. It doesn't help to change supplier either, as most laptops that can be carried only support 2MBs. Think before talking.
-- Roland Buresund MBA, MCMI, CISSP
The problem with MacOS is that other than that, it sucks. The system itself was designed for use on tiny microcomputers, and retrofitted into a workstation role. There is no command line and no scriptability. The tangle of APIs and Managers grows more impenetrably dense by the day. Not to mention that the system is unstable (no memory protection, for example), inefficient and so different from everything else to make programming a nightmare.
From an end-user point of view, it's very pretty, and better for most things than Windows 95. Look any deeper and you see its rotten guts.
(I own a Mac and use MacOS, mostly for running various media applications. I've tried programming under it, and after UNIX, it's a pain, even with tools like CodeWarrior.)
Not to mention NeWS. Another client/server windowing system from the late 80s/early 90s. Only NeWS did things The Right Way. Rather than simply throwing dumb requests and responses back and forth, a client application could send Display PostScript code, which would live in the server and handle UI aspects.
Of course, back in those dark, unenlightened days, Sun (the owners) either demanded exorbitant licencing fees for the technology or just refused to licence it, thinking that being the only ones with NeWS gave them an advantage. And so, sadly, NeWS died.
The inventors of NeWS went on to create another client/server system, albeit one with a different scope. We know it as Java.
Have you ever programmed in PostScript? It's a remarkably elegant language.
Different name, same difference.
X.Org Becomes X Technology Steward Industry consortium to guide the future of the X Window System
Menlo Park, CA., May 12, 1999 - X.Org, a newly formed organization of The Open Group, has today become the official steward of the X Window System technology and the technical experts for the X Window System standards. Member companies include Compaq Computer Corporation, Hewlett-Packard Company, Hummingbird Communications Ltd., International Business Machines Corporation, SGI, Sun Microsystems Inc. and many others.
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
(I'm curious, what are those non-xterm tools?)
The ability to admin machines remotely is obviously a great feature. But X decided that it was such an important feature that it had to be built into the window system at such a low level that local access pays the price: that is, that it was more important to be able to use the machine down the hall than to be able to use the machine on your desk!
X could have been designed to be efficient locally, with remote access being possible but slow. It wasn't. It was designed in such a way that local and remote access are about equally slow (if you have a fast local network, which was another fundamental assumption of X.)
Wouldn't it be better if remote access was a dog and local access was fast, instead of both being a dog? That's how other window systems do it.
The idea that the way to do network transparency is to have the remote machine be the one tracking the mouse is just crazy. It would be far better for all GUIs to live locally, and for the on-the-wire activity to happen with some more domain-specific RPC, or other services.
(Like, for example, through a web server. CGI is a great example of how to do remote operations while keeping UIs local, and doing it portably as well.)
SGI has a great X server, and it's a credit to them that they made it go as fast as they did (I've never seen a better X server than SGI's.) But it's still ridiculously slow, given what their hardware is capable of! You only have to compare X performance to GL performance to see this.
Guess what, Netscape doesn't (and can't) use XCopyArea for scrolling. Because that just moves bits, not subwindows (think form elements.) Netscape plays crazy tricks with window gravity to move all the windows at once, since the alternative (moving each subwindow by hand) is insanely slow.
But probably the reason you see flicker isn't really X's fault, but is because the table redisplay code isn't great.
I hope you're right; that would be a very good outcome.
It does give me some hope that MacOS X is looking so Unixy, because people who have experience writing Macintosh applications just will not tolerate the kind of UI free-for-all that X brings to the party, so maybe they will actually do something about it.
I don't know about that; I don't think that rescuing all of those NeXTstep applications will really make that big an impact, given how marginal NeXT has always been in the market. It's a nice looking system, no doubt about that, but that doesn't mean it's ever going to catch on.
I'm also somewhat dubious of Display PostScript. I've done a lot of PostScript hacking, and it's frankly a lousy language to program in. (It's a great page-description language, but these days I really believe it's more suited to use as an output format than to use as a language you would actually write code in, and debug.) Of course, I haven't actually hacked on a Display PostScript system, so maybe the DPS APIs are different enough to make it bearable. I don't know. Would someone who has hacked DPS care to comment? Do you end up actually writing PostScript code, or is that hidden behind the scenes somehow?
Well sure -- if what you're doing doesn't require high performance graphics, then the fact that X can't deliver high performance graphics doesn't much matter, right?
It's certainly true that most applications don't require high performance graphics. But when you need it, you need it. And X can't deliver.
This, of course, is The Way of X. Got a problem that people have been suffering from for ten years? Fix it by adding yet another new and optional API! So now all the applications writers get to code their graphics routines twice, with lots of runtime feature-checking. Have you ever written X code that made use of XSHM, the shared-memory extension? Did you do it in such a way that your program actually worked when the extension didn't exist? Are you sure? Did it still work when the extension existed on the server, but the server was on a different machine? Are you sure? (In my experience, 99% of the programs that try get it wrong.)
This is no way to fix a bug. X's refusal to add required features to the protocol (SHAPE is still optional, for pete's sake!) makes life hell for application writers until the end of time. Or leaves users with applications that mostly work most of the time.
The fact that the window manager is not built into the server really doesn't have much to do with the client/server model. In a Windows-like library world, the window manager could as easily be a pluggable DLL with the same effect, but without taking the X hit of all the context switches and network traffic.
Nice words, coming from someone who's too chicken-shit to attach their name to them. Don's one of the smartest people I know. Who are you and what have you done?
Actually, quite a few of the xscreensaver hacks behave very differently on PseudoColor versus TrueColor: the difference will be that, when a colormap is available, the whole screen will be alive with motion, and when there is no colormap, the screen will be pretty much a static image. There are some things you just can't do fast without colormaps.
Another reason for using 8-bit depth is speed: that's 1/4 as many bits that the server has to move around. You might expect that this wouldn't be a big deal, but it turns out that it is. The difference really is perceptible: there are a few hacks in xscreensaver (``compass'' comes to mind) that very obviously run 4x faster in 8-bit mode than in 24-bit mode. Sad but true.
SGI got this right, of course, by having an X server that allows 8-bit-deep colormapped windows and 24-bit-deep non-colormapped windows to exist side by side on the same display. That way, each application can pick the color depth that is most appropriate to its task.
Ha! Try ``an order of magnitude.'' Where did you get this idea?
WTF? Do you recompile libc every time you compile your program? Are you aware of how libraries work?
I am most certainly not talking about ``dumping the functions that get in the way'' or ``running on the bare metal.'' There's a world of difference between having every application have hardware-specific knowlege; and having every application use proper high-level abstractions, but having the implementation of those abstractions not involve handshaking between multiple processes!
What's this supposed to mean, besides being a dig against the fact that Windows doesn't have memory protection? I think you're confusing memory protection and the client-server model. Neither implies the other.
Maybe you don't realize this, but any X program can scribble on the windows of any other X program. Or even free resources allocated by other programs, causing them to get X errors and (usually) crash. It's not particularly easy to do this by accident, but X does nothing to prevent it (in fact, it's explicitly allowed.) Once you have a connection to the display, you have free reign.
The client-server approach buys you nothing in terms of stability, security, or portability. Those are all orthogonal issues. All the client-server approach buys you is network-transparent graphics.
Likewise, having an implementation that gives you in-process access to the frame buffer (and the ability to do graphics fast) does not imply lack of memory protection. Remember that these clients are still going to be doing their drawing through high-level APIs, and the implementation of those APIs can do whatever bounds checking is appropriate. The X server does such checks internally anyway -- in addition to all the IPC overhead.
I agree, but...
"-*-courier-bold-o-*-*-*-120-*-*-*-*-iso8859-1"is actually what you should be using, if you want your resources to have a better chance of being portable from one machine to another. That X's font names are verbose doesn't mean you need to specify all those fields.
X doesn't require that level of detail. However, neither does it make the operation you described easy. This is largely because there aren't a set of library routines for doing things like asking for a similarly-sized font in a different face, or the next-larger font size that is displayable and/or looks good.
I'm sure lots of people have rolled their own solutions to this over the years. I did it once in emacs-lisp, and did it again twice for Netscape (which is on its third or fourth version of the font-selection code now, so if you still hate it, it's not my fault any more...)
X's font management is lousy in many ways, but I don't think that its long font names are a problem.
SGI uses X, and they have an X server that is insanely optimized for their hardware. On top of that, for anything that actually needs to go fast, they use GL instead of X. Basically, they use X to allocate a rectangle, and then X stays out of the way. The GL library then talks to the hardware directly, without a zillion context-switches in the way.
I get that idea from having spent ten years trying to squeeze every drop of performance out of X programs as I can. The inefficiencies that the design of the X protocol forces on clients are just staggering! All the handshaking back and forth between the client and server (and associated context switches) adds up really quickly. I see it every day -- I see operations that are fast in every window system that preceeded X slowing X programs to a crawl, and because I know X inside and out, I understand why. It's no mystery to me, it's because of the fundamental design decisions that went into the X protocol on day 1.
I have not done bechmarking, because I have had no reason to. I know X is slow, but I also know I'm stuck with it. However, if you want to try it out for yourself, try and do some simple 2D graphics that do double-buffering using Xlib. Now rewrite that same program using OpenGL (note that we're talking about 2D here, not 3D, no textures. Just line drawings.) Code both programs such that it replaces the image as quickly as it can, yet results in no perceptible flicker. Tell me which one runs faster. Here's a hint: it's the one that can touch the frame buffer in-process, rather than having to suck bits through a straw. (Use the joke of the X Double-Buffer extension if you like, and the XSHM extension. It won't help.)
Obvious, is it? So what you're saying is, ``Quake shouldn't use X.'' Which is to say, ``X is unsuitable for anything graphics-intensive.'' Which is my point.
You're missing the point again. It's not just the fact that there's a pipe involved, it's the fact that there is synchronization between multiple processes: one writes, and flushes, and then some time later the other becomes runnable, and eventually gets around to reading from the pipe, then talking to the hardware, then writing a response, then flushing it, and eventually the first process becomes runnable again and...
When window operations are involved, you often have to block waiting for answers from the window manager, resulting in a three-way cluster-fuck between the client, the server, and the WM. Oh, but isn't it great that they could be running on three different machines? Whatever.
Ah, we've reached that point already I see. We always get here whenever the failings of X, Unix, or anything else Linux weenies hold dear are discussed: the fallacy that, before one has the right to point out a problem, one must have already handed the world the solution on a silver platter. Well guess what, the fact that we're stuck with X forever (because it is completely entrenched) does not mean that X has no problems, or that those problems are not severe. There appear to be some people, like you, who don't understand the extent of those problems, so don't bitch at me for pointing them out, ok?
Bite me, fanboy.
I've also heard a fair number of people complain about X's API and the basic toolkits (Xaw) and how ugly and kludgey they are, but that's what things like qt and gtk are for.
--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)
"People will pay big bucks for the luxury of ignorance."
X's greatest strength is far andx away its configurability. Pair it with enlightenment, and you can almost literally draw an interface out on paper and have X look and feel that way.
If it's possible to have too much of a good thing, though, this is it. X is great for configurability, but it goes too far. Without any sort of "standard" toolkit, window manager, or any such thing, there's no standard sort of interface on which a user can rely. This isn't saying that configurability isn't bad, it's saying that if you're going to make something configurable, you need to set defaults too. X doesn't do that. Consider the multitude of GUI toolkits, three or four drag-and-drop protocols (all of which are incompatible), four desktop environments which don't even share common API's on most things (meaning that support has to be written into an app four times if the author wants to support everyone), and so forth.
X's major weakness, though, is its age. Now, old software isn't necessarily bad. It all depends on how far ahead the developers think. X's original developers thought ahead several years. Problem is, those years ended quite some time ago. Things like drag-and-drop, inter-application messaging, text antialiasing, support for TrueType fonts, and such never made it into X. They've come in since as bolt-on solutions, but these things are so vital to a modern GUI that they really ought to be rolled in (which you can't really do without shelling out obscene amounts of money).
I don't know. XFree 4.0 appears to address some of these concerns. I'll still be giving Berlin a spin when it's usable, though, if only to see if it's a better system.
X is actually a really efficient protocol for what it does. Very sparse.
As for remote apps.. X rules in this dept. I find that nothing can come close to X for performance. Things like pcanywhere, carbon copy, etc. have a noticeable lag. (caveat: every win32 Xserver i've tried is slow.. XFree86 on a 486-33/32MB is a magnitude faster than X on win32 on a P11-450).
With X however is impossible to tell whether apps are remote or not. Also, X is perfectly feasible over 33.6k modems for simple Xt type apps (xterm, etc), and even complex apps if you use lbxproxy.
I once ran Netscape 3.0 from a computer in scotland over the internet displayed to my computer in ireland (connected via 33.6k). Took a heck of a long time to draw (~5min), but from then on it was useable (with a little patience). And that was just plain X. I didn't even compress it with lbxproxy or ssh! Try that with anything else and you will not get anywhere.
As for those who argue that "X needs this, and needs that, And that the fact that they weren't included means it must have beem badly designed": The intention was to provide a basic protocol, which could be easily extended, so it's meant to be like that by design.. want Direct rendering? -> extension. Owant penGL?->extension, DPS.. etc.. by design.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Specifically, I thought about the laptop sitting next to me as I posted, with 8MB video RAM. Granted, that's not as standard on new laptops as on new desktops, but it will be very soon. RAM (even the cool RAM your video card uses) is cheap and small - there's no reason not to use a ton of it.
On the other hand, there are a lot of old laptops out there that aren't upgradable, at least not in the video chipset. If you can upgrade the system RAM (or have enough to begin with), running two X servers at once in different bit depths is a useful workaround. Depending on how you work, that may be less or more convenient than flipping desktop settings back and forth.
Ok, granted, font anti-aliasing would be nice and needs to be added (although current improvements in the existing renderers are visually helpful without antialiasing), even just as an extension for future applications.
But is it really such a big inconvenience in this day and age to be unable to change color depths on the fly? Being able to go from 800x600x32 to 1152x768x8 (or whatever; I haven't done the math) might have been important when trying to balance out resolution vs. color depth on a 2MB video card... but every video card in every new computer or store shelf today will do 16 million colors in any resolution you please, and there's just no reason to use a non 32-bit color depth. There's that one xscreensaver hack that uses palette shifting on 8-bit displays and is slow on other color depths... but that's the only advantage to 8bit color left, and there is no advantage to 16 bit color.
It costs $15 now to get a 4MB video card; $30 to get an 8MB card. Bring sandwiches to work for a week instead of buying lunch, and never worry about sub-par color again.
Many of the advantages that made X so powerful in "the day" may no longer apply. X has an extensive security mechanism that exists more or less to provide authentication/authorization in an insecure, networked environment (such as a bunch of X terminals connected to one app server). While this environment does still exist (primarily in university settings), "most" users of X only have a single display to work with and won't need the security considerations X offers.
:)
X tends to suffer from what I call "Win32APItis", a huge assortment of functions of dubious utility (it would be "GTKitis" if it weren't documented). Other projects, such as Berlin, seem to have learned this lesson -- it's possible to make an entire windowing system with the simplicity of a "regular" toolkit. Any step in the direction of a less stressful API is therefore a step towards unification of look-and-feel, since developers won't be compelled to write entirely new toolkits to scratch the itch of hating Xt/Xlib
While some of the various extensions that X is now sporting (patches for TrueType support, GLX, and printing) are useful accessories, ultimately they reveal X's age. A lot of the features a modern GUI designer would like simply aren't that easy (or sometimes possible) to implement.
All this isn't to say that we just need to chuck X in the garbage can and start supporting Berlin/GGI/whatever; I would prefer to see a thin (hah) Xlib wrapper on top of such projects, in parallel to ports of GDK or Qt or whatever people like. X has some very strong advantages, which should not be overlooked.
Nothing worth doing is worth doing today.
$ top
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
391 root 12 0 38356 35M 2576 S 0 1.5 57.0 18:11 X
That's 38 megs, 35 in core.
I now await the standard blather about how "RAM is cheap" and how that justifies this astonishing bloat.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Alternatives
There is the GGI-Project, the Berlin consortium and Y. GGI is an abstraction layer for grafics programming, but relatively low-level (e.g.games). It serves as driver lib, can be partially controlled by the kernel (KGI) and can output to different "targets" like svga or X. It also serves as the basis for Berlin, a new windowing system using OpenGL, among other things. Don't know about Y.
Hope that helps a bit
Avus
I'd be curious as to the details of why this is a good idea. Sure it's cool, but for pretty much every serious job I can think of, a third dimension would just get in the way. The reason is simple: monitors are two dimensional. The trick is to use that space efficiently, and I don't see how adding a third dimension would help any.
There are also control issues. How do I deal with these windows? Do you seriously want to have to do FPS-style moving around to move to a different app? Frankly, this would just be confusing. Please eleaborate as to where this would be useful.
There are two X alternatives that I can think of besides the Berlin mentioned. One of them is The Y Window System, by the Hungry Programmers (specifically Christoph Toshok), which isn't very far along and as far as I can tell hasn't been worked on in a while (since about February 1998). It promotes the use of a single fixed depth, which I think is a bad idea. It does have some good ideas though, like a somewhat separate memory architecture. Download here.
The other one, NanoGUI, was originally developed by Alan Cox. It was designed with a lightweight memory footprint in mind. I'm not sure if it supports networked display, though, but I believe they're going to at least port VNC. It's being used on the new Linux7k project, which is attempting to create a usable Linux system for the Psion 5 series palmtop (it uses an ARM7 processor). It seems to be undergoing active development. Download here.
So I hope that's a good starting point.
In response:
:)
,reverse qq;):zrekcahzlrepzrehtonaztey; );"
1) There is no excuse for this one
2) See #1
3) Not true. There IS a lot of backwards compatibility because it DOES get used. X is not all that bloated, although a diet would improve things.
4) If you want a speedier environment (#6) then this wouldn't help. Coding GUI's isn't hard in C, it's merely a matter of preference, and I'm sure many people will fight to the death to keep coding gui's in C.
5) Standardization is a Bad Thing. The whole idea of X is to make something that interfaces witht the video drivers and provides only the very basic tools. Standardization of GUI's is beyond the scope of it. Use KDE or GNOME, this is what they're made for.
6)Your card probably isn't supported very well. There are a variety of reasons for this. Netscape never flickers grey for me.. and my PC isn't exceptional, nor is my video card. Netscpae is a bad example anyways, since it isn't exactly a high-performance piece of software.
7) This is where the windowmanager comes in. And the graphics toolkits. You can't blame X for the variety out there, and X shouldn't make one standard at the cost of hurting the others. GTK+ is making a bid these days for the default toolkit, and things like GNOME and KDE do somethign similar.
Besides the X-consortium thing, your arguments miss the point.
Probably the biggest complaint most people have is the client-server architecture, but there are benefits to this as well (in computer labs, etc..)
which IMHO far outweigh any problems.
Besides, it's not like opening a connection to your own computer is slow, and I remember hearing if X knows its working on the same computer it makes optimizations (but I am not sure on that.)
Which dosen't mean the berlin project is bad. That's the spirit of open source operating systems like BSD and Linux, if you don't like what's out, write your own!
- Paradox
Man of the C!!!
perl -e "print join q( ), split(q.z.
Slashdot. It's Not For Common Sense
The experience of using X is, in my opinion, far inferior to using windows or macos. It is the feel of it that always gets on my nerves.
Using X, the mouse seems just a tiny bit less smooth and responsive than running windows on the same machine. Responsiveness to a click lags a little bit behind other systems, and for some reason a click does not always register. And yes, my video card IS supported, and my processor is a Pentium 350, my bus runs at 100mhz and I have 96MB of sdram, so I don't think the computer is the problem.
The speed things are actually drawn at is usually way better than windows or mac, but responsiveness to the mouse and sometimes the keyboard is usually way worse. If X would just start feeling as smooth and responsive as other GUIs, I would be very happy with it, but right now it is frustrating.
Vidi, Vici, Veni
Well, since you are biased, could you take those points and explain how Berlin has fixed/is-attempting-to-fix these things? I can guess the answer to 3 and 4 pretty easily but I'm curious as to how a start-over approach would deal with the rest of the items.
That's font antialiasing in action. It uses a trick of the human eye to "blur" each character in a way that it actually appears sharper. For a fuller explanation, pick up advanced book on computer graphics.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
If you check out:
:-)
http://reality.sgi.com/opengl/d11/d11.html
there is a really good article about how to extend X11 with the special case of 'local host' and that would improve the performance that I find could be made better. And that would definitely be good if it is to be used for games and such.
All other stuff about easier configuration, prettier window managers and such is already being worked on and will get better and better. If you can't wait for it you could donate money to people doing it for you unless you can yourself
True, X is old. BUT, there are a lot of things that X has that blow the pants off of other GUIs (Here I'm thinking of Win and Mac).
1) Network support. The ability to start a remote X session is a HUGE advantage. It allows you to run machines without monitirs, it allows you to work in a GUI when you want to do remote administration, etc.
2) Client Server Architecture. This means that we can have any number of Window Managers and switch among them at will. This is great becasue different people work differetly. What is efficient to you is ineficient to me, etc.
While it's true that X is aging, something BIG would have to be developed to replace it (not an impossible task, just difficult).
The truth of the matter is that XFree 4.0 will offer some very modern additions to X's capabilities. Integrated 3D (GLX) support for direct hardware access for rendering, true multi-headed support, etc. The rewrite for 4.0 is also making a lot of 'under-the-hood' changes. They are making X modular (much like the Linux kernel), this means that generally X will be stabler because it will have more common code that will not have to be recreated across a bunch of different servers.
I like X. It could probably be better (what couldn't), but I think it's probably the best GUI system that I've ever come across in terms of flexability and user choices. X 4.0 will bring out many features that will modernize it greatly.
There has been a lot of discussion here already about what X's failings are. Quite a lot of it has been wrong (X has many problems, but it's not that ``tvtwm sucks.'' That has nothing to do with X.)
The X chapter of the Unix Haters' Handbook really does do a great job of covering the major points. Yes, this was written several years ago, and not all of it is relevant any more (for example, most Linux users don't use Motif, so all the abuse piled on the Motif implementation probably isn't relevant to most of you; and GTK doesn't even use the X resource manager, so most of you probably don't use your .Xdefaults file any more.) But where he talks about the X protocol, the low-level X API, and the horrors that X's fundamental design decisions have inflicted on us (``run xterm well'' with window management added as an afterthought) it's spot-on. The ``Myth: X Demonstrates the Power of Client/Server Computing'' and ``Myth: X is Device Independent'' section are especially key.
But none of that matters . Why? Because it doesn't matter how much X sucks, because X is entrenched. It works badly, but it works well enough. It is the de-facto sub-standard. It cannot be replaced, or even fixed, without rewriting every single graphical application you have ever seen, and that's just not practical.
Worse is Better.
Another point I feel the need to make is that most of the people who have been posting to this thread don't understand what X actually is. Some people are talking about X, and some people are talking about ``the sum total of the graphical Unix experience'', of which X is only a small part. In particular, if you're flaming the way your window manager works, you're not talking about X, you're talking about some random crummy application. There are a ton of window managers (there are possibly even more WMs than there are IRC clients, and that's pretty impressive.)
The source of this confusion is that most other window systems come with policy: the look of the window management controls are built in to the window system itself, as are all kinds of other things like cut-and-paste and drag-and-drop: in the interest of ``flexibility,'' X left all of these things undefined, meaning there is no consistency at all.
X itself is very low-level, handling graphics operations and little else. Though small, it imposes serious performance restrictions by the nature of its design.
Because X itself does close to nothing, on top of it, many organizations have built the so-called ``toolkits'' that let you actually build user interfaces. These toolkits impose policy, and implement all the things that one would expect from a window system if one's first experience with a window system was something other than X.
These toolkits inherit all the limitations of X, and then add more of their own: Athena is ugly as sin, and does very little (it doesn't even have real menubars.) Motif was insanely buggy for years, and is still incredibly inefficient. GTK is slow, and isn't really finished yet. KDE requires C++. And so on. And of course all of them are incompatible with each other to various degrees.
If you're bitching about things not being ``object oriented'' enough, then you're bitching about a toolkit, not about X. X itself is so low level that there's just no need for OO hair: those abstractions come at a higher level.
Some people think it's a great thing that X doesn't come with policy. I say nonsense: rampant customizability is almost always an excuse for not having taken the time to get it right in the first place. I just want an appliance that works, I don't want to have to spend days tweaking it before I can turn it on.
Here's what X's lauded ``flexibility'' has given me: right now I'm looking at a screen that has applications on it written using five different toolkits. They all work basically the same (which is to say, they all work basically like a Xerox Alto), but each one renders menus differently, and half of them do cut-and-paste in incompatible ways. Thanks to the flexibility of X, there is no consistency. I really don't care what menus look like, or how cut-and-paste works; I just wish it was possible to pick one and stick with it.
The other efforts to provide consistency across the desktop (Gnome, KDE, whatever) all start off with the requirement of rewriting every single application to do so! What a colossal waste of time! But there is simply no other way, thanks to the legacy of X: thanks to X's refusal to dictate policy, there is no one policy to replace, there are dozens.
I have no problems with X once it is up and
running. The X server idea with the server
running close to the client is highly useful,
as well as removing the window manager from
the server (as opposed to the options on most
prevalent systems).
Configuration does seem to be the problem
area with X -- especially now that XFree86
has become so popular. Our local NLUG just
had an hour-long lecture devoted to X
configuration (and many of the listeners were
the Linux Literate).
If X could be made to be more readily
configurable (which is not an X issue per se...)
by better configuration tools than currently
exist -- hell, even fetching specs from
www.xfree86.org automatically given a known
card name/chipset would dramatically ease
installation in most cases (most users don't
know where to look and most tools guess horribly
wrong about what numbers go with what cards) --
then X would be more usable by more people.
Another issue is security. Most X installations
are grossly insecure. A secure X distribution
(one that installs more securely by default)
would be a nice touch.
I don't, however, see any competing protocol which
offers anywhere near the utility of X.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
1) To develop for X you have to be an X Consortium member which costs about $50k/year to do any real work. This is why so much work is being done on layers above X, because no one can actually submit the kind of radical modifications to X that are needed to bring it into the 90's.
:)
:)
2) The X consortium maintains full control over X itself... meaning they can (and have at least once) change the licensing to kill off any free implementations such as xfree86.
3) The software is extremely dated with over a decade of backwards compatibility which no one even uses any more bloating the code base.
4) C... Object Oriented environment.. please. I'm sure a lot of people will bash this, but writing GUI programs in an OO language is simply easier. And before you start on the OO toolkits out there, read the next point.
5) Of course there are C++ and Java toolkits out there, but until they are standard within X, it's a big war. I have roughly 15 X toolkits on my machine to run a total of 8 programs and a window manager. Doesn't anyone else think this is silly?
6) Sluggish. I have AccelX and I have to admit the entire experience is still very slow. Netscape flickers gray every time I scroll up and down, windows take ages to redraw when switching between them, etc. I multiboot to Windows and don't have any of these problems, everything is quite snappy... even if it crashes every 8 hours
7) Inconsistant. With all the toolkits out there, it is so very hard to get a nice consistant desktop. I wouldn't even claim that Windows is consistant, but it is pretty close. MacOS is better.. but at least both environments are intuitive.
Once you understand the basics, you can switch between different applications and automatically pickup that the scisors in the toolbar means cut or that the file menu will have an 'exit' entry or even that ctrl-c will copy the selected text (most of the time at least
Of course, I am biased on this subject...
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Berlin is a new windowing system for Unix systems designed to replace the aging X Window System. Berlin is currently released under LGPL and is developed using an open development model. We are sponsored in part by SPI who also sponsors the Debian and GNOME projects.
Berlin operates on the object level. All GUI components (widgets), applications, and non-visual components such as audio components, are CORBA accessible components. This means they are network transparent, platform independent, and language independent.
To do things like displaying an application run on a server on your local workstation (the way X does), we abstracted 2D and 3D APIs as much as possible, we also implemented commonly used functions in the display server to reduce the network traffic as much as possible.
If you are familiar with how ActiveX components in Windows work, this should be a very familiar model. All communication between components, applications and Berlin is done via CORBA using the OmniORB2 CORBA ORB (which is recognized as the fastest CORBA implementation out there).
Because we use CORBA, any language with CORBA bindings will be usable for writing Berlin applications and components. These include C, C++, Perl, Java, Python and much more.
We adopted a paradigm similar to the classic Model-View-Controller so that the look of individual components such as buttons is not directly tied to it's interface and can be swapped out easily and painlessly. New components that ship with applications, and indeed the applications themselves, can be used freely by other applications extending the reusability of code to the extreme.
A lot of Berlin's design was taken from Fresco, the competing toolkit to Motif. Fresco is still one of the most advanced toolkits out there and it's influences can be seen in several newer toolkits such as Java's JFC.
Instead of implementing our own video drivers in userspace as X does, our backend currently uses Mesa an OpenGL implementation, but can be replaced without much work. Current versions of Mesa can use a wide variety of video drivers from the integrated drivers in the Linux kernel to X itself.
Overall, we hope to provide all the power we can to developers while ending the excessive desire to create new toolkits in order to add a single widget or modify an existing one.
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.