Announcement

Collapse
No announcement yet.

KDrive, Xnest, Xvfb Called For Removal From X.Org

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

  • KDrive, Xnest, Xvfb Called For Removal From X.Org

    Phoronix: KDrive, Xnest, Xvfb Called For Removal From X.Org

    X.Org developers are currently discussing the possibility to remove the KDrive, Xnest, and Xvfb technologies from the X.Org Server, citing that their functionality has been superseded by better alternatives and this could lead to trimming the xorg-server by over 30,000 lines of code...

    http://www.phoronix.com/vr.php?view=MTA3NzY

  • #2
    There has to be a better reason than "it removes 30,000 lines of code".

    Comment


    • #3
      Well, Xfbdev hasn't been usable in several releases (they broke both keyboard and mouse in 1.3, IIRC). While I personally use many of the would-be-kicked and already-kicked servers, it's quite understandable when the people who use them (mainly embedded folks, with little to none X dev experience) aren't the people who maintain X.

      Comment


      • #4
        From my experience using Xephyr and Xnest, most of them have little things broken everywhere.
        If they are not maintained and are untested, it's better to remove them than to leave users frustrated with crashes and other problems.

        Comment


        • #5
          Originally posted by johnc View Post
          There has to be a better reason than "it removes 30,000 lines of code".
          There is: this seems to be unused code/duplicated functionality.

          Comment


          • #6
            Originally posted by [Knuckles] View Post
            From my experience using Xephyr and Xnest, most of them have little things broken everywhere.
            If they are not maintained and are untested, it's better to remove them than to leave users frustrated with crashes and other problems.
            So it's better that users have no software than buggy software?

            I've used Xnest, Xvfb and Xephyr for various things in the past, and would hate to see them go.

            At the least, I really think they should wait 'till all the functionality of these servers which aren't currently available in the DDX drivers are implemented first before removing the servers, it'd provide motivation for whoever wants the servers removed to actually get the work done, whereas if the servers are removed first then we will likely never see some of the functionality re-implemented, and will effectively be removing functionality for no good reason.

            And before someone mentions "removing 30,000 lines of code" as a good enough reason, I wonder how much of that code actually affects the Xorg server itself?
            Pretty sure they're all separate code trees within the source tarballs...

            Anyways, from reading through the mailing list messages looks like it's gonna happen regardless of what I or other end users think.

            Comment


            • #7
              So wait, what's the better solution that supersedes Xephyr?

              Comment


              • #8
                Again...

                I imagine it will be better to just keep the support for X by I/O Kit on macosx, preferably only for the latest version. It should seriously reduce the number of lines.
                "
                - Please, can someone can explains me where is Xnest ?
                - I don't know I don't work on deprecated code, you can use an older version. You can search the git repository yourself, compile the code, reimplement it... do whatever you want, it's free software.
                - Thanks.
                "

                Comment


                • #9
                  Sounds good to me, X have a lot of bloated functionality

                  Comment


                  • #10
                    Originally posted by Alex Sarmiento View Post
                    Sounds good to me, X have a lot of bloated functionality
                    But if it never hits, it doesn't matter right?

                    Only to those who want to use it, of course.

                    Comment


                    • #11
                      Originally posted by johnc View Post
                      But if it never hits, it doesn't matter right?

                      Only to those who want to use it, of course.
                      I didn't say that that functionality should be lost.

                      Comment


                      • #12
                        Originally posted by Sadako View Post
                        And before someone mentions "removing 30,000 lines of code" as a good enough reason, I wonder how much of that code actually affects the Xorg server itself?
                        Well, it does increase the size of source tarballs/git pulls, and unless there's a configure option to disable the stuff, it increases build time. That's good enough for me..

                        Comment


                        • #13
                          Originally posted by johnc View Post
                          So wait, what's the better solution that supersedes Xephyr?
                          I'm wondering this as well.

                          Comment


                          • #14
                            I think the general idea is "if it's broken and unmaintained, then we should chunk it" (as highlighted earlier), as well as, "if we chunk it, others (who need the functionality) will be more likely to create their own (possibly better) solution and maintain it"...or something along those lines.

                            Comment


                            • #15
                              Wow it really seems like there aren't many thinkers in this forum today.

                              The article did NOT say xephyr is being removed, xephyr is pretty much the successor and replacement of xnest. xephyr may be glitchy but its a hell of a lot better than xnest. As for the other 2, they're just simply not needed. I'd like to know 10 people who actively uses them and prefers them over their replacements.

                              As for people acting like cleaning up 30K lines of code for features that are blatantly obsolete is pointless, I can't even comprehend the irrationality of such a thought. That's like someone gives you a 2Lbs steak for you to eat and then they suddenly decide to remove the bone before giving it to you, which would then reduce the physical size and the weight to maybe 1.5Lbs. Oh no! What if I wanted to carry that extra volume and weight with me on my way home! Maybe I wanted to throw out that bone in my own trash! What a nerve!

                              Seriously, how is it NOT obvious why code needs to be cleaned up.

                              If I haven't made my point clear enough, I think removing these features is a great idea. In fact, I'm surprised there isn't more being removed.

                              Comment

                              Working...
                              X