Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Graphics Open Source Software Linux

Wayland 1.7.0 Marks an Important Release 189

jones_supa writes: The 1.7.0 release of Wayland is now available for download. The project thanks all who have contributed, and especially the desktop environments and client applications that now converse using Wayland. In an official announcement from Bryce Harrington of Samsung, he says the Wayland protocol may be considered 'done' but that doesn't mean there's not work to be done. A bigger importance is now given to testing, documentation, and bugfixing. As Wayland is maturing, we are also getting closer to the point where the big Linux distros will eventually start integrating it to their operating system.
This discussion has been archived. No new comments can be posted.

Wayland 1.7.0 Marks an Important Release

Comments Filter:
  • by Anonymous Coward

    I keep hearing about Wayland release this, and Wayland release that. That's all great - keep releasing new versions, that's progress. But I want to know, when can I install a GNU/Linux distro and start using Wayland. I know, it's next year, but we'll said that for a couple of years now and I'm running out of patience.

    • by afgam28 ( 48611 ) on Saturday February 14, 2015 @02:02PM (#49055527)

      You can use Wayland in Fedora today: http://fedoramagazine.org/gnom... [fedoramagazine.org]

  • by buchner.johannes ( 1139593 ) on Saturday February 14, 2015 @02:00PM (#49055505) Homepage Journal

    Second is the protocol
    documentation, which is mechanically generated from the protocol
    definitions and works more like a reference manual. Third is the code
    documentation, which is also mechanically generated but from the library
    source code itself.

    That's the right way to do it. They use pelican, xmlto with some customized XSLT and graphviz for maintainable high-level diagrams.

    Pretty cool. So far I have only used sphinx (and doxygen before), but these days there are a lot of great documentation options out there.

  • by caseih ( 160668 ) on Saturday February 14, 2015 @02:23PM (#49055659)

    After it was announced a year or two ago, I have heard nothing about RDP support in Wayland. Is it getting to the point that Wayland will have first-class support for transparently remoting apps with RDP? Anyone know the status on this? There's precious little info about this on the interwebs, and no real information on what the workflow looks like, say with ssh forwarding.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Remoting should be done at the toolkit level. This is where it belong. Similarly to sftp, gtkclient->ssh->intertubes->ssh->gtkapp

      in practice you would call "gtkclient user@host:/path/to/gtk/application" which would connect the ssh pipes, set envar GTK_BACKEND to "pipe" and run the app. Gtk api get serialized both way, piped through ssh and run locally on your gtkclient which use what ever display backend your desktop is set to. This way you get the absolute minimal network traffics with zero lag

      • by jedidiah ( 1196 )

        That's just priceless. We've gone from completely ignoring the fact that RDP has taken the world by storm in the last 20 years to really stupid alternate approaches.

        You could't create more Unix fragmentation if that's what you were actually trying for.

        • by Mathieu Lu ( 69 )

          We've moved from displaying remote applications from the xlib level over ssh, to the toolkit level over ssh (as parent described). It's Unix moving forward, finally.

          Microsoft's proprietary RDP protocol or alternatives such as VNC work differently (and usually pretty slow, since they work similarly to xlib, passing compressed bitmap images over the wire). If you want a remote desktop and your network link is fast enough, that's fine, but for most cases, toolkit-over-ssh is more secure and efficient.

          • by Anonymous Coward

            Microsoft's proprietary RDP protocol or alternatives such as VNC work differently (and usually pretty slow, since they work similarly to xlib, passing compressed bitmap images over the wire).

            What you say only applies to VNC. RDP only passes bitmaps when it needs to draw bitmaps. The protocol sends rendering primitives to a thin client, much like X. It can even send fonts or a video/audio stream to let the client do the rendering or decoding.

            See http://en.wikipedia.org/wiki/R... [wikipedia.org]

        • by sjames ( 1099 )

          In practice, RDP can be a security risk. It can be mitigated, but hasn't been in practice.

          • by adolf ( 21054 )

            In practice, RDP can be a security risk. It can be mitigated, but hasn't been in practice.

            Is this security risk any different than any other method which allows relatively-insecure* remote logins to a general-purpose computer?

            For a long time, I had the default RDP port forwarded to my Windows 7 desktop computer at home -- open for all manner of fuckery -- out of sheer laziness on my part. Nothing bad happened, even though it was simply a username/password combo (and both the username and the password were

            • by sjames ( 1099 )

              Yes, it presents hazards never even dreamed of by X or VNC.

              In one case I know of (no, I am bound to not name names here), RDP was a vector for a CryptoLocker attack. A reasonably secure operation (AV on email, IDS, strong user training, etc) granted an outside support person a temporary RDP connection to diagnose a problem. It seems the support person opened a bad email on his own machine while connected and CryptoLocker took advantage of the RDP forwarded file shares to encrypt the fileserver.

              OOOPS

              • Yes, it presents hazards never even dreamed of by X or VNC.

                X has always been a breathtaking hazard for reasons entirely the fault of X.

                In one case I know of (no, I am bound to not name names here), RDP was a vector for a CryptoLocker attack. A reasonably secure operation (AV on email, IDS, strong user training, etc) granted an outside support person a

                AV and IDS are worthless against targeted attacks.

                temporary RDP connection to diagnose a problem. It seems the support person opened a bad email on his own machine while connected and CryptoLocker took advantage of the RDP forwarded file shares to encrypt the fileserver.

                You can do the same with SSH.

                • by sjames ( 1099 )

                  Did you invent RDP or something? You'll break your back bending that far backwards to absolve it of the incident I wrote about.

                  The attack wasn't targeted, it was a shotgun style spam opened at a bad moment.

                  You CAN do that with ssh but it's far from the default setting.

                  • Did you invent RDP or something? You'll break your back bending that far backwards to absolve it of the incident I wrote about.

                    I fail to understand how the repercussions of social engineering attacks are the fault of a remote access technology unrelated to initial compromise.

                    Especially given root cause from your story seems to be acceptance followed by execution of unauthenticated, untrusted messages.

                    You CAN do that with ssh but it's far from the default setting.

                    Name a popular Linux distro which fails to enable ssh, port redirect and scp by default. I dare you to name one.

                    suse, debian, ubuntu, fedora, centos all DEFAULT setting. Every unix system I've ever used or connected to in the past de

                    • by sjames ( 1099 )

                      Wow, you are desperately working to miss it!

                      The file sharing that allowed the nasty on the remote terminal to get at the fileserver was not required and was not part of the reason for allowing that RDP connection. But it was there because RDP in the wild overshares by default.

                      SSH and X don't tend to overshare by default. You can do port redirection, but only by explicitly asking for it.

                    • Wow, you are desperately working to miss it!

                      Right back at ya.

                      The file sharing that allowed the nasty on the remote terminal to get at the fileserver was not required and was not part of the reason for allowing that RDP connection. But it was there because RDP in the wild overshares by default.

                      SSH and X don't tend to overshare by default. You can do port redirection, but only by explicitly asking for it.

                      Can you explain the difference between a share allowed with an RDP connection and the use of SCP over SSH which is enabled and allowed by default?

                      If you own the client and the client logs on to something it would seem to me this is game over you must assume everything the client has access was compromised unless you have reason to believe otherwise... as we already know SSH provides file system access by default to all clients. I'm failing to comprehend the difference.

                    • by sjames ( 1099 )

                      SCP moves one file. SSH doesn't move any. RDP makes every file the target has access to directly accessible as a file share on the client even if you don't want it to.

                      CryptoLocker running on the client wouldn't have seen the files the target could access at all had the connection been VNC, X, or ssh.

                    • SCP moves one file. SSH doesn't move any. RDP makes every file the target has access to directly accessible as a file share on the client even if you don't want it to.

                      CryptoLocker running on the client wouldn't have seen the files the target could access at all had the connection been VNC, X, or ssh.

                      So this is just a security by obscurity play. The assertion is since a particular instance of malware lacks a feature set enabling it to detect and subvert SSH connections from a compromised client then SSH is more secure than RDP even though both offer functionally equivalent access.

                      Sounds like all the wrong lessons have been learned from this security breach.

                      Also worth noting RDP maps the clients local resources to remote server not the other way around.

      • by caseih ( 160668 )

        Ahh interesting. Makes sense, but I disagree about that being the right way to do it. The way you describe is hackish, having to run a client. We need the ability to simply remote log into a machine and run the binary and have it work. This is disappointing, if this is indeed the way they've chosen to go. Shouldn't matter what widget set an app uses; it should work (by some definition of the word "work") whether locally, or on a remote machine.

      • Re: (Score:3, Interesting)

        by PPH ( 736903 )

        gtkclient->ssh->intertubes->ssh->gtkapp

        Which means that I have to install/maintain a gtkapp on ever desktop that needs to access gtkclient. No thanks. In a corporate environment, that could be thousands of desktops.

        This is the sort of architecture that only Microsoft could love, with per-seat licenses for each user.

        With X, it is: Xclient->network->Xserver

        And Xserver is available on numerous OSs, so there's no desktop lockin.

    • Compared to X11, RDP isn't good for seamless graphical element integration into the local environment (though integration of audio makes it better on another front, and performance wise RDP runs circles around X11).

      All that said, I'm not one to be down on Wayland. Xpra demonstrates how a linux graphical environment is best remoted, and it doesn't really use the X protocol at all for the business end of things. It interjects as a compositor and window manager, with a dummy X server to satisfy the demands of

      • I actually disagree with this, well if I interpreted it correctly.

        If you're saying that exporting an entire desktop isn't as good as exporting a single app then I agree with you. But the single app thing is actually supported by RDP.
        If you're saying that the app should seamlessly integrate into the user environment completely taking on the target environment's look and feel, then I disagree. I greatly prefer to know which if of my programs are part of the local environment and which are part of a remote ses

        • by dbIII ( 701233 )

          But the single app thing is actually supported by RDP.

          People here keep saying that but none, possibly until now, of those have actually done it. How for instance can I launch an application window on a Win7 box with RDP fully licenced for one user onto the Win7 box next to it instead of an entire desktop? Let's assume I don't care what happens on the screen of the box that actually has the application to make things easier. Any ideas?
          Trivial in X in 1995 but this feature in RDP doesn't seem to be putting

          • Well you need a service that implements that part of the RDP spec of course. Windows 7 doesn't. Windows Terminal Services on servers have always had that capability when using Windows clients, though it seems to require a bit of hoohaaa to setup.

            Windows server 2008 onwards supports RemoteApp which is apparently an easy implementation of the same thing though I've never seen it in practice.

            A quick google search also shows a product called SeamlessRDP which seems to be compatible with Windows RDP clients, tho

            • by dbIII ( 701233 )
              Thanks - all I've got till now is "but RDP does single apps so X is obsolete" and then silence when I ask for an example.
              I'll take a look at SeamlessRDP - which may scratch the itch of a couple of users wanting an old version of AutoCAD LT that runs under Wine but not under any 64 bit MS Windows. Yes there's Virtualbox, VNC etc but they want their single window. Yes there's X on MS Windows but the menus misbehave.
              I looked at MS Server 2008 but then I found that the 200 page windows licencing for dummies
    • by Anonymous Coward

      Biggest issue here: Wayland -itself- has _NO_ support for network/RDP. Its merely a protocol between applications.

      And there is the issue: GNOME/KDE (cant say for Enlightenment) are basically repurposing their X11 stuff. As you know the Xserver was network transparent, so neither GNOME/KDE has any capabilities to piggyback on. So I assume the answer here is "no time soon".

      As for Weston, I have not tested it, but Weston does include RDP support from what I can tell.

      • by Junta ( 36770 )

        As you know the Xserver was network transparent, so neither GNOME/KDE has any capabilities to piggyback on

        Which really is still not a big deal, because...

        As for Weston, I have not tested it, but Weston does include RDP support from what I can tell.

        The best seamless remoting implementation for X11 is no longer actually using the X protocol. Xpra does remote X applications using compositing and window management hooks rather than anything involved in the X11 protocol interaction.

        Of course it's entirely plausible that specific scenarios could be better done in the toolkit, but I think the scenarios are frankly limited compared to the complexity of making it happen. At the same time real time encode of gr

    • by Bengie ( 1121981 )
      Wayland is how you display images, what happens on the backend is entirely the responsibility of something else. RDP is simple as making a "producer" that interfaces with Wayland.
    • After it was announced a year or two ago.

      It wasn't "announced" as such. Wayland developers have always said that on the protocol level Wayland does not support remote applications. They cited many reasons why adding this support to the Wayland protocol itself would be bad and defeat the purpose of Wayland which was to reduce the complexity of that part of the graphic subsystem, and why remote support was one of the single biggest bottlenecks of X11.

      They then proceeded to say that there is nothing in Wayland preventing someone from adding remote su

      • Correct, but just to make things clear, there is an RDP backend in Wayland. There is a Slashdot announcement from 2013 [slashdot.org].

        However it's been a bit of a mystery to people if that code actually is in usable state and how it is operated.

        • There was an RDP backend on top of Weston. There's a big difference. Wayland as a protocol does not have any concept of network rendering. They said it themselves on their docs, any remoting abilities need to be written as a separate piece such as a server sitting on top of the compositor, or handled entirely on the client side.

          They demonstrated the former using Weston, but it has nothing to do with the Wayland protocol.

  • Anyway to try it on hardware without using vm?

  • by syzler ( 748241 ) <david@syzde[ ]et ['k.n' in gap]> on Saturday February 14, 2015 @03:36PM (#49056077)

    <rant>

    For those of us who have not heard of Wayland, the following is how the summary reads:

    The x.y.z release of Some Software is now available for download. The project thanks all who have contributed, and especially the desktop environments and client applications that now converse using Some Software. In an official announcement from Some Author of Some Company, he says the Some Software protocol may be considered 'done' but that doesn't mean there's not work to be done. A bigger importance is now given to testing, documentation, and bugfixing. As Some Software is maturing, we are also getting closer to the point where the big Linux distros will eventually start integrating it to their operating system.

    So what does Some Software actually do and why should I be interested? I know that I can Google Some Software, but is it really that hard to start with the summary with the following:

    The x.y.z release of Somesoftware, a package which does blah blah blah, is now available for download. ...

    After all, phrases such as "As Wayland is maturing", imply that this is a relatively new piece of software still under development of which everyone is not familiar, especially for those of us using BSDs, Solaris, and Slackware.

    </rant>

    • Re: (Score:2, Informative)

      by syzler ( 748241 )
      BTW, for those not familiar and who have not yet googled it, according to Wikipedia, Wayland [wikipedia.org] aims to be a replacement for the X Window System.
      • aims to be a replacement for the X Window System

        Only the bits of X they consider important.
        It was planned as more an alternative MS style window system for *nix boxes than a "replacement" for X, but has adopted more X style features (eg. choice of window management instead of one style fits all) as the project has progressed.

        It's the differences that have people arguing and putting people down for wanting to run applications from 2013, 2005 or (shock horror!) commercial *nix software that still has bits fr

        • There is an X server you can run as a wayland client. Though popup menu's may be broken due to issues with how each application / framework calculates screen offsets, everything else works fine.
          • by hitmark ( 640295 )

            Best i can tell, you can use Wayland as a display driver for Xorg (THE X server right now, iirc).

            Frankly that is the way i see myself using Wayland, as basically a way to render the whole X session using OGL. This instead of using X as a "minimal" container for a OGL "window".

    • Re: (Score:2, Offtopic)

      by thegarbz ( 1787294 )

      Welcome back. I noticed you have a relatively low UID and are one of the long history of slashdot users to return from your 10 year walk in the jungle. Much has changed on Slashdot and unfortunately it's not the same as it used to be. Here's a summary list of changes:

      - Slashdot is now Dice's personal blog. We do videos and they ignore all complaints which happen weekly.
      - Slashdot attempted to roll out Beta which was hated universally by all and spawned a couple of Slashdot forks.
      - Bitcoin (a virtual currenc

  • by radarskiy ( 2874255 ) on Saturday February 14, 2015 @06:32PM (#49056953)

    So a) they got to v1.7.0 of an implementation before they finished the initial protocol they were implementing, and b) they are NOW increasing their work on documentation and testing.

    This is why actual engineers, including software engineers, either laugh or cry over these programmers who think they should be treated with respect.

  • I hit /. daily, fark daily, run Linux daily. I've heard of Wayland, but have no idea what it is. So, um, WTF is Wayland and why should I care? Summary, help me out?
    • by hitmark ( 640295 )

      low level GUI plumbing. It is X without the networking stuff, and assumes you have a GPU to play around with.

    • by rdnetto ( 955205 )

      Wayland is a replacement for the X window server. (X is the software the sits between your graphics drivers and your desktop environment.) X is ancient at this point and has fundamental issues with its design that mean security issues which can't be fixed without breaking backward compatibility. X has a lot of features that it is required to support to maintain backward compatibility that no one uses any more - modern systems work by just pushing blocks of pixels to it. Wayland only supports this method of

  • by TechyImmigrant ( 175943 ) on Sunday February 15, 2015 @02:20AM (#49058581) Homepage Journal

    From TFA:
    >Wayland's developer documentation is comprised of three different pieces.

    Where's that guy from Wikipedia to fix their grammar?

  • by walterbyrd ( 182728 ) on Sunday February 15, 2015 @03:08PM (#49061111)

    If so, why?

"Ninety percent of baseball is half mental." -- Yogi Berra

Working...