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?
> 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.
Actually this is precisely why we reproduce.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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
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.
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?
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.
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.
> Plan 9's windowing system will run another instance of itself in one of its windows
Any window? Running xli inside an xterm would be nifty indeed. Or is it a "window system window?" Xnest has been able to do that for a long time.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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?
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.
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"
Aboslutely! I've become increasingly worried about the trend of moving applications to the web. While X is big, nasty and old, and Windows is big, unreliable and proprietary, they were at least designed to run applications on.
The web was not, and the pots of liquid kludge required to get any half-decent application running on the web make it extremely unfriendly and unreliable. Even on modern GUI systems there are to many layers, too much to go wrong, between the application code and the machine. Add to that HTML, Javascript, DOM, the web browser and the HTTP layer, and you've got a teetering stack of systems. Any layer goes wrong, and your application won't work, usually in some obscure and hard-to-correct way. Add to this the abysmal level of support for standards in web browsers and you'll be lucky to get anything to work at all.
Not to mention that having to go through HTTP makes web apps excruciatingly slow. Used a web-based mail service lately? Marvel at how long it takes you to go through your mailbox, weeding out spam and organising the mail. Each small operation, which would happen almost instantaneously on a decent client-side mailreader application, now takes five to ten seconds to perform, making mail a chore. And you thought *X* was slow!
Another case: MS NT Option Pack (after a tortous install procedure) has no help files. Instead, it installs a bunch of help web pages on your server, and expects you to use a web browser to read them. Except you need a web browser with MS's VM installed, which it isn't by default. So you have to go through another install. (And the first thing any webmaster does is automatically remove all the stupid samples and crap IIS installs. So then the help system isn't even usable.)
When the help system does work, it's still miles worse than the Windows Help application MS have had since Windows 3. The contents list becomes unresizable. The search feature requires that you haven't messed up something in the configuration (which might, for example, be a reason why you'd be reading the help files? do you see? DO YOU SEE?). When you do a search and find something related to what you want to know, you can't pop up a level to see related documents, because there are no links. And if you go back to the contents pane, you ca't actually see where the document you are viewing is in the hierarchy.
Usability factor zero. But hey, it's on the web. So it must be cool, right?
The web is *not* a way to make interfaces easier. What is needed is consistency of interfaces, but the only consistency the web gives you is that you get a few navigation buttons at the top. That doesn't teach you how to use a new piece of software on the web. In fact it often breaks the software if you use them.
Damn right. It's a pity the idea never quite caught on, with most commercial packages becoming bloated with totally unnecessary features, so that any particular task can be done badly by a dozen applications, but done well by none.
I don't want an unfriendly text editor in my C compiler, damn it! I don't want a bad mailer in my web browser!
I'm rambling now. I'll stop.
The web is good for two things:
The web is not the future for document creation, processing or e-mail. Or if it is, I want to stick my head under the pillow and hope the future will go away.
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.