Announcement

Collapse
No announcement yet.

Sadly, Two X.Org GSoC Projects Already Failed

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

  • Ericg
    replied
    Originally posted by Ancurio View Post
    Wayland does no networking whatsoever; buffers are passed directly via local system handles, and communication happens over unix sockets. The point is, it doesn't have to be. Frameworks like VNC have proven that accessing a desktop over the network can be handled (almost) completely separate from the windowing system.
    You obviously never read my Wayland writeup haha. You're right in that Wayland has no 'built-in' concept of networking. That being said, the protocol and the extensions are efficient enough that a Networking is expected to be a very simple addition. The latest mailing list post I saw was to constantly track screen-damages and send the changed pixels over the wire (much like VNC), granted that was a few months ago so it could've changed since then. We can always do better though, perhaps Linux will have a proper RDP replacement soon that's a bit more efficient than pixel-scrapping.*

    *Just search "limitations of vnc", you'll find a few comparisons between VNC vs RDP vs X11 Network Transparency, VNC(-style) is the most flexible but its not the most efficient.

    Leave a comment:


  • Ancurio
    replied
    Originally posted by Ericg View Post
    Wayland. XWayland will handle backwards compatibility, Wayland can also do networking better than X.
    Wayland does no networking whatsoever; buffers are passed directly via local system handles, and communication happens over unix sockets. The point is, it doesn't have to be. Frameworks like VNC have proven that accessing a desktop over the network can be handled (almost) completely separate from the windowing system.

    Leave a comment:


  • Daktyl198
    replied
    Originally posted by doom_Oo7 View Post
    So we keep features from X9, X10, X11 ?
    lol, nah. Like Wayland wouldn't remove any features in versions 1.0 - 3.0, then when Wayland hits 4.0, it can remove features from the 1.0 release, but not 2.0/3.0. Then on the 5.0 release, it can remove features from 2.0, etc etc. I figure this gives a couple years of availability for features (it's not like major version shifts happen every month, right?), but allows us to not be using legacy crap 30 effing years down the line like what we're doing with X.

    The key word here is "can". 99% Features will most likely live for more than 3 major versions, it just gives the project some breathing room when it comes to maintaining old and crappy code :P

    Leave a comment:


  • doom_Oo7
    replied
    Originally posted by Daktyl198 View Post
    while keeping AT LEAST 3 major versions with a feature available for those who need it.
    So we keep features from X9, X10, X11 ?

    Leave a comment:


  • Daktyl198
    replied
    Originally posted by BradN View Post
    Maybe i'm in the minority but I think what X needs is aggressive refactoring and code cleanup in the name of maintainability. Backwards compatibility and network transparency are its strongest assets I think. Or at least, any X replacement should make those features first class citizens. We use network forwarding every day in particular, and on relatively old hardware too. It's usable even on a crappy 100 megabit network...
    I don't know how many times it has to be said, but modern X's components (DRI, etc) are NOT network transparent anymore! It is Network Capable, just like Wayland. If you want to use X.org's Network Transparency, you pretty much have to use it's oldest components that are still "maintained".

    As for backwards compatibility, I think there needs to be a limit. Like, you can't remove a feature added 3 major releases ago or less. With that, we'd be able to clean up old crap nobody uses in newer releases, while keeping AT LEAST 3 major versions with a feature available for those who need it.

    Leave a comment:


  • mattst88
    replied
    Originally posted by magika View Post
    Why is everyone so negative about these projets? I see only one thats is for X Server (QtQuick compositor). Rest are Mesa/Wayland projects, and you want them to fail?
    Complete cluelessness and a total inability to perform basic reasoning.

    Leave a comment:


  • magika
    replied
    Why is everyone so negative about these projets? I see only one thats is for X Server (QtQuick compositor). Rest are Mesa/Wayland projects, and you want them to fail?

    Leave a comment:


  • smitty3268
    replied
    Originally posted by BradN View Post
    We use network forwarding every day in particular, and on relatively old hardware too. It's usable even on a crappy 100 megabit network...
    Is this some kind of joke? What kind of system could possibly fail on a 100mb network, it would have to be awful.
    Last edited by smitty3268; 27 June 2014, 03:25 PM.

    Leave a comment:


  • Ericg
    replied
    Originally posted by BradN View Post
    Maybe i'm in the minority but I think what X needs is aggressive refactoring and code cleanup in the name of maintainability. Backwards compatibility and network transparency are its strongest assets I think. Or at least, any X replacement should make those features first class citizens. We use network forwarding every day in particular, and on relatively old hardware too. It's usable even on a crappy 100 megabit network...
    Wayland. XWayland will handle backwards compatibility, Wayland can also do networking better than X.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by 89c51 View Post
    Which was the other one that failed?
    Probably tesselation support in mesa, i think i heard that guy went missing without giving notice. Another volunteer has asked to start working on it, hopefully he makes better progress.

    Leave a comment:

Working...
X