Announcement

Collapse
No announcement yet.

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

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

  • #21
    Originally posted by DanL View Post
    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..
    There are configure options for each of the servers proposed for removal, the compressed source tarball is around 5 MB, removing 30,000 lines of code wouldn't make a big dent in that, and considering how little work is done on these components it would only affect a "clean" git checkout...

    Originally posted by schmidtbag View Post
    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.
    I'm fairly certain the removal of Kdrive implies the removal of Xephyr, especially considering the mailing list post basically stated xorg-server ddx drivers can and should be used instead, if this is true for xnest how is it not true for Xephyr?

    Originally posted by Delgarde View Post
    If those 30,000 lines aren't doing anything useful, then no, they don't need a better reason.
    If people are actually still using the servers, and are using functionality in those servers not currently available in the ddx drivers then are those 30,000 not "doing something useful"?

    Comment


    • #22
      Doesn't xrdp use Xvfb? I've seen Xvfb processes running when I initiate an xrdp session with my server.

      If they're planning to take that away, xrdp would have to use a different solution, which could impact a lot of code in xrdp. Xrdp is the only viable (efficient) free software remote desktop solution for Xorg right now, because the NX projects such as FreeNX are at a standstill and are not being maintained/improved/supported in modern distros. Even Google's NX project, NeatX, hasn't had any commits since February 25, 2010, and it doesn't work quite right in its current state. The only other option is to use the closed source NoMachine NX product, which has its own problems (extreme difficulty/impossibility to use with nonstandard SSH port and public key authentication).

      Please don't kill xrdp by killing Xvfb!

      Comment


      • #23
        By the time X.org removes something it's generally been unusable and unmaintained for at least two or three years.

        Comment


        • #24
          Originally posted by allquixotic View Post
          Please don't kill xrdp by killing Xvfb!
          I can't answer your particular question, but from what I've read in the thread it sounds like there is or will be a usable alternative. And anyway, by the time this effects you, someone will likely have already written a script or program that does what you want...that is unless you're on the bleeding edge, but that's the risk you take (thus the name).

          Comment


          • #25
            Keith Packard

            I wanna hear Keith Packard's opinion about this.
            Before I make up my mind.
            I don't know what Keith thinks about this, but I would agree with him.

            Comment


            • #26
              Originally posted by schmidtbag View Post
              The article did NOT say xephyr is being removed
              The patch does.

              hw/kdrive/ephyr/.gitignore | 1 -
              hw/kdrive/ephyr/Makefile.am | 90 --
              hw/kdrive/ephyr/README | 73 --
              ....

              Comment


              • #27
                An attempt to give a rational review:
                Xvfb:
                Used by several packages' test suites, for automated testing. Drop it, and iceweasel/firefox/... have to
                A. Drop automatic testing on X11, OR
                B. Run test suites as root (not fakeroot, full root) (means packages must be built as full root)
                Also, Xrdp does have reasons for existing.

                Xnest:
                Drop it. Now. If you add a symlink to Xephyr, fine.
                (provides subset of Xephyr functionality)

                Xephyr:
                Don't think about dropping this, until users can specify drivers or X autodetects when it's run nested via DISPLAY.
                Useful for keeping experiments confined to one X server, while working on stuff separately.

                Xfbdev:
                Really, they should have dropped this instead of Xvesa. But don't think about dropping it now.
                At one point (2010-early 2011), I got this and Ubuntu running with an i915 card.
                May sound pointless, until you understand that this wasn't a full ubuntu: it was a recovery cd stuck on a 512 MB U3 USB drive, with the rest of that used for storage. Using full Xorg would have been hopeless.

                [rant]
                Oh-and-by-the-way,
                Whoever thinks xaa should die had better fix up EVERY driver that still needs it before they commit the change. Breaking embedded hardware like this is NOT the way to win the market; most such boards use a non-EXA driver.
                The argument that "the drivers are obsolete and rarely used" is about as intelligent as a desktop user saying "We should really get rid of Apache--it's rarely used, and has had several security holes". You may not see the users, but that doesn't mean they're not there; it's just a different field.
                Do you really want Windows CE/Mobile/whatever MS named it today taking over the embedded market?
                [/rant]

                Comment


                • #28
                  Originally posted by Ibidem View Post
                  [rant]
                  Oh-and-by-the-way,
                  Whoever thinks xaa should die had better fix up EVERY driver that still needs it before they commit the change. Breaking embedded hardware like this is NOT the way to win the market; most such boards use a non-EXA driver.
                  The argument that "the drivers are obsolete and rarely used" is about as intelligent as a desktop user saying "We should really get rid of Apache--it's rarely used, and has had several security holes". You may not see the users, but that doesn't mean they're not there; it's just a different field.
                  Do you really want Windows CE/Mobile/whatever MS named it today taking over the embedded market?
                  [/rant]
                  Where did you see an embedded system running uptodate software? Such obsolete hardware is most likely still running Linux 2.4 with XFree86.

                  And nobody is going to switch their EOL hardware to M$ crap, M$ wouldn't offer support anyway. Only for new hardware there is this chance, and they drop old code so that they can provide better features/performance for new hardware, so where is the problem again?

                  Or do you think embedded means last decade's failed desktop hardware? Because that's what the link you posted suggests.

                  Comment


                  • #29
                    These servers are able to be removed because their functionality can be accomplished in part (and hopefully, eventually in full) by xf86-video-nested.

                    Comment


                    • #30
                      Originally posted by Ansla View Post
                      Where did you see an embedded system running uptodate software? Such obsolete hardware is most likely still running Linux 2.4 with XFree86.

                      And nobody is going to switch their EOL hardware to M$ crap, M$ wouldn't offer support anyway. Only for new hardware there is this chance, and they drop old code so that they can provide better features/performance for new hardware, so where is the problem again?

                      Or do you think embedded means last decade's failed desktop hardware? Because that's what the link you posted suggests.
                      I'm not so sure you're correct on the MS part, much as I hate them; but leave that for now.

                      That fellow is doing a new design with Debian Squeeze/kernel 2.6.32 + Xorg 7.5, which is a far cry from 2.4 + XF86 (in case you weren't paying attention, the last Debian version with a 2.4.x kernel and XF86 was 3.1 not 6.0, so you're 5 years behind the times on that.)
                      The board isn't one I picked, it's one his company picked.

                      If you're going to through out claims to 'refute' what I say, you could at least verify that they match reality and each other!

                      Much as you may want to think that what failed on the desktop is dead, that's wishful thinking.
                      Go find a PC104 board that has NVidia graphics of any age/ION, or an AMD Radeon 3xxx or better, or find any x86 board listed as "embedded" that's halfway up-to-date.
                      The closest I've seen is an Atom board and a few of Via's designs; those might work reasonably if the graphics work, but even 'new' designs have to be compatible with the old ones to some extent, and switching from PC104 to (say) micro-ITX may not be possible due to those constraints.
                      I've even found a company selling 'embedded' boards based on an AM186; they also carry an Am386 based system that comes with Linux 2.2.
                      I could point out several examples of out-of-date hardware if I wanted, but checking the aforementioned ones should prove that much of the embedded/x86 stuff is very much 'the last decade or two's failed hardware. Gripe all you like, but if the hardware is from the last decade, they're unusually current--or are you going to pay them the (wag) $20/device they'd spend on going with real up-to-date hardware?

                      Comment

                      Working...
                      X