Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

The State of X.Org

Posted by kdawson on Wed Jun 11, 2008 07:47 AM
from the marks-the-spot dept.
An anonymous reader writes "Phoronix has up an article looking at the release of X Server 1.4.1. This maintenance release for X.Org, which the open-source operating systems depend upon for living in a graphically rich world, comes more than 200 days late and it doesn't even clear the BugZilla release blocker bug. A further indication of problems is that the next major release of X.Org was scheduled to be released in February... then May... and now it's missing with no sign of when a release will occur. There are still more than three dozen outstanding bugs. Also, the forthcoming release (X.Org 7.4) will ship with a slimmer set of features than what was initially planned."
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by CastrTroy (595695) on Wednesday June 11 2008, @07:53AM (#23746037) Homepage
    Is there anything else out there? Why is there such a lack of interest in X.org, when so many other projects depend on it. Most of the big projects have been moving quite quickly, making a lot of headway in the past couple of years. What's holding x.org back?
    • Probably the complexity of the issues involved, and the ever-expanding environmental requirements X is being written for.
      • by kripkenstein (913150) on Wednesday June 11 2008, @09:51AM (#23747753) Homepage
        In addition to those factors, I'd say the problem is also a lack of interest.

        On the one hand we have things like GNOME and KDE, Firefox, Blender, etc. etc. - software that the user knows by name and interacts with directly. People happily join such projects and contribute code to them.

        On the other hand you have software that the typical user might not not even know exists, like the Linux kernel. However, for geeks the kernel is perhaps the pinnacle of programming, and furthermore by lucky coincidence (or unhappy, if you are GNU) the name of the kernel has become synonymous with the entire OS, making it high-profile just like the more obvious software projects mentioned in the previous paragraph.

        Whereas the X server is somewhere in the middle. It isn't well known, even geeks might not know exactly what it does (i.e., where the separation is between X, the window manager, and so forth), and for some reason it lacks the 'coolness' factor of the Linux kernel.

        All of this is unjustified, and a shame. Perhaps more stories on Slashdot like this one will raise awareness? Maybe we should also motivate people, by e.g. telling them that hacking X is even harder than hacking the kernel ;)
        • by 0xABADC0DA (867955) on Wednesday June 11 2008, @11:02AM (#23749049)
          I would like to contribute to the X, but mostly what stops me is that the code is written for the 80s. Lots of internals are using macros and bit values and optimization hacks, and directly 'speaking' X11 protocol. The code is disorganized, with files in weird locations and with two-letter names. I'm not blaming the developers, because in the 80s this is what had to be done. And they are making huge progress making it modular and organizing the code. But it's still not an attractive codebase to dig into.

          Then, once you have decided to work on it and have fully absorbed X11 protocol into your being, you basically need a vmware license in order to develop. It's almost as hard to try out the changes you made as it is for kernel developers... slightly easier, especially for debugging, but you still need to either shut down everything you are doing to run a new build or have multiple development systems.

          So basically it is a really step hill to overcome just to start developing X. Perhaps steeper since the kernel at least has excellent, 'simple', modular code to work with.
        • by ThePhilips (752041) on Wednesday June 11 2008, @11:44AM (#23749915) Homepage Journal

          My personal bet is that X is overly complicated.

          E.g. it takes 20-30 minutes to start doing something with Linux kernel. Entry bar is set low - many people like to participate. Needless to mention that to compile (properly configured) Linux kernel (with subset of drivers and features you really need) only few minutes. There are piles and piles of documentation and forums where you can find anything.

          E.g. KDE + Qt. To compile KDE - you might need days. Or just grab precompiled binary packages. But after that you can in 5 minutes create something useful and interesting. Documentation is near perfect and complete. Also reading source code is quite easy, since most of the code is human readable.

          But X is different beast. Even compiling it is challenge on itself. There is literally no documentation on its innards. There is no "Hello World" for X. There are bunch of example modules which you need to spend hours after hours to only understand where they plug into the all X mess.

          I'd say main X problem is its strive to be cool and sit on all chairs. I'd say they need to scale down the project and split it into smaller independent pieces. Forget large releases (installing apt-get would help! kidding). The smaller sub-projects would have more chances attracting people, since (at least theoretically) then entry barrier would be lower.

    • by larry bagina (561269) on Wednesday June 11 2008, @07:57AM (#23746093) Journal
      I agree. I recently discovered the xfree86 project. It seems like a good alternative to x.org.
      • by Kjella (173770) on Wednesday June 11 2008, @08:10AM (#23746257) Homepage
        Uh, a strange thing to say but your posting history seems normal so...

        In February 2004, with version 4.4.0, The XFree86 Project adopted a license change that the Free Software Foundation considered GPL incompatible. Most Linux distributions found the potential legal issues unacceptable and made plans to move to a fork from before the license change. At first there were multiple forks, but the X.Org fork soon became the dominant one. Most XFree86 developers who were already annoyed at other issues in the project also moved to X.Org.
        In short, x.org was xfree86 but that project is practicly dead. Pretty much everyone worth mentioning have migrated from xfree86 to x.org and while x.org may be moving slow, xfree86 has almost stopped dead. Going back there would do little to nothing to bolster X development. Tbe question is rather why there's so little work overall (or so it claims, I don't have enough knowledge to say) since the competition is basicly non-existant.
        • by Yetihehe (971185) on Wednesday June 11 2008, @08:13AM (#23746305)

          Tbe question is rather why there's so little work overall (or so it claims, I don't have enough knowledge to say) since the competition is basicly non-existant.
          Wow, you have just answered your question in the same sentence.
          • by CastrTroy (595695) on Wednesday June 11 2008, @08:22AM (#23746405) Homepage
            Open source does not work like big business. It doesn't stagnate because there's no competition. It stagnates because people don't want to work on it. There isn't much competition for the Linux Kernel either. That doesn't slow down it's development.
            • by pebcak (773787) on Wednesday June 11 2008, @08:29AM (#23746503) Homepage

              There isn't much competition for the Linux Kernel either.
              You mean like FreeBSD, OpenBSD, NetBSD, Darwin and OpenSolaris?
              • by kosibar (671097) <slashdot AT teneblok DOT com> on Wednesday June 11 2008, @10:39AM (#23748613)
                Okay, so here's an idea...

                We should revive XFree86. To start, we should generate a list of features for the next release. We'll spread some rumors about what we're doing, let the world see how hard we're working on it.

                This should get some attention from /. and other sites to get people involved but we'll freeze the code and not allow any new developers/submissions on the project. Frustrated, they'll go over to X.Org to try to work for the competition.

                Now for phase II. About this time next year we announce a release date, delay it a few times, then release it about two years from now. Make it a big deal. Major release. Get everybody talking about it.

                For the release we'll drop all of the major new features on the list. We'll fix a bug or two, something major like a spelling error in a log report. Of course, we'll add a few new bugs. We could drop support for some hardware. For new features we could change a few things in the conf file. Instead of "Section" you now have to use "Block". We could totally change the format of the ModeLine to something totally crazy (crazier?)

                If this follows the corporate model we have today it should drive major innovation and more frequent releases from X.Org, though our XFree86 project would unfortunately take away most of X.Org's market share.

                Open source projects would probably earn the respect of more businesses and government agencies if it would just follow these common sense models from the corporate world.
                • by peragrin (659227) on Wednesday June 11 2008, @10:54AM (#23748903)
                  that was the point of the fork though. Xfree86 developers moved slowly before X.org was formed, and wouldn't introduce changes like 3D accelerated desktop, period.

                  Developers where complaining about xfree86 for years before the fork, When the license changed it was just enough to push the fork. X.org began a long boring process of breaking X into smaller modules which will accelerate overall development. The problem is that process is still on going, and will take a few more years before any major upgrades can take place.

                  Think about the Mozilla project. They spent years cleaning out the core codebase and upgrading the core gecko engine from Netscape before they even had a decent beta. X.org is doing the same to something far larger, and uglier.
          • by Kjella (173770) on Wednesday June 11 2008, @08:31AM (#23746523) Homepage

            Wow, you have just answered your question in the same sentence.
            The Linux kernel for example, is completely without competing forks that I know of, yet seems to be making good strides. xfree86 was going slow, and even after the x.org revival things again appear to be going slow. With a lot of people focusing on the desktop performance of Linux, why isn't this project interesting? A lot of other projects seem to be progressing nicely even without the competition breathing down their necks. I wonder if part of the reason is that the code is X11 licensed, which is fairly close to BSD so you don't have even LGPL protection of your code. If Stallman is looking for a non-(L)GPL project to replace, maybe he should drop the Hurd and start working on a GPL'd X instead...
              • by vrmlguy (120854) <samwyse @ g m a il.com> on Wednesday June 11 2008, @10:02AM (#23747939) Homepage Journal

                Admittedly, I know next to nil about the internals of X, however I think that it does its job well for what it was intended. The problem is that home-use of "desktop" linux is NOT what X was intended for.
                [...]
                For "desktop linux," I don't see why the system isn't reworked to run off of a frame-buffer and scrap all the X crap -- still keep X for running networked apps.
                X uses multiple communications channels. There's TCP and DECnet, used for apps running on a different machine than the display server, and there's Unix pipes, which provide much higher throughput for local apps. But Unix pipes are nearly legacy now, because most servers also support MIT-SHM (the MIT Shared Memory extension), which lets an app have direct access to the X server's graphics buffers, and GLX (the OpenGL extension), used for running 3D graphics over a network. Finally, there's VirtualGL, which is a layer that can be used on top of either X11 or VNC. (See http://en.wikipedia.org/wiki/VirtualGL [wikipedia.org] for more info.)

                X11 already provides desktop Linux with you need to run high performance graphics.
                  • by nguy (1207026) on Wednesday June 11 2008, @11:18AM (#23749403)
                    A lot of Mac's success *IS* because its gui framework.

                    The GUI framework on the Mac is Cocoa. The equivalent of Cocoa is Gnome (or KDE). The underlying display server, the equivalent of X11, is Quartz.

                    it appears to be managed in frame buffer

                    But it isn't. OS X has the same client/server display architecture as a Gnome desktop.

                    with custom rom that makes sure you never see bios info -- just pretty pictures.

                    What you see on OS X is that the boot loader quickly throws up a gray screen to keep you from seeing the boot loader text; the text itself is still there. If you like, you can boot OS X completely in text mode, just like a Linux system.

                    the removal of large swaths of abstraction make it load and "talk" faster.

                    The OS X display server has at least as many layers of abstraction as X11. It is not intrinsically faster than X11 (if anything, it's slower). Mostly what you perceive as speed on OS X is massive amounts of backing store.

                    the use of pdf rendering

                    OS X doesn't really use PDF rendering.

                    and enforcing policy rather than just providing tools means that things like cut and paste work from app to app, every app.

                    I own several Macs. The notion that "cut and paste work from app to app, every app" is laughable, and Apple couldn't enforce that if they tried.

                    Furthermore, if anything, policy is determined by the GUI framework, not the display server.

                    That is the sort of thing that X fails on for the casual or home user.

                    Whatever problems you think the Linux desktop may have, they have nothing to do with X11; consistency and policy is determined by the desktop environment, not the display server.
        • by CastrTroy (595695) on Wednesday June 11 2008, @08:16AM (#23746329) Homepage
          First, I believe your parent post was a joke. Second of all, the reason most open source projects go stagnant seems to be for a couple reasons. First, the code is an ugly mess, and nobody wants to work on it. Second, internal conflict about where the project is going, so nothing gets done, or every new feature or bug fix becomes a big argument, about how it should be done. Thirdly, very boring project subject matter. The last one seems to be the big killer. There could be a nice open source Outlook/Exchange replacement. It wouldn't be inherently hard to build, but it seems that nobody is interested in doing it. Most of the stuff that gets a lot of attention is the stuff that developers are interested in building.
        • by 0xABADC0DA (867955) on Wednesday June 11 2008, @11:54AM (#23750093)

          Personally, I'm still unconvinced that X is a particularly "good idea." 15 years later, and the promises of simplicity and compatibility are still unrealized, as every single implementation of the protocol has suffered from numerous problems. Perhaps it would be best to start from scratch, and revise X11 to be a more realistic/practical specification.
          The main problem I think is that X is written in C. Originally the X server did graphics itself, scan converting lines and such, so it had to be in C (and there weren't many real alternatives then). Now all it really does is manage a lot of information -- and C is a really really bad language for managing lots of information. Even a simple desktop has over a thousand "windows" that all have position, change listeners, and other properties. Then there are all the bitmaps, pens, backing stores, repaint regions, etc. Events, queues, messages.

          The X server should be mostly scrapped and rewritten in Java. Java is a language that is suited for managing information like that, while still being high-performance (enough). The server could be rewritten in C++, but C++ is messy and is a complicated and archaic language at this point anyway.

          Take a look at for instance weirdx [jcraft.com] which basically one person did. It handles most of the core functions of X and plenty fast (of course it is incomplete since it is one person's hobby). Or see Sun's Project Looking Glass, an opengl X server written in Java -- that was also written in one guy's spare time. With more development on these they could be real competitors to X.org while being more approachable, and I'll bet faster than the C code.
          • by Anonymous Coward on Wednesday June 11 2008, @09:22AM (#23747277)
            or new developers to tackle bite-sized portions of the stack without being overwhelmed. Anyone care to comment on whether this was done?

            Yes, it was - hence rapid development things like mpx, xrandr, xrender, composite xinput 2.0 and so forth. Have people really forgotten so fast that a couple of years ago linux /didn't do/ all those gee-whiz window explodey effects?

            Really, the /. story is inflammatory flamebait. Loads of pretty cool new stuff has appeared recently in X.org. Actually, IMO that's more likely why the release schedule slipped - stuff like MPX is very cool but represents very major changes.

            Emacs' release schedule recently slipped too - but it was because they're merging ECB and window groups into Emacs 23, not because emacs devel has stopped!
          • by mhall119 (1035984) on Wednesday June 11 2008, @09:29AM (#23747373) Homepage Journal

            I remember when X.org started one of the things they promised was that the code base would be modularized allowing for new developers to tackle bite-sized portions of the stack without being overwhelmed. Anyone care to comment on whether this was done?
            It was done when they moved from X.org 6.x to 7.
    • I have a theory.

      We're using X as our windowing system because it's what we have, and we need it. But I don't think anybody (or not many people) really *believe* in it.

      That is to say, I doubt anybody takes a look at it and says "this is it! This is the way we should do Windowing!" And so the followup, "...and if it this thing worked, then it'd be more awesome."

      What people actually say when they start looking at it looks more like this.
      "Okay! X.org is a good project! I think maybe I'll contribute my time to it! Hold on...what is this? Why does it have all these features that nobody cares about? Why the nonstandard build system? What's with all the crazy legacy code? This thing is way too complex for me to spend my time on, and what I learn won't transfer to any other work. I'll pick something else."
    • by Enleth (947766) <enleth@enleth.com> on Wednesday June 11 2008, @08:28AM (#23746485) Homepage
      It's a HUGE, and I mean, REALLY HUGE codebase that deals with hell lots of different concepts (graphics, input, networking, ...) that requires a good deal of understanding to modify it properly. Yet, there are less than 30 (!) active developers. That's probably one of the most under-manned Open Source project out there, proportionally to its size. And it's, again, because it's complicated as hell and nothing can be done about this - it's just the way a windowing server has to be.

      I've tried to help the project two years ago, I did dome work on input hotplugging and while not much of the code I wrote finally made it to the upstream (Daniel Stone, the man behind the input subsystem, finally decided for a different solution than what I was thinking about - maybe that was a good decision, I'm not the one to judge), I could experience myself how difficult developing X is. Besides skills and experience, you need to be able to keep track of such a big structure mentally, all the time. Not every programmer can do that, even skilled and experienced.

      And, no, you can't always abstract everything out and make a nice, clean structure for the code to adhere to. Maybe the X code could be a bit easier to modify, but just a bit. Trying to force that, you would end up with an Xserver counterpart of GNU Hurd, if you know what I mean...
        • by Enleth (947766) <enleth@enleth.com> on Wednesday June 11 2008, @09:02AM (#23746999) Homepage
          Geez, people bash on the network transaprency all the time, while it's actually the least of the problems. And it's completely irrelevant when an application connects locally because it happens over a shared-memory IPC (which unix sockets actually is, despite having "sockets" in the name).

          I'd say all the old, device-dependent xfree86 code is to blame for most of the needless complexity and while it is being rewritten, it's a slow process that requires more developers than are involved with the project. Working with the new X.org code, while still demanding, wasn't really bad, just required thinking and getting "the bigger picture" well.

          Actually, the new code is perfectly capable of dropping network transparency, integration of needless extensions and so on *when it's appropriate*, just take a look at Kdrive. But still too many important things remain in the xfree86 part.
        • There's no reason the graphics system and drivers have to be anywhere close to the same project as the window manager.

          They aren't.

          Well, the drivers are. But obviously at this stage they DO have to be coupled to the server for a variety of reasons, not least that no one else wants to take over.

          But let's face it, twm hasn't had any major work in a long time, and the window managers we all use on a daily basis are nowhere near the X.Org codebase.

          Do we really need network transparency?

          Yes, we do need network transparency. I use it all the time. It's a major feature. Keep your hands off my network transparency!

      • by Jellybob (597204) on Wednesday June 11 2008, @08:33AM (#23746571) Journal
        Ahhh, because Windows' display manager is truly amazing.

        Now, let me just open an application on another machine, and show it on this one's X server... hmmm... what's that - I need to be running Windows 2008 Server, and have a terminal server license?

        How about running multiple display managers, so that I can have more then one person using the machine with seperate monitors and input... no. Thought not.

        I could go on, but I think you'll get the point.
      • Re:You Are (Score:5, Interesting)

        by jjohnson (62583) on Wednesday June 11 2008, @10:08AM (#23748067) Homepage
        How many people on here have the capacity to actually make a useful contribution to X.org? Leave aside the organizational complaints about delays in getting patches accepted or commit bits set.

        Your "provocative" posts are probably counterproductive if your intent is to get X.org some more community contribution. Legitimate complaints met with 'fix it yourself' are what push people to OSX.
  • by larry bagina (561269) on Wednesday June 11 2008, @07:55AM (#23746071) Journal
    It's Open Source -- unlike proprietary software, we're not at the mercy of a company to dictate the release schedule or fix bugs if they get around to it. If bugs aren't fixed, it's because we failed to fix them.
  • by mrchaotica (681592) * on Wednesday June 11 2008, @07:56AM (#23746081)

    From the article:

    At Phoronix we are even willing to offer -- cash and/or computer hardware -- bounties for having X.Org release schedules met and bug lists being cleared out.
        • by The Ultimate Fartkno (756456) on Wednesday June 11 2008, @08:30AM (#23746521)
          Bribery? I completely fail to see your logic here.

          BattleCat needs to have a bug fixed. He approaches coders who, for free and in their spare time, code.

          "Hey there, coderman. I see that you do this sort of thing for free and for fun, but what would you say to doing that coding thing that you love to do, hitting this one bug that I really need fixed, and ending up with all the satisfaction that you normally get from your work and a shiny nickel on top of it?"

          "ZOMGBRIBERYYOUCALLOUSBASTARD!"

          Really? Is that what you call bribery? Where I come from, bribery entails a breach of ethics. All BattleCat wanted was to add a little icing to the job that people were already doing for free in an effort to have something fixed that was a priority for him. That's about as straight-up, ethical, and non-bribery a way to get things done as I can imagine.
  • by elrous0 (869638) * on Wednesday June 11 2008, @08:00AM (#23746117)
    Oh, wait.
  • People aren't going to work on X because a lot of developers want to make new stuff, not fix up someone's old junk. So, the only way to get them to do it is to pay them. There's not enough money for that. Bounties are nice and all, but you really need to have a foundation with big money coming in to get the people to actually work on this stuff.
  • ID games? (Score:5, Funny)

    by couch_warrior (718752) on Wednesday June 11 2008, @08:09AM (#23746251)
    Clearly X.org is being held up because it is the new game engine for "Duke Nukem Forever"....
  • Paid developers? (Score:5, Interesting)

    by siride (974284) on Wednesday June 11 2008, @08:11AM (#23746269)
    Aside from Keith Packard and Dave Airlie, and maybe one or two others, how many paid full-time X developers are there? Watching the mailing list, it seems like there's a couple of volunteers, some people who submit the occasional patch but otherwise work on Qt, or GNOME or whatever, and then the core listed above. I think there just isn't enough manpower right now and the distros, instead of fixing that problem, just maintain their own patchsets and do a "good enough" job to make X work smoothly for their releases, and leave it at that. Clearly, nobody wants to make X a priority and it shows. The Wiki is almost never up to date, it's nigh on impossible to build a working X system from git, even with the couple of half-arsed build scripts available from the mailing list (for my part, I have never been able to get it to build completely, and not for lack of trying or ability). The mailing list is full of academic arguments over color specs and other pointless things, or people asking for help. There used to be a lot of discussion on how to improve X and also, how to get things done. That no longer happens. What the distros and Linux companies need to do is get more people working directly on X and get serious about making X a serious project. It's not just some option piece of software that nobody has to care about. It's only one of the most important aspects of desktop Linux. And it just makes no sense to me that no distros are really spearheading X development. If they don't take the time to make this an issue, X will continue to atrophy, further limiting Linux's potential in the market.
    • Re:Paid developers? (Score:5, Informative)

      by axxium.us (1305805) on Wednesday June 11 2008, @08:46AM (#23746749) Homepage

      What the distros and Linux companies need to do is get more people working directly on X and get serious about making X a serious project.
      Hi. I am the X11 maintainer for Zenwalk Linux. While I can't fix it all myself I have been updating the wiki and fixing documentation with the available time that I have to commit to it. I agree and think that if each GNU/Linux distribution had at least one developer helping in what we he/she can it would make a significant improvement.
  • by archeopterix (594938) on Wednesday June 11 2008, @09:17AM (#23747211) Journal
    Here [hack.org][pdf warning] is an interesting article from James Gosling and it pretty much explains why making the GUI system a server was necessary in the past but is not such a good idea anymore.

    Perhaps X should be replaced, not improved.

  • by jonsmirl (114798) on Wednesday June 11 2008, @09:18AM (#23747225)
    Three main trends got X to where it is.

    1) Proprietary hardware. NVidia and ATI didn't release specs. That resulted in what little dev talent there was being used to do reverse engineering. ATI has gone a long ways towards fixing this.
    2) Insistence on cross platform support. Cross platform support means no device drivers - everything in user space. There are all kinds of security issues with everything in user space. This also mean no integration with the underlying kernel. OOPS isn't visible, VT interaction, mode setting, no intergration with framebuffer, etc. Insistence on cross platform means that one OS can prevent progress from occurring on the others. There seems to be some movement on this issue.
    3) Failure to endorse OpenGL-ES as the core driver system. The embedded world went OpenGL-ES and ignores X (N810 is an exception). There is money in the embedded world and not in the desktop. The money went to OpenGL-ES.

    From a developer's point of view the architecture of X has not evolved in a way where a developer can work on one chunk of the code without having comprehensive knowledge of the entire system. Requiring that level of knowledge really reduces the number of potential developers. Finally there is a giant amount of NIH that goes on.
    • by Anonymous Coward on Wednesday June 11 2008, @08:06AM (#23746201)

      Do they still sing "network transparency out of the box" mantra every time someone suggests changing architecture ?
      That's the complaint you're going to go with? Seriously? Something that degrades gracefully into the ideal solution (shared mem and unix sockets) for a local-only graphics server?

      There's a LOT wrong with X.org right now, even mentioned in TFS. I personally wish they would put a lot more work into the transition to evdev and HAL, so we can get rid of xorg.conf and finally make strides to being as user friendly as "the other" OSes.

      But network transparency? You're fighting the wrong battles here.
      • by kaiman (234281) on Wednesday June 11 2008, @08:21AM (#23746401)

        But network transparency? You're fighting the wrong battles here.
        That is so true. Using Macs myself since a couple years. I have a recent MacBook Pro (mostly occupied by my wife) and an iBook G3 left for my stuff. While I can ssh into the MacBook Pro and do command line stuff fast, I so wish I could simply

            export DISPLAY=skarabrae:0.0

        and get actual work done fast!

        Network transparency is *the* feature of X.
    • by Anonymous Coward on Wednesday June 11 2008, @08:17AM (#23746339)
      Internally, X11 running in local mode works the same way as Apple's window server - using shared memory and local sockets. Hell, even Windows Vista works this way (except using Windows IPC mechanisms instead of Unix ones).

      Everyone who suggests changing the architecture of X by removing network transparency is arguing from a position of ignorance. There isn't a faster mechanism for doing a GUI server without either building the windows server into each app (allowing only one app at a time), or building the window server into the kernel (bad idea).
        • by siride (974284) on Wednesday June 11 2008, @08:49AM (#23746801)
          No windowing system has anything resembling widgets on the server-side. It's all done in client-side libraries, where that kind of stuff belongs. The server-exposed interface just provides the mechanisms needed for implementing widgets. That part is fine and doesn't need to change.

          As for the protocol, only a few parts are actually poorly designed. Grabs need to be reworked as they can result in subtle race conditions and lock-ups. There's a lot of old cruft that nobody uses that could go away, but isn't really causing a problem by remaining in the protocol. The main historical problem was Xlib, which did a lot of stupid things with the protocol, resulting in reduced performance, especially over the network. XCB fixes that, although no toolkits have been ported to pure XCB yet (and it may be a while).

          Ultimately what's going to be happening is the move towards Composite/EXA, OpenGL and DRI(2) for everything, which should negate a lot of the existing problems with X's rendering infrastructure. Again, the lack of manpower is going to prevent these projects from making much forward progress.
    • I agree wholeheartedly. The current release of X is suitable and works well for me.

      The "upgrade every year" mentality is the wrong one to have. They missed their date? Okay, that's fine. As long as they don't buckle under the "release schedule" mentality compromise quality. I may be naive, but I don't know any reason they would want to push/rush their next release.

      • by siride (974284) on Wednesday June 11 2008, @08:17AM (#23746337)
        It's not that they missed their date because they were busily fixing bugs and adding new features; they missed it because they're just not doing that much right now. There's no management, there's very little direction, and there's really not that much going on at all. That's not a good thing.
    • by Chemisor (97276) on Wednesday June 11 2008, @08:37AM (#23746627) Journal
      Well, excuuuse me! Blame the community. I would blame the code instead. I happen to be one of those few people who actually wanted to contribute something. Specifically, there was this bug where the server would crash after a VT switch, so I thought I'd take a look. Have you seen the X.Org tree? It's not just huge. It's unreadable. I honestly didn't even know where to start. Documentation was minimal. If you wanted to trace one of your Xlib calls, you wouldn't be able to. There are modules, but they don't seem to have any clear purpose. There are libraries that are wrappers around something which is a wrapper around something else. Try and find the real code! I dare you! Even just building the damn thing is a major ordeal. With the current XOrg tree from git, I can't do it at all. Yes, that's right: I can't even compile it, and that ought to be the simplest thing you can do with a project. You want to know why I'm not helping the XOrg project? Because it's a pile of steaming crap, that's why, and I have better things to do with my time than trying to build a windowed skyscraper out of it.
      • Re:Lazy Developers (Score:5, Insightful)

        by lysse (516445) on Wednesday June 11 2008, @11:42AM (#23749877)

        There are developers and users, and if the developers want to go open source they damn well need to accept that fact.
        I have to say that I believe you are completely and utterly wrong about this. The segregation of users into developers and consumers is something that only happens when you actively prohibit the latter from being able to become the former - for example, by locking up the source code in the safe of trade secrecy. The whole point of free software is to break down the barriers between the two - to allow anyone to dip into development any time they need to, without subjecting them to restrictions or limitations. It's about empowerment. Of course, not every user will participate in development, for a whole range of reasons - but no user is prevented from doing so; every user is allowed to participate. And in that climate, the idea that there is some big glass wall between the developer and the user is simply ridiculous.

        I am a huge Linux advocate, but...
        Why does that comment sound so much like "I'm not a racist, but..."? Perhaps some of your best friends are penguins...?