Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
X GUI

Is X The Future? 261

Posted by CmdrTaco from the future-of-the-gui dept.
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?
This discussion has been archived. No new comments can be posted.

Is X The Future? More

Is X The Future?

Comments Filter:
  • > 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.

  • What happens if a .Xdefaults/resources/whatever file gets corrupted? Your application starts up with a perfactly usable set of options.

    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.
  • Linux seems more GNU-compliant than POSIX-compliant.

    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.
  • Sounds to me like he's just striking back at all the ignorami who think we need to discard X, despite having no idea what X actually does. I agree with him, and I'm a math PhD student with no vested interests in the computer industry.


  • How old are you anyway? At least 15 to 20 years old? Your development has gotten so slow that you probably haven't added any height whatever for at least a year, if not longer. You probably have added weight (bloat) since you stopped developing.

    Its probably time to replace you. You've stopped making progress.


    Actually this is precisely why we reproduce.
  • 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.
  • Interestng article, but I take issue with his views on GUI toolkits. I agree with some of his points, but the foolishness of his suggestion that we program in raw Xlib is only surpassed by the suggestion that we can all use Motif because "Lesstif is available". Maybe he's using a commercial UNIX which includes motif, and he hasn't seen how bad lesstif really is.

    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.
  • 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...

    What happens if the Windows registry gets corrupted? Your machine's fscked, never mind your application.

    What happens if a .Xdefaults/resources/whatever
    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

  • 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


    ---

  • 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.
  • 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.

  • Interestingly enough, QT and GTK don't make use of those files ( well, KDE sets X-resources to match it's own configuration ). KDE already has a control panel and GUI tools to configure those things ( as does GNOME )

  • 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.
  • > 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.

    Meaning you get even slower and more bloated double-windowed system. At least extending X means you do things /once/.

    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 /heard/ about it was Rasterman and he told me he couldn't grasp its API. Neither could I.

    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.
  • 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.
  • Slower than other remote display protocols, especially ICA

    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).

  • dammed html..

    App {- opengl functions -} OpenGL Library {- glx/dri/X11/directX/whatever -} Screen
  • 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.
  • 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".

    ;)
  • 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.

  • 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.

    That hasn't been my experience at all. I've seen three basic sets of opinions:

    1. People who don't know the difference between X and FVWM, and note that Linux has a crummy and inconsistent end-user GUI experience;

    2. People who have done little or no X programming and think that being able to run an xterm on the machine down the hallway is really neat;

    3. People who have done an extensive amount of X programming, know a lot about X, and hate it because it is completely unsuitable for any kind of performance-critical tasks, including (for example) anything that uses graphics.

    I'm in camp #3, obviously.

    This thread is going to re-hash everything that was discussed here last week [slashdot.org] and the week before then, is it? I guess that's appropriate, since the article that started these comments also seemed to disregard it.

  • 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.
  • 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).
  • 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.

  • 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:

    1. 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:

    2. Take a nontrivial X application and make it fully ICCCM compliant.
    3. Make a hand-held X terminal, or any other embedded X implentation. It has to be complete enough to display Netscape and all other popular X apps.
    4. Add antialiased fonts to X, while ensuring the following:
      • All existing X clients get antialiased fonts when using an X server that supports them
      • Retain the ability to use existing X font servers (in some cases, replacing the server is not possible, because of fonts in an old proprietary font format that certain apps require)
      • New applications will work on servers that do n't support antialiased fonts
    5. Write a word processor in X that can print, without writing your own display abstraction on top of X for the onscreen WYSIWYG display. Bonus points if you can do without the extra display abstraction for printing itself; there are relevent X standards.
    6. Implement clipboard functionality in X on par with Windows or Mac environments, while still retaining interoperability with existing applications
    7. Implement sharing colormap cells between apps (as Windows does), so those that require a large number of colors (but don't, say, palette-cycle) don't have to allocate a private colormap and cause annoying palette disturbances

    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.


    ---
  • 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...
  • I think the point of this article is: X has the ability to do everything that you describe natively or with a few extensions?

    Just because something is old doesn't mean it's bad.

  • My 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).

  • 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.

    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 ??
  • ...or at least we don't know the ending yet.

  • 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.

  • 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.

  • No way! One of the big wins of X is that it does not try to implement any GUI components. If it did, X would look precisely like it did in 1983 and it would be very very lousy!

    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!

  • 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

  • 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.

    This implies that the entire X window system, including TCP/IP, is faster than the lowest level of a typical NT graphics driver. Even when the target is an ancient NCD X terminal (nearly nine year old technology).

    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.
  • 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.

    Errr, the book has an "anti-forward" by Dennis Ritchie. Not exactly someone who hates Unix on a fundamental level. I think the book is more about playfully taking Unix to task for all its ugliness than suggesting that it be abandoned. When you think about it, all operating systems are evil, and Unix is really just the least evil operating system of them all.

    ~k.lee

  • 1. 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.


    ---
  • 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.
  • You've bumpoed into the 'Rolls Royce over night' problem -- one person alone can't code that much...
    John

  • How exactly does one extend X with features such as

    1. Elegant minimalism
      The Archimedes could put the entire basic windowing system into less than 1MB of RAM. Why not do that for the drawing infrastructure, and then bolt on an extra 100Kb of RAM requirements for the networking -- and then dedecate another few Mb of RAM for image cacheing, texture cacheing, VM workspace etc. -- X requires too much memory on both the client and server end (whichever they are) -- the only difference with X these days is that the requirements are tolerable.
    2. A single unified font subsystem that understands font metrics correctly...
    In short -- extending an existing architecture CANNOT make it any leaner
    John

  • 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
  • Quartz looks like it will be truly amazing. Only problem is it almost certainly won't support remote display. Not a big deal for most users, but it would be nice to have. Other than that it looks like it'll be years ahead of anything else out there.

    The only info I can find online about it is this [apple.com] which is mostly just marketing hype, but from demos Apple gave at WWDC in January it looks like it'll be amazing.

    Linux/Unix in general could really use a replacement for X. I believe the OSS community can put together something better than Quartz if people will just admit that X is broken first.

  • 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.








  • http://terror.hungry.com/products/Ywind ows/ [hungry.com]

    Not much there yet, it seems.

  • I don't really know enough about X to comment, but I see that hasn't stopped anyone else, so here goes...

    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

  • Sure. Compare it to, for example, a database.

    Database client: "Excuse me, but, if you wouldn't mind, could you mark record 27B/6 as 'completed', please." Database server: "Sure thing; marked it is."

    X client: "Excuse me, but, if you wouldn't mind, could you draw me a rectangle please? Just a little one." X server: "Sure thing; drawn it is."

    What I don't understand is why people think X uses the terms backwards. Would someone mind explaining?

  • > 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.

    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- haters/x-windows/disaster.html

    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" ...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.

    ...

    Myth: X Is "Portable" ...And Iran-Contra wasn't Arms for Hostages.
    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; /* Black. */
    /* Whoops! No, I mean: */
    favorite_color = BlackPixel(display, DefaultScreen(display));
    /* AAAYYYYEEEEE!! */

    (client dumps core & falls into the chasm)


    ...

    Programming X-Windows is like trying to find the square root of pi using roman numerals.


  • > I'd really hate to try running Quake2, even
    > 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 ... lead to the exact same
    > 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.
  • "We need to replace X with a media-ready, true-color-plus-alpha, image-compositing gui that runs on the framebuffer device."

    See also: Apple's "Quartz" imaging model for Mac OS X...

  • 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> [att.com]. 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)

  • X is certainly big. What I would like to see is an alternate X (maybe Y will do that?), which is slimmer and has a subset of X functionality. Don't we all complain about the unwanted excess baggage M$ imposes on us? For a true desktop PC, why have all those features of being able to display remote processes screens on your display? We shouldn't go for a "one size fits all" policy.

    Remember: I'm NOT saying X should be replaced - only that we should have a choice of a slimmer and meaner alternate windowing system. Isn't that what "free" is about?
  • Are you saying that X is hard to configure, or that One implementation of X on the PC (XFree86) is hard to configure?

    There are several implementations of X Servers on PCs. Just becasue one isn't luser friendly to setup, doesn't mean they all arn't (Sun has one, SCO has one, Plus there are seveal comercial X servers for Linix on x86).

    Alot of the complaints I've been reading, are not talkign about X, but one implementation of it. If you find XFree hard to configure, grab the source and fix it, or write your own implementation of X.

    PS. The author never mentioned Xfree or any specific implementation of X, but X in general.
  • "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.
  • The only problem with your statement is: Linux is not POSIX compliant. It's kinda-sorta compliant.

    One of the 'big guns' now supporting Linux should fund the efforts needed to get POSIX compliance for Linux. The problem is, then Linux developers would have to get a cluse in order to keep it compliant.

    Recently in a newsgroup thread, the primary maintainer of the Bash project stepped into a discussion, where somebody was claiming that Bash was based on the POSIX shell spec., and admitted he didn't even have access to a copy of the POSIX standards. From my reading recently, a strong anti-standards bias seems to be built into the GNU community. There's a remarkable attitude that says "add it to the GNU version and everybody else will catch up eventually."



  • 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.
    --

  • 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 [themes.org]), 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.

  • This article is laughable. I will debunk myself only a couple of its claims, but do yourself a favor and read the X11 chapter [catalog.com] of the Unix-Haters Handbook [catalog.com]. 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.

  • Maybe something like:
    *background: LightSteelBlue
    ?

    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.
    --

  • 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).
    --
  • 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...).

  • 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
  • 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...
  • 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"
  • Yes, I remember my enthusiasm after seeing the original Berlin webpage: "Hardware acceleration makes all the difference", "Assembly language is fast" etc. Now it's just an overengineered bloat-vapor-ware.
  • 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.
  • 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.

    That's true. I still do not get why there is not just a simple VESA-server that uses all Vesa 1.2 resolutions on my card. Stupid Windows doesn't have this either, by the way, all stupid different drivers.

    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!

    SGI/IRIX rules in these area's. They use X.

    The GUI should also support anti-aliased Type1, Truetype and OpenType fonts.

    X, X, X. The idea of starting extra font servers and just plugging them in (xfstt) rules.

    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.

    X

  • Ick/ (Score:1)

    by Boolean ( 15853 )
    personally I hate programming in X. I sure HOPE its not the future.

  • 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?

  • > X is probably the best protocol for a
    > distributed windowing environment.

    Fine - but what about when someone wishes to use Linux on a desktop not on a network? I'm well aware that networking is everywhere these days but even so, that does not mean that you are going to have enough bandwidth to run X apps along the line.
    Surely using a windowing system that is written for distributed computing is inappropriate in terms of system overheads for a single desktop?
    In this case - is there an alternative that is usable and worth trying out?
  • 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. ;)
  • Nope, indeed many of these cheap PC cards are better than their Sun/SGI/HP equivilants costing many times more.

    However there isn't any easy way to avoid the mess of different video cards we've got. Twice now there has been an effort at standardization, and both times manufacturers have added in extra stuff to give their cards an edge. You can either live with the reduced choice, or with the increased complexity of configuration.

  • ...but is X a GUI? From my (admittedly limited) understanding, X is the stuff underlying the GUI. Can somebody who KNOWS clarify?

    Tusind tak.

  • 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 [berlin-consortium.org] is personally my best hope for replacing X, or giving it a sorely needed wakeup call.

  • ... get rid of those fscking .Xdefaults and .appdefaults files!

    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?

  • > 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.
  • 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
  • I work on OS/2, WinNT, and Linux and I have X servers for ALL of them. I have to tell you, it is very convienient to run a program on my Linux box and have it show up on my OS/2 system or WinNT system....or at home...or in another state to show a customer....or....

    The article is not about how displays look because X does not describe the graphics themselves, but instead defines a protocol for applications (clients) to talk to X Servers. X Window Managers manage the graphics displays. I think people are getting hung up on the 'looks' of a GUI which is totally dependent upon the X Window Manager and the underlying libraries the specific application was linked with.

    X is probably the best protocol for a distributed windowing environment. It is certainly the most flexible. Sure, improvements can still be made, but X is a great concept and a stable piece of software using open standards. Name another piece of software that is as flexible, useful and solid.
  • > 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).

    Actually, There are X Servers (and very possibly clients) for Windows, and OS/2. It would surprise me if BEOS didn't have some sort of X Server.

    IMHO, X IS the way to go, it is a solid proven standard.
  • X is hard to configure because it asks for stuff like the chipset of your video card or the vertical and horizontal refresh rates on your monitor. Of course that seems easy for an advanced user but the people who use their PC for e-mail and wab surfing dont know about that (and probably don't need to know).
  • I agree with most of what the author is saying. However, certain things (such as him insisting we not require the use of shared memory and lots of bandwidth) are a bit pedantic, since certain things just don't work the way X was intended. For example, I'd really hate to try running Quake2, even through GLX, on a remote display. The latency would be absolutely *horrible*...

    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.

  • I love X as a platform. I'll bet that most of the negative posts on this article will treat X as an interface, which it simply isn't. You can have any kind of interface on top of X, including the Windows GUI by the way (WinCenter).

    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?

  • AFAIK, GLX can run remotely, but I'm not sure.
  • 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"
  • The web is just plain gross. HTML is horrific. Writing CGI software is inefficient, tramatic, and very limiting.

    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.

    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.

    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.

    Programs are not documents either.

    The web is good for two things:

    • distributing documents.
    • communicating with others in more complex ways than simple e-mail allows (for example sites, like /.).

    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.

Slashdot Top Deals

This is now. Later is later.

Close