Announcement

Collapse
No announcement yet.

Wayland Preparing For 1.0 Stable Release

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

  • #16
    Originally posted by smitty3268 View Post
    What this whole thread was about?
    Nobody in that thread was able to provide any sense of clarity about how network transparency is or is not going to exist in a Wayland display context and how it will or will not be different from X. Sure, workarounds were offered, but can you read that thread and say, "Surely we're in good hands here; there is a clear understanding of how network transparency is an important function."

    I didn't get the warm fuzzies.

    When it's up and mature and if it can do everything X can do, and do it at least as well, and the binary drivers play nice, yeah I'm definitely on board and can't wait to move up. But I hope I'm not asking for too much there. Or perhaps the whole "hey let's deprecate functionality" mentality that has been all the linux rage these days has made me bitter. Because seriously... if the goal is to make linux as shitty as Windows, somebody please let me know so I can switch back now and get a head start.

    Comment


    • #17
      Originally posted by smitty3268 View Post
      Experienced X developers: Look at the new shiny Wayland we're creating. It's better than X in every possible way.

      Masses: Oh noes - you don't list network transparency as a feature. Doom, Doom, Doom.

      Experienced X developers: Right, because that will be taken care of by the layer above. It's much better that way.

      Masses: You can't get rid of [implementation detail] "network transparency". Doom!

      Experienced X developers: Really, it's trivial. All you have to do is run an alternative compositor on Wayland that would scrape the buffers, compress them, and send them over the network. It's far more flexible than the X system, and also gives better performance. For the moment, we aren't even going to bother with this trivial detail because at the start everyone will be using X apps anyway and it will work the same. It will only matter after several years of use when native apps start being used.

      Masses: I don't trust these devs. They're obviously going to screw up network transparency. I'm not sure why, i just think they will. Look at windows, it doesn't have X and it sucks.
      Yes, let's come up with a design several years after we start writing code. How could anybody think we'd end up having to hack something in like was done in Windows?!

      Comment


      • #18
        Originally posted by johnc View Post
        Nobody in that thread was able to provide any sense of clarity about how network transparency is or is not going to exist in a Wayland display context and how it will or will not be different from X. Sure, workarounds were offered, but can you read that thread and say, "Surely we're in good hands here; there is a clear understanding of how network transparency is an important function."

        I didn't get the warm fuzzies.
        http://lists.fedoraproject.org/piper...er/145309.html

        When it's up and mature and if it can do everything X can do, and do it at least as well, and the binary drivers play nice, yeah I'm definitely on board and can't wait to move up. But I hope I'm not asking for too much there.
        Define "everything". I suspect you mean it just can do network transparency - there are literally hundreds of deprecated X features that no one uses anymore. The fact that you think this feature is going to disappear honestly baffles me. Where does this mindset come from? Do you think Red Hat is going to start shipping RHEL without the ability to use remote apps like they currently can?

        Because seriously... if the goal is to make linux as shitty as Windows, somebody please let me know so I can switch back now and get a head start.
        FUD. This is FUD. Because seriously - no one has the goal of making linux shitty.

        If you do want to go to an OS that never changes, you should probably look into moving to a Unix flavor. Because other OS's all look to improve over time, and that means throwing away crap. Like X.
        Last edited by smitty3268; 02-01-2012, 01:15 AM.

        Comment


        • #19
          Originally posted by johnc View Post
          When it's up and mature and if it can do everything X can do, and do it at least as well, and the binary drivers play nice, yeah I'm definitely on board and can't wait to move up. But I hope I'm not asking for too much there. Or perhaps the whole "hey let's deprecate functionality" mentality that has been all the linux rage these days has made me bitter. Because seriously... if the goal is to make linux as shitty as Windows, somebody please let me know so I can switch back now and get a head start.
          Sure. If you want to switch, go ahead and do that. There is no point in sticking around if you can't trust the X developers to know what they are talking about. On the other hand, if you to wait, that's great. Nobody is forcing you either. In fact, the thread itself clearly stated several times that Wayland will take time to be adopted. This is why it is explicitly designed to be run in parallel.

          Comment


          • #20
            Originally posted by smitty3268 View Post
            The fact that you think this feature is going to disappear honestly baffles me. Where does this mindset come from? Do you think Red Hat is going to start shipping RHEL without the ability to use remote apps like they currently can?
            Where does the mindset come from? How about there doesn't seem to be any serious consideration for network transparency at the design phase? It almost seems like that kind of thing just really isn't that important. Yes, there's a lot of hand-waving, "ohhhhh, welll... you can run X on top of Wayland to run remote apps..." Seriously -- why would I want to do that? Ok, eventually X will be phased out... and then something else will have to be implemented. That "something else" really hasn't been designed yet as far as I can see. I'm sure they'll come up with something. Of course RH will have remote app functionality. Microsoft can check that box too. Maybe we'll end up with something like VNC... wouldn't that be awesome? So will the brunt of the work be done on the server or on the client? Wouldn't it be nice to know some of these things as we're coming upon a "stable release"?

            I understand that X is a turd and it'd be great if it was replaced with something better. I'm sure Wayland will be better. Maybe in practice the benefits won't be obvious to the end-user. But I just said what I feel -- that that thread didn't inspire any confidence in me that network transparency is even in the top thousand (<-- that's hyperbole btw) areas of concern for Wayland devs. Hopefully I'm wrong. We'll just have to cross our fingers, keep our mouths shut, and place our trust in them.

            FUD. This is FUD. Because seriously - no one has the goal of making linux shitty.
            Ok... maybe "goal" was the wrong word, but in practice that is often what we get. We can look to our "Experienced GNOME developers" for evidence of that.

            Comment


            • #21
              Originally posted by johnc View Post
              ...
              Everything you say just confirms my original feelings about this subject. It seems we've gone full circle. Good night, and hopefully Red Hat doesn't decide to torpedo their entire business just because they felt like it. That'd be unfortunate.

              Comment


              • #22
                i am quite surprised that they are approaching 1.0 stable so fast.

                i was expecting a long(ish) testing period with fully functional desktops -just in case something goes wrong and to fix minnor stuff here and there- and then release 1.0

                props to the devs

                Comment


                • #23
                  Originally posted by johnc View Post
                  Where does the mindset come from? How about there doesn't seem to be any serious consideration for network transparency at the design phase?
                  Because there doesn't need to be any. You're either missing some bit of information here, have a grotesque misunderstanding of some of the Wayland fundamentals, or are just being obtuse. :/

                  Let's ignore the network for a moment and just try to understand how Wayland works. That'll make the network bit much easier to understand.

                  The Wayland protocol lets clients connect to what is essentially just a compositor and input manager. All rendering happens on the client application. The client application posts updated frame buffers to the compositor. Wayland composites all the clients onto the "display." Wayland delivers input signals to the clients. A few other bits are also done, but that's pretty much the gist of it.

                  The cool bit of Wayland is that the "display" and input event sources do not at all need to actually be a physical display or OS input devices. They can easily be an X11 window. They can be a hidden surface inside a GUI app test harness that sends scripted input to the apps and records and diffs output frames. They can an offscreen buffer used for compositing over X11, which is what KWin is working on doing (so your Wayland native apps run over X11) and what Weston can already do. They can be just about anything you want, because all the protocol does is coordinate framebuffer updates and handle input events and the like. None of these new applications or special configuration require any kind of new protocol changes. The protocol already works for all of these cases, and more.

                  This is where networking comes in and becomes so easy. There is no need for Wayland support for networking because Wayland already does everything you'd need to support networking. Since the Wayland server/compositor can easily be any random app (which doesn't even need to have a graphical display of any kind) it's _already supported_ to just drop in any possible networked proxy or remote display system you want. Want VNC? Just write a VNC client that's a Wayland server. Want SPICE? SPICE client that's a Wayland server. Want HTML5? HTTP server with streaming WebM and WebSockets that's a Wayland server. Want something specifically optimized for per-window low-latency low-bandwidth WiFi/Internet remoting of desktop applications? Figure out that new protocol, write a client/server for it, and make the client a Wayland server. _None of these_ will require a protocol change or changes to any Wayland-based applications.

                  No changes to Wayland itself are needed, period. That's why the Wayland folks are saying they'll worry about it later: because they _can_, because the protocol was designed to be separate from the networking half. It does not need -- nor is there any reason to even want -- the networking aspect to be built into the Wayland protocol itself. The network proxy stuff hasn't appeared yet because nobody who actually does anything but whine has bothered to write one. It's not because Wayland needs some future extension or changes that are being ignored.

                  There is something lost by this approach which X11 offers. That is remote rendering. With X11, remoting is actually very different than what Wayland requires. With Wayland, the networked proxy would only be sending finished frames across the network, while with X11, the drawing commands are sent across the network. The X11 way kinda sorta works better in environments with very low bandwidth and very low latency, but those networks don't really exist in this day and age; just about everything is decently high bandwidth, and the networks that have bandwidth constraints also have latency problems. The other advantage to the X11 model is that thin client setups allow distributing the actual graphics rendering work out to the actual clients while the Wayland model would require the application server to do all rendering (potentially requiring more expensive application servers, albeit allowing even cheaper and "thinner" clients). I have yet to see anybody actually bitch about this, though; instead we just see "I can't SSH into a box and run an app!" which is a very different use case than thin clients, and for which the Wayland approach will work better anyway.

                  As a final note, a lot of people complain when they hear "VNC-like" by assuming that means remoting an entire desktop rather than individual windows. All VNC-like means is that the network support is effected by frame transmission rather than drawing command transmission. Pretty much everybody agrees that a seamless per-window approach is a better user experience.

                  ... maybe "goal" was the wrong word, but in practice that is often what we get. We can look to our "Experienced GNOME developers" for evidence of that.
                  What in $DEITY's name makes you think GNOME is in any way, shape, or form following in Windows' footsteps? Half the reason why everyone is bitching about GNOME lately is that they've gone so far off into "WTF, this is nothing like anything else land" that its' barely recognizable as a desktop at all, much less a Windows-like one. One could only _wish_ that GNOME (and the other desktops) tried to look and act more like Win7; then the Linux desktops might not feel quite so unpolished, buggy, and inefficient as it is.

                  Comment


                  • #24
                    one is for sure I LOVE WAYLAND!!! *Happy*

                    and its also perfect for mobile devices

                    i hope andorid switch to wayland to.

                    Comment


                    • #25
                      Originally posted by Qaridarium View Post
                      one is for sure I LOVE WAYLAND!!! *Happy*

                      and its also perfect for mobile devices

                      i hope andorid switch to wayland to.

                      i am not sure about android but i thiiiiink i saw some chrome OS related stuff round the web

                      tizen most likely will use it (at least thats what i expect)

                      Comment


                      • #26
                        Originally posted by elanthis View Post
                        Because there doesn't need to be any. You're either missing some bit of information here, have a grotesque misunderstanding of some of the Wayland fundamentals, or are just being obtuse. :/

                        Let's ignore the network for a moment and just try to understand how Wayland works. That'll make the network bit much easier to understand.

                        The Wayland protocol lets clients connect to what is essentially just a compositor and input manager. All rendering happens on the client application. The client application posts updated frame buffers to the compositor. Wayland composites all the clients onto the "display." Wayland delivers input signals to the clients. A few other bits are also done, but that's pretty much the gist of it.

                        The cool bit of Wayland is that the "display" and input event sources do not at all need to actually be a physical display or OS input devices. They can easily be an X11 window. They can be a hidden surface inside a GUI app test harness that sends scripted input to the apps and records and diffs output frames. They can an offscreen buffer used for compositing over X11, which is what KWin is working on doing (so your Wayland native apps run over X11) and what Weston can already do. They can be just about anything you want, because all the protocol does is coordinate framebuffer updates and handle input events and the like. None of these new applications or special configuration require any kind of new protocol changes. The protocol already works for all of these cases, and more.

                        This is where networking comes in and becomes so easy. There is no need for Wayland support for networking because Wayland already does everything you'd need to support networking. Since the Wayland server/compositor can easily be any random app (which doesn't even need to have a graphical display of any kind) it's _already supported_ to just drop in any possible networked proxy or remote display system you want. Want VNC? Just write a VNC client that's a Wayland server. Want SPICE? SPICE client that's a Wayland server. Want HTML5? HTTP server with streaming WebM and WebSockets that's a Wayland server. Want something specifically optimized for per-window low-latency low-bandwidth WiFi/Internet remoting of desktop applications? Figure out that new protocol, write a client/server for it, and make the client a Wayland server. _None of these_ will require a protocol change or changes to any Wayland-based applications.

                        No changes to Wayland itself are needed, period. That's why the Wayland folks are saying they'll worry about it later: because they _can_, because the protocol was designed to be separate from the networking half. It does not need -- nor is there any reason to even want -- the networking aspect to be built into the Wayland protocol itself. The network proxy stuff hasn't appeared yet because nobody who actually does anything but whine has bothered to write one. It's not because Wayland needs some future extension or changes that are being ignored.

                        There is something lost by this approach which X11 offers. That is remote rendering. With X11, remoting is actually very different than what Wayland requires. With Wayland, the networked proxy would only be sending finished frames across the network, while with X11, the drawing commands are sent across the network. The X11 way kinda sorta works better in environments with very low bandwidth and very low latency, but those networks don't really exist in this day and age; just about everything is decently high bandwidth, and the networks that have bandwidth constraints also have latency problems. The other advantage to the X11 model is that thin client setups allow distributing the actual graphics rendering work out to the actual clients while the Wayland model would require the application server to do all rendering (potentially requiring more expensive application servers, albeit allowing even cheaper and "thinner" clients). I have yet to see anybody actually bitch about this, though; instead we just see "I can't SSH into a box and run an app!" which is a very different use case than thin clients, and for which the Wayland approach will work better anyway.

                        As a final note, a lot of people complain when they hear "VNC-like" by assuming that means remoting an entire desktop rather than individual windows. All VNC-like means is that the network support is effected by frame transmission rather than drawing command transmission. Pretty much everybody agrees that a seamless per-window approach is a better user experience.



                        What in $DEITY's name makes you think GNOME is in any way, shape, or form following in Windows' footsteps? Half the reason why everyone is bitching about GNOME lately is that they've gone so far off into "WTF, this is nothing like anything else land" that its' barely recognizable as a desktop at all, much less a Windows-like one. One could only _wish_ that GNOME (and the other desktops) tried to look and act more like Win7; then the Linux desktops might not feel quite so unpolished, buggy, and inefficient as it is.
                        ...BLAH BLAH BLAH...

                        X devs are idiots/X FOREVER!!!

                        Hmm, I'm sure there's a problem hidden in there somewhere

                        Nicely said, elanthis...well, mostly. I'm not sure I agree with you sentiments towards the end.

                        Comment


                        • #27
                          Originally posted by elanthis View Post
                          The Wayland protocol lets clients connect to what is essentially just a compositor and input manager. All rendering happens on the client application. The client application posts updated frame buffers to the compositor. Wayland composites all the clients onto the "display." Wayland delivers input signals to the clients. A few other bits are also done, but that's pretty much the gist of it.

                          The cool bit of Wayland is that the "display" and input event sources do not at all need to actually be a physical display or OS input devices. They can easily be an X11 window. They can be a hidden surface inside a GUI app test harness that sends scripted input to the apps and records and diffs output frames. They can an offscreen buffer used for compositing over X11, which is what KWin is working on doing (so your Wayland native apps run over X11) and what Weston can already do. They can be just about anything you want, because all the protocol does is coordinate framebuffer updates and handle input events and the like. None of these new applications or special configuration require any kind of new protocol changes. The protocol already works for all of these cases, and more.
                          Thank you for explaining this once and for all.

                          Now I'm even more excited about wayland's possibilities: You could have your app render on the server, push the result through some standard video compression (vorbis, webm, or h264, choose your poison), and stream it to your mobile phone (or browser). On the phone, you intercept pinches and zooms pokes and input and send the input back to the server. Light weight remote apps from anywhere .

                          Due to the video compression, you'd get relatively low bandwidth usage, and easy decompression and render on the client side.


                          What in $DEITY's name makes you think GNOME is in any way, shape, or form following in Windows' footsteps? Half the reason why everyone is bitching about GNOME lately is that they've gone so far off into "WTF, this is nothing like anything else land" that its' barely recognizable as a desktop at all, much less a Windows-like one. One could only _wish_ that GNOME (and the other desktops) tried to look and act more like Win7; then the Linux desktops might not feel quite so unpolished, buggy, and inefficient as it is.
                          Actually, if people weren't moaning about being outworldish, they'd be moaning about free software copying Windows or OSX and never innovating. Haters gotta hate you know.

                          Comment


                          • #28
                            Originally posted by AnonymousCoward View Post
                            I wan't to see a webbrowser running on wayland. And what about Adobe Flash, will this ever run on wayland? AFAIK it has got some hard dependencies on X. And as much as I hate the thing, I really need the plugin for some websites.
                            Intel employee already worked port of Chromium to Wayland. look into this Chromium dev thread:http://groups.google.com/a/chromium....8a0493522fb74d

                            Comment


                            • #29
                              I also find that the Linux kernel has a lot of cool features that can make applications faster, safer and simpler, and we often don't use those in the name of portability. There is an accept4 syscall that lets you accept a connection on a socket and sets O_CLOEXEC atomically. The epoll mechanism with timerfd and signalfd does most of what many complex userspace event loops do in many thousands of lines of code. We need to embrace all the new features the kernel offers and not insist on some outdated lowest common denominator.
                              Make the Linux OS, please and don't care about ancient crap that always slowed you down. Linux+wayland+systemd is the future.

                              Comment


                              • #30
                                Originally posted by kraftman View Post
                                Make the Linux OS, please and don't care about ancient crap that always slowed you down. Linux+wayland+systemd is the future.
                                Totally agree.

                                To all of the network-transpara-tards: Network transparency in X was somebody's great idea before people had properly figured out the right way to do that kind of thing: web applications, and/or VNC. You might as well get on board with doing things the way they should be done, or commit yourself to using old computers, old operating systems, and old applications. Have fun with that.

                                Comment

                                Working...
                                X