Remote Desktop Backend Merged into Wayland 215
New submitter Skrapion writes "One month ago, an independent developer submitted patches to the Wayland's Weston compositor which adds support for FreeRDP, an open-source remote desktop protocol. Now, after six revisions, the remote desktop code has been merged into the trunk. While remote desktop has been prototyped in Weston once before by Wayland developer Kristian Høgsberg, this is the first time Wayland/Weston has officially supported the feature. For a summary of why we can expect Wayland's remote desktop to surpass X.Org's network transparency, see Daniel Stone's excellent talk from Linux.conf.au."
Nothing Compares To X11 Transparency! (Score:5, Insightful)
For the past 10 years I have been repeatedly lambasted for complaining that RDP and ICA were superior to X11 transparency and VNC with seemingly nothing being done to address the issue. Naturally, this made me a clueless troll. Blah, blah blah.
Now, with RDP copied and inserted into Wayland "we can expect Wayland's remote desktop to surpass X.Org's network transparency".
Fan boys are pathetic. LOL. I for one, welcome any improvement over X11 transparency and VNC. Anything at all.
Re:Nothing Compares To X11 Transparency! (Score:5, Insightful)
Even better... watch the full video and you'll note that any version of X that isn't in a museum does not actually implement network transparency anymore (instead it's more of a network fallback to a less-capable graphics display).
Re:That You, Fanboy? (Score:5, Interesting)
You're misinterpreting... I was agreeing with you about X fanboys who always cry about "network transparency" when X hasn't been network transparent for years & years. Any modern X server is just shooting bitmaps over a network link in a less efficient manner than RDP.
Re:That You, Fanboy? (Score:4, Informative)
I think what the poster was referring to is that client-side rendering is now the norm. This has brought us nice fonts and compositing, among other things. So yes, most X11 apps are just sending bitmaps to the server. No longer are modern X-based applications asking the server to render text and buttons and shapes for it. Yes this does decrease remote performance. And modern toolkits like GTK do require a lot of server round trips, which makes things hard to deal with over a high-latency link.
I remember running Xemacs over a modem and it ran great remotely, since it was mostly just asking the server to draw in its behalf. Worked very well, but compared to modern apps, was very ugly.
Re: (Score:2)
I think what the poster was referring to is that client-side rendering is now the norm.
Partly. Fonts are rendered client side, but can be composited server side just fine. Since X can cache bitmaps, a well written client will send the glyphs to the server as bitmaps, then send a list of bitmap IDs to composite. After the initial data dump it can go very fast.
And modern toolkits like GTK do require a lot of server round trips, which makes things hard to deal with over a high-latency link.
Frequently things l
Re: (Score:2)
Exactly - xedit, xclac, xvim, all work great over the slowest link you will find in use anywhere. The trouble is the world has moved on. I am not sure sending bit-maps ( regardless of how clever your scheme of sending just the changed parts, compress etc is ), is the right way to go but the fact is the X11 programs most people are using most of the time these days don't get the benefits of X11 server side rendering features.
Sending bit-maps be it X11 doing it, RDP, or VNC is certainly the simplest thing to
Re: (Score:3)
So what you're saying is that X11 isn't network transparent, at least from the perspective of developers. And the example of inefficiency that you provided (drawing bitmaps) is something that all modern GUIs do extensively today. Your defense of X11 seems to be out of touch with the reality of modern GUI development. This is precisely why the people that actual
Re: (Score:3)
Re: (Score:3)
So if you want your app to be reasonably usable over connections slower than LANs, you need to design your app in a very specific manner. That doesn't sound unreasonable, but it also doesn't sound transparent, which was my original point.
Re: (Score:3)
Re: (Score:3, Insightful)
1. As I told another poster, Network Forwarding != Network Transparency. You know how modern X servers operate over a network? By pushing a bunch of bitmaps in a less-efficient manner than RDP. I really don't care if some dusty design document from 1985 says otherwise, you're irrational wishes don't create a new reality. Unless you are a real fossil, I was probably doing X forwarding before you even new what Linux was, and I know much much more about its limitations than you do.
2. If you're calling me a li
Re: (Score:2, Troll)
As I told another poster, Network Forwarding != Network Transparency.
OK, you're not a liar, you're just redefining commonly understood terms to confuse people. Fair play.
ou know how modern X servers operate over a network? By pushing a bunch of bitmaps
First yo umean xclients. And no, the cliend can still upload nice glyph bitmaps and then composite them using the bitmap IDs instead of using the old font mechanism, meaning the expensive bitmaps are sent once, not once per use.
Unless you are a real fossil,
Re: (Score:2)
An important feature for me (Score:5, Insightful)
Re:An important feature for me (Score:5, Insightful)
The way X11 does forwarding is very handy and useful, and I make use of it fairly often. But as usual, there's more than one proverbial way to skin the proverbial cat.
X11 forwarding is great for high speed and low latency connections such as a lan. Using it on anything else is asking for trouble, because if you lose your connection, you lose your app. Perhaps an improvement can be made to X11 forwarding in the new path forward (wayland) to make it more like screen where you can attach and detach to a running X11 app from a networked endpoint.
Remote desktop using RDP is superior to X11 forwarding for lossy connections because once the screen is loaded, very minimal draw/drag/etc communications are sent between the server and client for updates, X11 is far more data intensive for screen updates. And of course if you lose your connection (which I frequently do, trying to RDP from my cell phone), you'll get your apps back when you reconnect.
Having both X11 forwarding and RDP is a great choice, and I hope something similar to my aforementioned improvement makes it into the app.
Re: (Score:2)
The nice thing about the Wayland stack is that it's much easier to replace parts of the stack with something else. I'm sure this won't be the last remoting protocol we see layered on top of Wayland.
Re: (Score:2)
Great, just what we need, multiple incompatible remote rendering back ends.
Re: (Score:2)
You already have multiple incompatible remote rendering back ends in X, it's just really hard to do in X. The reason the Unix mantra "do one thing well" is so important is because it allows you to swap out parts and innovate more easily.
Re: (Score:2)
As long as I'm guaranteed that my local display can talk to remote applications, no matter what the flavor of the month is, I'll be happy. There needs to be a universal standard.
Re: (Score:2)
There needs to be a universal standard.
This just cries out for the obligatory xkcd [xkcd.com].
Re: (Score:2)
We already have some brain-addled dev someplace trying to come up with the display equivalent of Pulse Audio.
We're all talking about it right now: It's called Wayland.
+...or did I miss your sarc tag?
Re: (Score:2)
Re:An important feature for me (Score:5, Informative)
I used NX for X11 over VPN. It works very well and I am able to resume where I left off if my VPN connection drops or I want to let something run overnight but don't want to remain online. NoMachine closed source their server at version 4.0, but FreeNX and Neatx took its place.
Re: (Score:3)
X2Go is also very good.
Re: (Score:2)
The problem you are describing doesn't exist.
Re:An important feature for me (Score:5, Interesting)
The problem is that the current implementation is effectively VNC done using the RDP protocol. That is it is just sending the changed areas of the screen. What is needed is something more like x11rdp. That is an X11 server that rather than talking to hardware spits out RDP protocol instead. Draw a rectangle on the X11 screen and the corresponding RDP gets spat down the line to the client. It is much much faster than VNC which is a total dog over slow links, rather like X11 being a total dog on links that don't have really low latency.
Re: (Score:2)
The problem is that the current implementation is effectively VNC done using the RDP protocol.
heh yes. At some point they'll realise that it's a good idea to have display related settings tied to a physical screen, not a local filesystem and reimplement xrdb too.
For those About to Whine! (Score:4, Insightful)
We don't Salute You!
For the next 100 posts whining about how this isn't exactly like forwarding an Xterm over an SSH tunnel (think about how stupid that is for a second)... X IS NOT NETWORK TRANSPARENT
What? That a lie! 1985 sez X is network transparent!
Well guess what: Modern versions of X are *not* network transparent anymore because to use any of the modern features of X that make using a modern Linux desktop even remotely enjoyable, you are breaking the classic backwards server-client paradigm of X. Sure, there's still a fallback mode for transferring data over networks, but lots and lots of modern features that you expect in a modern desktop GUI break in the process, which is *not* transparency, but is instead more of a network fallback.
Frankly, having tried to use both X and RDP over real connections using the real Internet, I'd take RDP any day of the week. I still remember the finger-pointing amongst developers of different projects when I pointed out that packets were being sent over the network each and every time my cursor blinked. Get over it guys, 1985 wasn't the be-all end-all pinnacle of graphics development.
Still don't believe me? How about clicking the link to Dan's talk about X where he says the exact same thing I just said. He's only been working on X development for over 10 years though, so I'm sure that some guy who sorta got X forwarding working over a gigabit link is much much more informed that he is....
Re:For those About to Whine! (Score:5, Insightful)
That's just pedantry.
In terms of "network transparent", what is meant is that a program doesn't care (it just communicates with whatever DISPLAY is set to) and the end user doesn't care. What the server does behind the scenes is irrelevant to how it's used.
If on Wayland, while you're in an SSH session to a remote machine you think..."hmm, I could really do with a couple of wterms" (or whatever the Wayland xterm equivalent is), or "I could really do with firing up wireshark", you can't just type "xterm" and be done then it's not network transparent to the user. If you then have to set up another session and do some desktop-style login (and the remote server has to be running some sort of GUI login manager or equivalent to handle it) then it's a lot less useful than what you get with X11 at the moment.
If on the other hand Wayland will allow the equivalent of ssh -X, then it doesn't matter how it's implemented, so long as the program running at the other end runs and doesn't care that the display is remote, and the user sees a window on their screen, then they have the functional equivalent however it's implemented.
Re: (Score:3)
No. You are an idiot. 127.0.0.1 is a network address. When you are using 127.0.0.1 as your display, all your X11 traffic is operating over the network. You are using network transparency.
The lack of network transparency is when you use things like SHM, or DRM, things that need direct access to hardware, and cannot operate over the network.
Re: (Score:2)
I found it hard to take much of your argument seriously when you wrote the above. "Client-server" does not mean "PC client running Windows-Windows server. The Wintel crowd pretty much co-opted the term "client-server" and when they encounter a case where "server" doesn't mean a Windows server, they go nuts.
Re: (Score:2)
Your sig says: Censorship is obscene.
Well it looks like you self-censored my post by not bothering to read past the first couple of lines and also censored an X developer who agrees with me and not you. So, aside from admitting that you are obscene, please list your evidence and credentials for why you are right and a guy who has been deeply involved in developing X for over 10 years is stupid....
Re: (Score:3, Informative)
The very fact that FreeNX exists is absolute proof that X has fundamental issues and you have admitted that those issues exist and that another layer of complexity needs to be added around X is a direct admission that X isn't cutting it!
You also lied in your original post when you said you forward over X and therefore X is transparent.
1. No you don't forward over X, you use a much more convoluted FreeNX setup.
2. Forwarding != Transparency. If you think it does, then FreeRDP is also network transparent! Mode
Re: (Score:2)
NX is just a proxy. I use X forwarding in conjuction with NX, it follows that I use X forwarding. There is nothing disingenuous about that. You might as well complain that I'm not using HTTP because I have a caching proxy.
I do agree that X forwarding is not perfect as it is, but it can be fixed by building NX into X, or into SSH, instead of throwing away the entire display system.
Re: (Score:2)
"Network transparent" means you can look at the bits over the wire and tell what it's doing. You can't do this with X nowadays, because nowadays it sends whole frame buffers instead of individual drawing commands. It's network opaque. Yes, X supports remoting, but it's not network transparent anymore.
Re: (Score:3)
Network transparent means that the application performs the same whether it's local or remote. It's transparent to the user, not transparent to a network sniffer.
Re:For those About to Whine! (Score:5, Insightful)
The Wayland devs were definitely a little too obscure whenever the issue of remoting came up. They kept saying that remoting was out of scope with regard to Wayland, and technically, they were right, but it lead to a lot of misunderstandings.
Imagine if somebody asked "Does the Linux kernel support email?" Of course it doesn't; email is done way higher in the stack. There's not a single line of code in the Linux kernel that has anything to do with email. But you would be giving people the wrong impression if you said "Linux doesn't support email", and that's exactly what the Wayland devs were doing.
Unanswered questions... (Score:5, Interesting)
Does this allow per-application forwarding? (All sorts of people blasting that Microsoft can do it, not many people speaking to whether *this* specific implementation can).
Does this allow remote applications to cleanly appear in things like notification areas? That was one problem I had with NX, even the rootless mode failed to properly incorporate that.
Does Wayland+FreeRDP provide a more unified approach to audio+video being grouped together? That's a large gap in X, where audio is consider just completely unrelated to the remoting...
Re: (Score:3)
I too eagerly await details.
X11 remoting is much more powerful than many people imagine. Like you say, it allows remote applications to display their icons in the local system tray. It also allows remote connections to communicate with locally-running apps. For example (and sometimes this behavior is not what I want!), running firefox on a remote machine will first check to see if there's an existing firefox instance on the X server running, and communicate with it to open the url. So on the remote machi
Re: (Score:2)
X11 remoting is much more powerful than many people imagine. Like you say, it allows remote applications to display their icons in the local system tray.
These days, most system tray icons are handled through DBUS, even under X11. Wayland probably won't bother with general client-to-client communication; instead, you'll forward your DBUS session alongside Wayland (and PulseAudio, CUPS, etc.) via a "ssh -X" equivalent which transparently handles all the details.
Re: (Score:2)
That's a large gap in X, where audio is consider just completely unrelated to the remoting...
That's a curious gap--espacially now. X11 is capable of forwarding pretty much arbitrary data. One could quite easily imagine a deamon which ships pulseaudio data over X11.
Or, alternatively, I assume that you could forward the pulseaudio port over ssh while you do X forwarding as well. I don't see why that wouldn't work. Of course you'd have to make sure that programs attempt to connect to the right pulse daemon.
Re: (Score:2)
Mod parent up (if it's true). I've not tried it, but if it's correct then that's great.
Re: (Score:2)
Best guess: X is a display protocol, not audio.
Re: (Score:2)
> I never understood why sound on Linux was kept separate from X
X is older than gaming PCs.
There are still a lot of remote desktop use cases where lack of sound support is pretty much irrelevant. Actually, I would go further and say that sound on a remote desktop is more likely than not COMPLETELY IRRELEVANT.
Most use cases that call for sound support stretch the abilities of ANY remote desktop implementation.
Re: (Score:3)
Does a GUI have to be running on the remote server?
No, the clients on the remote machine will be talking to a different Wayland server, one that only sends RDP to a remote display.
Yes there is special code running on the remote machine, but even X forwarding requires xlib and the code that translates a socket connection to actual network packets to be running on the remote machine. And modern programs require freetype and cairo and libpng and lots of other code that you think of as "GUI" running on the remo
sounds good (Score:2)
sounds like a nice improvement. as long as:
* The interface is still the same. i.e. i ssh -X in to a machine, start a graphical program (evince or whatever), and it displays locally. I dont want to have to configure stuff, or start some additional server on the remote machine.
* It works in mixed environments. I might be running wayland on my laptop next year. but some of the machines i log into a currently on Scientific Linux 5. I guess RHEL 7 will still be X11 based and i would not make bets about RHEL8.
Als
Comment removed (Score:3)
Re: (Score:2)
You realize you only mentioned VNC and services that use VNC as things you've tried, right? And VNC is very inefficient compared to just about anything (X over network, ssh -CX, RDP, NX, etc)
Re: (Score:2)
Actual Information from the FreeRDP Project (Score:5, Informative)
Re: (Score:3)
THAT IS USELESS! You didn't show forwarded Xterms using the exact same perfect protocol that was cool in 1985! Your system is obviously bloated and inefficient compared to X11 and a complete waste of time!! /sarcasm
Much more seriously, thank you very much for your hard work and for pushing forward with implementing this technology in an open & cross-platform way. The video is fantastic!
Re:And why is this better than VNC? (Score:5, Informative)
Presumably RDP can handle rootless windows. VNC does not have that option at this moment. That means that RDP will work much like xforwarding and be usable over ssh, whereas with VNC you need to start a VNC-session and click around on the desktop to start programs.
Re:And why is this better than VNC? (Score:4, Funny)
Because VNC is slow and sucks.
Re:And why is this better than VNC? (Score:5, Informative)
Re: (Score:3)
RDP on windows at least outperforms VNC by a wide margin both on fast and slow network connections.
It should -- VNC is doing screen scraping. RDP is hooked in deep into the GDI and can see the underlying API calls. (Technically speaking, VNC could do the same thing, but doesn't.) Its a lot closer to how remote X works than VNC.
Re: (Score:3)
VNC is a rather inefficient protocol. It basically works by sending periodic screenshots of the host system to the remote one, whereas RDP sends just enough information to the other end to render the screen on its own. Basically it is just a hell of a lot more efficient on bandwidth and CPU usage.
Re:Rootless? (Score:5, Informative)
You would be wrong then. RDP 6.1 along with Windows Server 2008 introduced RemoteApp which allows a single application to be forwarded rather than a whole desktop.
Re:Those who do not understand X11 (Score:5, Informative)
Nobody understands X11 then, because Wayland devs are also X11 devs. Enjoy.
Re: (Score:2, Insightful)
Nobody understands X11 then,
A true statement has just been spoken...
Re: (Score:2)
Nobody understands X11 then, because Wayland devs are also X11 devs. Enjoy.
Which makes the results more surprising. You should see some of the stuff that Keith Packard has spewed about X, especially the stuff about strings and atoms. He's basically set up very nice straw man to attack, but that is really all.
Re: (Score:3)
Re: (Score:2, Troll)
Your bad rhetoric is unconvincing. Your appeal to authority is the mark of a simpleton. Meanwhile, many of us continue to effectively use X remotely both on local networks and across the Internet.
So, that feature needs to be in any attempt to mindlessly flee from X.
It also needs to not suck (like VNC on MacOS does).
Re: (Score:3, Interesting)
wrong.
all that needs to happen is enough of us to care less about your precious remote X functionality and you'll be forced to ditch it, support it yourself or program it yourself.
so people mindlessly fleeing from X, might not even care about a feature they never used......ever
Re:Those who do not understand X11 (Score:4, Insightful)
all that needs to happen is enough of us to care less about your precious remote X functionality and you'll be forced to ditch it
Sigh. Linux used to be the world of possibilities where unusual behaviour was expected and no one in their right mind would put up barriers to their fellow hacker.
What happened?
Re: (Score:2, Funny)
Lennart Poettering
(Grin, Duck, and Run)
Re: (Score:2)
Any word on when it will be able to delete files that are open?
I suppose it already can, otherwise the SUA subsystem would be unimplementable.
Re:Rootless? (Score:5, Insightful)
Whatever it does RDP is far, far faster and more versatile than X forwarding. X forwarding is slow and buggy to the point that I use vnc on my unix servers and vnc is awful.
Re: (Score:2)
Really?
Because I use X forwarding all the damn time. Mind you only on the LAN.
Newer VNC is not too bad either, but the normal ones suck. Have you tried TigerVNC?
Re:Rootless? (Score:4, Interesting)
I've used it on LANs. I've used it across my crummy IDSL link. And I've even used it on dial-up. Only when using very graphics intensive applications on dial-up did I find the performance awful (and, fortunately, I only needed to resort to dial-up during those rare times that the VPN access was down). Caveat: I'm not trying to play games via X11 connections which may be why it works well for me and so badly for the folks who are in favor of Wayland.
I find it amusing that some people are touting how wonderful the implementation of RDP is on Windows 2008 server. I need to access remote UNIX systems, not Windows servers. Those of us that use UNIX (almost exclusively or as exclusively as I can pull off) don't want something that is useful only for Win2008 Server systems. How will an RDP plug-in for Wayland accommodate UNIX/Linux desktops connecting to UNIX/Linux servers? Oh... I guess the people running UNIX servers will have to install a non-native layer to allow the Wayland folks access. That's just nuts.
(Personal opinion time: It seems there is a group of Linux developers who grew up developing for Windows and won't be happy until they've turned Linux into the Windows they would have liked to have seen. Too bad they never used UNIX/Linux as they were developing their programming skills.)
Re: (Score:3)
Non-native?
Rdesktop is a native linux app I use for when I have to deal with windows servers. The other way around I don't see why someone running wayland could not use X over SSH like the rest of us.
I cut my teeth on Solaris and my caplock key position proves it.
Re: (Score:2)
"Oh... I guess the people running UNIX servers will have to install a non-native layer to allow the Wayland folks access. That's just nuts. ?
That's a pretty flimsy straw-man. Of course you'd install an X Server on Windows.
What settings are you using for X over dialup?
Re: (Score:3)
I don't care about RDP either, but have you ever used NX/X2Go instead of straight X forwarding? I find it is much faster and usable even over slow(ish) connections.
Re: (Score:3)
X with compression and caching can work very well actually.
Across the Internet, it runs circles around what VNC can do locally on a gigabit network.
VNC is nothing to hold up as a solution for not having the networking features of X anymore.
Re: (Score:2)
You must be joking.
I've seen what VNC is capable of going from any combination of Unix, Windows, or MacOS.
VNC is just sad when compared to X.
Don't try to confuse RDP with VNC.
Re: (Score:2)
This depends on your method of X forwarding. NX does a pretty good job and isn't slow and is less "buggy" (well, you can't do GLX, but trying to do that via a VPN would be...evil...)- along with handling pretty low bandwidth links well.
Having said this, if RDP does a good enough job and Wayland untangles the whole POSIX desktop world, I'd say it's pretty much a win- esp. if I can do the RDP remoting over moderately low bandwidth links.
Re:Rootless? (Score:5, Insightful)
A few things :
- Microsoft RDP clients are pre-installed on every Windows based client since Windows XP/Server 2003. This means that a majority of non-slashdot-reading admins have all the tools they need to connect to it already installed.
- Microsoft RDP is a lot faster than VNC/X11 forwarding. For one, they do smart bitmap-caching. VNC is screen-shots only (using some sensing of what has changed on the screen to send the diffs), and X11 forwarding were pretty much just UI elements, which made interacting with certain applications difficult or ackward.
- Later RDP versions allow you to forward just specific applications, in addition to the entire workspace. I don't know if FreeRDP supports this feature yet, but it is built into the protocol.
Re: (Score:2)
For one, they do smart bitmap-caching. VNC is screen-shots only (using some sensing of what has changed on the screen to send the diffs)
So what's smart bitmap-caching then, if not (as I'm only naively guessing based on the name) "using some sensing of what has changed on the screen to send the diffs"?
Re: (Score:2)
Not all that familiar with the innards of RDP myself, but the obvious difference is that a bitmap may or may not be visible on the screen, only partially visible, or repeatedly visible. This would allow parts of the bitmap that are currently not on the screen to be sent once to the client and reused over and over again, allowing smoother screen draws and less bandwidth/latency on incremental changes.
Re:Rootless? (Score:5, Informative)
Essentially, the client can request a bitmap representation of an element, or the native UI component. For example, common UI components are sent as UIElements and SkinParts. SkinParts can be sent as vector items (like gradients, lines, etc), or bitmaps themselves. So, for example if you run calc.exe, the client can request the app as a stack of UI elements (essentially, how the GDI plans on drawing the components to the screen). All the buttons, etc. are sent as a component package which describes how the element should look. If it uses a bitmap as a part of its chrome, it is sent as a separate SkinPart.
You can also get bitmap representations of components if the OS thinks it is too difficult to draw them (or the developer just threw a bunch of bitmaps together to represent common UI components). When this happens, calls into the GDI update the RDP server to let it know that a component of size X/Y at X/Y has updated. It's a lot smarter than VNC which has to watch the screen and updates the screen in a 1/x method.
X11 is a bit more primitive... It expects the UI components to be created and skinned by the client. This is really only useful/consistent if both the client and the server are running the same WM. Users of RDP get the same experience regardless of their client.
Re: (Score:2)
Caching the way a button looks, the way your titlebar looks, possibly down to each letter on the screen.,All these are stored Client-side by the Server's request, so instead of sending a 24bpp bitmap of the word "cat" (a few kb), it references a previous: "c.jpg, a.jpg, t.jpg" (which is only a few bytes). It also caches whole windows so a window move isn't expensive.
Re: (Score:2)
- Later RDP versions allow you to forward just specific applications, in addition to the entire workspace. I don't know if FreeRDP supports this feature yet, but it is built into the protocol.
Outside of Windows, this really doesn't exist. I think there is a paid-for program on Mac OS (not the MS RDP) that does this.
Re: (Score:2)
For one, they do smart bitmap-caching.
If you use a window manager and applications that use X primitives rather then drawing everything in bitmapped eyecandy the performance is much faster than RDP. All the anti X forwarding folks have never used the system as it was originally intended which is why we have to see it reinvented again... badly.
Re:Rootless? (Score:4, Insightful)
So the cure to remote performance is to rewrite modern applications to 80 era style, because writing a display server that handles modern apps is doomed to be implemented badly...
Dude, just listen to yourself.
Re: (Score:2)
- Later RDP versions allow you to forward just specific applications, in addition to the entire workspace. I don't know if FreeRDP supports this feature yet, but it is built into the protocol.
It does a lot more that just that...
$ xfreerdp --help
FreeRDP - A Free Remote Desktop Protocol Client
See http://www.freerdp.com/ [freerdp.com] for more information
Usage: xfreerdp [options] server:port
-0: connect to console session
-a: set color depth in bit, default is 16
-c: initial working directory
-D: hide window decorations
-T: window title
-d: domain
-f: fullscreen mode
-g: set geometry, using format WxH
Re: (Score:2)
no, RDP forwards all the bits that have changed - now simpler versions of it will happily forward everything (eg VNC at least in early incarnations, and Microsoft's own RDP protocol) but Citrix did a load of work reducing the amount of screen that was transferred over the network. Microsoft since took that and built it into the kernel (or graphics bits that are in the kernel) so that it became even more optimised - after all, if the OS only redraws a small section, only that section needs to be transferred.
Re: (Score:2)
Not if you wanted to forward the display of a single application. Your use case is not everyones use case.
I understand it now does that too, which is great.
Re: (Score:2)
My use case includes sound, printing, the clipboard and preserving state when disconnected.
VNC will preserve your state, but your performance is gone and you still haven't solved sound, printing or the clipboard.
X11 might give you the middle-button buffer, but not the clipboard.
Re:Rootless? (Score:4, Insightful)
RDP has been able to forward the display of a single application for 5+ years.
Re: (Score:2)
Starting in 2008 RDP doesn't require this either, please go read all about it: http://en.wikipedia.org/wiki/Remote_Desktop_Protocol#Version_6.1 [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
RDP is truly impressive, but not everyone wants to have a desktop on their server.
Is it capable of letting me launch graphical applications from an OS without a local graphical display? I ask because my understanding is windows 2008 has added that as an option.
Re: (Score:2)
Yes, this is very common.
I have KVM installed on a server, I use virt-manager to play with it. I forward X over SSH to run virt-manager and have it display on my local machine. The server has no graphical output. You can feel free to substitute any program with a graphical output you like for virt-manager in my example.
Re: (Score:2)
Sounds like a conventional Windows application installer, doesn't it?
Never wanted to install software from some 3rd party proprietary vendor? It's not like Free Software where you can just integrated it into some yum or apt repository.
Plus you're basically stuck dealing with whatever the vendor wants to give you.
Re: (Score:3)
For one, the programming language should naturally support the notion of doing stuff in a non-blocking way (C/C++ does not naturally support this; simulating this requires working with threads or tinkering with even more low-level machinery).
You what?
Unix has offered non blocking calls more or less since forever, and C was basically invented in order to write unix.
read() can operate in non blocking mode just fine. You might want to check the man pages for read() and select().
Re: (Score:2)
Sorry, but select() doesn't cut it. Using select, you are forced to write ugly event-driven code, with objects representing event-handlers, where all you want to do is run a bunch of snippets of code, where each of them executes as soon as the data is available.
And by the way, using select() you can't even wait for both a file descriptor and a semaphore simultaneously, but that is a different story.
Re: (Score:2)
Using select, you are forced to write ugly event-driven code, with objects representing event-handlers, where all you want to do is run a bunch of snippets of code, where each of them executes as soon as the data is available
How is it ugly? You can do what you want in a few lines of code with a base class, select and a std::unordered_map. With a small amount of care, you can also store a lambda in the derived class, meaning that you have a map of file descriptors to literally code snippits that get run on d
Re: (Score:2)
Sorry, but I want expressiveness without seeing all the ugly low-level stuff.
To go back to the original topic, Wayland needs to remove round-trip times to make the system faster and more responsive.
How can a compiler decide to move code from the client to the server or vice versa if all the plumb-work gets in the way?
Re: (Score:2)
Sorry, but I want expressiveness without seeing all the ugly low-level stuff.
Even versus callback driven is a matter of taste. I strongly suspect there will soon be some good C++11 libraries for callback driven I/O since the language can do it very prettily.
Re: (Score:2)
While Wayland may solve some mundane issues with the client-server nature of remote desktops, I think in general a completely different programming model is needed for client-server applications. For one, the programming language should naturally support the notion of doing stuff in a non-blocking way (C/C++ does not naturally support this; simulating this requires working with threads or tinkering with even more low-level machinery).
I expect we'll see more posts like this now that so many states have decriminalized weed.
Re: (Score:3)
Ah yes, the ever intelligent commentary on Slashdot.
What video did you watch? Was it made within the last few months? You do realize (if the video is covering Weston) that Weston is not only new but also a reference implementation and not intended for production use, right?
This has not a goddamn thing to do with why "Linux on the desktop has failed."