Announcement

Collapse
No announcement yet.

It Looks Like X.Org 7.5 Will Be Released Late

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    There's one fundamental difference between X and the kernel that I haven't heard mentioned here. Linux for servers is a thriving and profitable business; Linux for clients (desktop, laptop, PDA, phone etc..) is promising and might make money outside of a few narrow niches one day.

    Server ($$$) and Client (?$) both need the kernel; only client needs X, so much more $$ flows into kernel than into X.

    Given the resources that are being made available for X vs the complexity of the features being demanded (functional parity with Windows but on perhaps 1/50th the investment) the development work is going surprisingly well. There is not a big demand for schedule predictability from the groups and individuals contributing resources, but there is a big demand for progress, and that results in the project management model (take aim, write down the plan, then everyone develops like crazy until it's done) you see today.

    The spirit among the developers is very enthusiastic and positive; everyone seems to be trivializing Dave's comments. His point is not that priorities and approaches are being set based on the whims of the developers; his point is that many of the developers are working for successful companies with clear priorities, and those priorities are where the developers spend *most* of their time.
    Last edited by bridgman; 07-16-2009, 10:01 PM.

    Comment


    • #32
      Originally posted by bridgman View Post
      (take aim, write down the plan, then everyone develops like crazy until it's done)
      You forgot the final step........ BEER!!!!!

      Comment


      • #33
        Originally posted by deanjo View Post
        You forgot the final step........ BEER!!!!!
        Good point... actually from the few conferences I have attended it seems the sequence is "take aim, BEER, write it down, implement like crazy..."

        I think I see the problem.

        Comment


        • #34
          Originally posted by bridgman View Post
          There's one fundamental difference between X and the kernel that I haven't heard mentioned here. Linux for servers is a thriving and profitable business; Linux for clients (desktop, laptop, PDA, phone etc..) is promising and might make money outside of a few narrow niches one day.

          Server ($$$) and Client (?$) both need the kernel; only client needs X, so much more $$ flows into kernel than into X.

          Given the resources that are being made available for X vs the complexity of the features being demanded (functional parity with Windows but on perhaps 1/50th the investment) the development work is going surprisingly well. There is not a big demand for schedule predictability from the groups and individuals contributing resources, but there is a big demand for progress, and that results in the project management model (take aim, write down the plan, then everyone develops like crazy until it's done) you see today.

          The spirit among the developers is very enthusiastic and positive; everyone seems to be trivializing Dave's comments. His point is not that priorities and approaches are being set based on the whims of the developers; his point is that many of the developers are working for successful companies with clear priorities, and those priorities are where the developers spend *most* of there time.
          What he said :-)

          Red Hat must be still making money (even in this dark time, profits are good) and they keep paying me, so I must be doing something right ;-)

          Our customer requirements for the Linux desktop were once described as "pretty and fast". This funded kernel modesetting, customers actually hated the bootup blinking that much.

          Dave.

          Comment


          • #35
            Don't you hate it when you make a spelling error (there/their, second last word in airlied's quote) and then someone quotes you before you can fix it ?

            Comment


            • #36
              Back on the original topic, the only complaint here is that everyone shouldn't look at Xorg release schedules as promises, as stated already, but perhaps that push partially stems from wanting to ask for development help in a round-about way. Regardless, X is important to Linux reaching desktops/etc, so may efforts to de-cruftify, rebuild, or feature-fortify graphical systems for Linux continue to be successful. ^^

              I'll continue supporting through bug reporting until I learn more. :P

              Comment


              • #37
                ..Those companies (off the top of my head: AMD, Apple, Canonical, Nokia, nVidia, Red Hat, Sun, SUSE, Via, VMWare) already provide manpower. People like myself, and many other developers, do contribute code..
                You're bluffing, right? 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.. Ten Companies, and more..
                hm.. IF ONLY each companies providing 3 manpower, then X.org have about 30 devs, + other developers.

                Btw, how much the minimum number of devs do X.org have so that X.org can have a constant and not-late release?

                CMIIW. Sometimes, it's just not logic for me, why companies that stated above (if its true) have THAT LITTLE CONCERN to X.org?
                Some of them said that they want to make linux a desktop-operating-system, rite? rite? And I guess, to have a better desktop on linux, we must have better X (and kernel?), rite? right? RIGHT? (IMO then, why can't they drop more devs on X.org to make that happen faster?)

                PS: like somebody said before, it can be hurt to start making documentation bout X.org We all know that it will be much help for X.org it self in the future.

                -- end of bitching here --

                Oh, and don't forget, we do appreciate your (all of you, devs) work
                Last edited by t.s.; 07-17-2009, 05:57 AM.

                Comment


                • #38
                  For whom may be interested:

                  This morning I just stumbled across a talk by Theo de Raadt about
                  OpenBSD's release management/process. At 6:55 he comments on X11.

                  The OpenBSD Release Process

                  Comment


                  • #39
                    Originally posted by entropy View Post
                    At 6:55 he comments on X11.[/URL]
                    Comments and talks for several minutes of how he disapproves with the modular X system and how it is maintained.

                    Comment


                    • #40
                      Originally posted by drees View Post
                      Frankly, Dave is right.

                      Bitching about why something is late or behind schedule without any offer to help or provide solutions does nothing but aggravate the developers.

                      Look at it from Dave's point of view - he spends his life toiling away working on X code which most would consider hardly glamorous or exciting.

                      He is already over worked and under appreciated, and now a bunch of users start bitching because the schedule has slipped without offering up any real help or solutions?

                      Please - ignoring the flames that occur when a schedule slips is the only way to remain sane.
                      This is pretty much it, yeah. Even if you cast aside the ideological 'they're too developer-focussed, they need to concentrate on the users' issue -- and you'd be insane to think that developers don't write software for users, aside from Theo de Raadt -- try pragmatism.

                      If all the developers eventually get discouraged and leave, the software won't get written, by definition. So if you want the software to advance, these threads probably aren't the way to go. When I finish my day job (X development, but not 1.7 or XKB2), it's a choice between going out and seeing my friends or a night in spent hacking X. Looking at the timestamps on IRC and commits from everyone might be fairly instructive as well. Plus, you never know, someone might be confined to bed all day with inflamed discs in his back, taking fewer painkillers in order to still be able to write code.

                      xserver 1.7 is in code freeze, as per the schedule (which was never announced as anything but a plan, as made plain in the emails and the subject), and the remaining work is Peter's Xi stabilisation, the final bits which need to be done in master and general bugfixing as well. The tree isn't exactly hugely unstable with massive amounts of disruptive work landing every day, so there's been no need to branch as far as I'm concerned. XKB2 (which is badly behind schedule) is the last big thing to get merged, and then I imagine it will get branched fairly soon after.

                      Code freeze in three days is plainly unrealistic, and the rest of the schedule pretty much hinges on when we get to that point, so it just depends on when it's stable enough to branch and declare full code freeze.

                      Anyway, back to it.

                      Comment


                      • #41
                        As a Debian Experimental user with the latest xorg-edgers packages from Ubuntu installed, I must say that as of a couple days ago, X is now perfect. Two years ago it was pathetic: I could not play Torcs even at the lowest resolution with a Core2Duo and a G33 chipset, with a frame rate slower than 1 fps.
                        Two days ago not only could I play it perfectly smoothly at 1280*1024, but for the first time (thanks to this smoothness) I won the Alpine race at the amateur level on my keyboard.
                        Now that I am a champion, it is obvious X is a champion too!

                        Comment


                        • #42
                          The Intel driver has gotten orders of magnitude better. My g45 is faster in linux than windows with opengl (nexuiz). Just some stability problems to work out, and maybe gallium will help even more.

                          Comment


                          • #43
                            Originally posted by DebianAroundParis View Post
                            As a Debian Experimental user with the latest xorg-edgers packages from Ubuntu installed, I must say that as of a couple days ago, X is now perfect.!
                            I dream that in a couple of years you could well use Debian stable and *still* have basic functionality with open drivers for your card which would at that point mean working and relatively fast 2D/3D accel. ^^ I'd suspect it would probably decrease the demand for pushing new X.org versions out a bit that average user actually gets what they need even with older versions of the components. You may call me a dreamer but hey, is it a crime? :3

                            Comment


                            • #44
                              Originally posted by nanonyme View Post
                              I dream that in a couple of years you could well use Debian stable and *still* have basic functionality with open drivers for your card which would at that point mean working and relatively fast 2D/3D accel. ^^ I'd suspect it would probably decrease the demand for pushing new X.org versions out a bit that average user actually gets what they need even with older versions of the components. You may call me a dreamer but hey, is it a crime? :3
                              If you have a 5 year old GPU, since debian stable doesn't backport pci ids or anything like, you won't get any suppor for newer gpus unless that sorta stuff takes place.

                              Like RHEL5.4 supports newer GPUs out of the box for 2D way better, but that stuff doesn't come for free.

                              Comment


                              • #45
                                Originally posted by airlied View Post
                                If you have a 5 year old GPU, since debian stable doesn't backport pci ids or anything like, you won't get any suppor for newer gpus unless that sorta stuff takes place.

                                Like RHEL5.4 supports newer GPUs out of the box for 2D way better, but that stuff doesn't come for free.
                                You know, in your case it's a bit hard to say how much of the observations considering RHEL and its competitor distros are objective and how much are not. That pci id thing is a problem though admittebly.
                                I was mostly pondering about the up-coming infra though, like that on radeon side r6xx/r7xx 3D gets done, KMS+ttm gets done. I mean, support's not going to just magically vanish anywhere and sooner or later (we might be talking of years again) even Debian stable should have working OpenGL rendering.
                                I'd personally prefer pci id listings to get somehow versioned separately so distros could integrate pci id's for new GPU's faster (as they are unlikely to break existing functionality) without actually updating the driver to a newer version where possible. (since changes in other parts of the driver might cause more breakages) Something more dynamic in the area would be imo neat.
                                Edit: I realize the idea means distros get left without chip-specific fixes that are put in arbitrary git versions but it's meant as more of a compromise than a real win-win scenario anyway.
                                Last edited by nanonyme; 07-17-2009, 09:23 PM.

                                Comment

                                Working...
                                X