FreeRDP 2.0 – A Remote Desktop Protocol implementation(freerdp.com)
freerdp.com
FreeRDP 2.0 – A Remote Desktop Protocol implementation
https://www.freerdp.com/
124 comments
Options for Wayland are a bit less antiquated. Here’s a couple.
If you are ever using a wlroots based Wayland compositor, then wayvnc becomes an option for RDP. (Note: haven’t personally used this.)
https://github.com/any1/wayvnc
Waypipe offers network transparency to Wayland, where by you can run applications across the network. I believe this should work with roughly any compositor.
https://gitlab.freedesktop.org/mstoeckl/waypipe/
If you are ever using a wlroots based Wayland compositor, then wayvnc becomes an option for RDP. (Note: haven’t personally used this.)
https://github.com/any1/wayvnc
Waypipe offers network transparency to Wayland, where by you can run applications across the network. I believe this should work with roughly any compositor.
https://gitlab.freedesktop.org/mstoeckl/waypipe/
The bottom of the Waypipe README says: "This is usable, but still somewhat unstable right now".
> On Linux I haven't found anything nearly as good. It's really surprising to me too - given that a good visual remoting tool allows for such ease in cross platform living.
Have you tried xpra[1]? I haven't tried forwarding the entire desktop, but I have done multiple individual applications with sharing enabled. There are some issues with different resolutions between the host and guest machine, but it works relatively well.
[1] https://xpra.org/
Have you tried xpra[1]? I haven't tried forwarding the entire desktop, but I have done multiple individual applications with sharing enabled. There are some issues with different resolutions between the host and guest machine, but it works relatively well.
[1] https://xpra.org/
I find X2Go to be a very nice Linux remote desktop solution, more or less on par with MS-RDP on Windows. The only thing I couldn't get to work was continuing a local session remotely (disconnecting and later reconnecting to a remote session works fine). It is packaged in most mainline distributions.
more or less on par with MS-RDP on Windows
That's surprising. I tried X2Go a couple of times on multiple machines (always logging in from Windows to Unbuntu 18.04 if that matters, on a local network) and it was horrible. At least a crash a day, couldn't get numeric keypad keys to work, slow. Not sure if I did anything wrong or just had bad luck.. And those are just the basic features. To get on par with RDP it should also do multiple screens properly (i.e. not one big screen, it's not 2000 anymore), drive/audio/... sharing and so on. But I never got to trying that, went back to VNC. Which also has problems but at least it allows me to do work.
Unfortunately the OP is about right (in my experience, for the things I do): if the connection allows it remote desktop should really be like you're sitting in front of the physical machine. RDP does that for me, on the same level SSH/Mosh does that for terminal stuff. I'm not sure what is so hard to get right to also get something equivalent on Linux, so maybe it's really the lack of interest?
That's surprising. I tried X2Go a couple of times on multiple machines (always logging in from Windows to Unbuntu 18.04 if that matters, on a local network) and it was horrible. At least a crash a day, couldn't get numeric keypad keys to work, slow. Not sure if I did anything wrong or just had bad luck.. And those are just the basic features. To get on par with RDP it should also do multiple screens properly (i.e. not one big screen, it's not 2000 anymore), drive/audio/... sharing and so on. But I never got to trying that, went back to VNC. Which also has problems but at least it allows me to do work.
Unfortunately the OP is about right (in my experience, for the things I do): if the connection allows it remote desktop should really be like you're sitting in front of the physical machine. RDP does that for me, on the same level SSH/Mosh does that for terminal stuff. I'm not sure what is so hard to get right to also get something equivalent on Linux, so maybe it's really the lack of interest?
> That's surprising.
Same experience. None of the Linux alternatives are on the same planet as RDP.
> I'm not sure what is so hard to get right to also get something equivalent on Linux, so maybe it's really the lack of interest?
As far as I can see it's lack of interest made worse by the usual fragmentation of effort.
Which makes me sad. I really enjoy KDE Neon on my secondary PC, but the lack of a viable remote desktop solution means it'll stay there.
Same experience. None of the Linux alternatives are on the same planet as RDP.
> I'm not sure what is so hard to get right to also get something equivalent on Linux, so maybe it's really the lack of interest?
As far as I can see it's lack of interest made worse by the usual fragmentation of effort.
Which makes me sad. I really enjoy KDE Neon on my secondary PC, but the lack of a viable remote desktop solution means it'll stay there.
NoMachine is the best X platform solution I've found, not perfect, but can even handle video over WiFi to an extent.
I have been using Linux-to-Linux; multiple monitors work without problems, with respect to docking to edges etc. I use it as a a graphical terminal when I work from home, i.e. I sit in front of my machine at home, but everything happens on the machine at work. Laptop screen with 1440x900 resolution does not feel sluggish on effectively 40 Mbps wireless network, desktop screen with 3840x2160 works fine over 75 Mbps residential broadband. I can have voice chats over that link too. Electron apps are redraw hogs though; they feel a little bit sluggish at 4K. I would rather use 2560x1440 then. Emacs is fine in either.
I've done a lot of work through x2go, also windows machine connecting to ubuntu. And I've almost exclusively used seamless windows which makes superior multi-screen (and single screen) UX as window management is just native windows.
Well, I guess it depends on the use case etc. but I find seamless windows to be the holy grail for most of my work. And the ability to resume an entire session is great!
Didn't have that many crashes, maybe once a month or something, still a bit frustrating but not enough to scare me away. But yeah, maybe I was lucky, didn't get the most reliable impression of it but it did still do wonders for me.
Well, I guess it depends on the use case etc. but I find seamless windows to be the holy grail for most of my work. And the ability to resume an entire session is great!
Didn't have that many crashes, maybe once a month or something, still a bit frustrating but not enough to scare me away. But yeah, maybe I was lucky, didn't get the most reliable impression of it but it did still do wonders for me.
Not surprising to me, I've been using x2go for many years now and have hardly ever had it crash - I can't remember the last time but it is sure to have happened... I guess. I'm using it both within a LAN as well as over a VPN between countries. I'd say x2go make true on the promise of network-transparency which X11 gives in theory but which is hard to use in practice.
[deleted]
+1 for X2go. The only solution I've found that didn't mess up scaling on 3,4k screens.
There's a mess of different VNC implementations with wildly varying speed and quality. TurboVNC is probably the best one I've found, it feels pretty similar to RDP in terms of performance (even without setting up their 3d acceleration stuff).
I had slightly better luck with tigervnc a few years back. (TurboVNC was a close #2 if I remember right.)
It was able to play full screen youtube on a RPi 3 over local wifi. :-)
It was able to play full screen youtube on a RPi 3 over local wifi. :-)
Although proprietary, I find Thinlinc Just Works and the server is free for less than 6 simultaneous connections and supports opengl natively in applications (and is based on TurboVNC iirc). It's very much a drop-in replacement. Clients are on all OSes. They give money upstream.
Highly recommend ThinLinc, it's simply the best in class. I don't know why it isn't more widely known.
I think, it's not known well in the space, because the target audience is either interested in "comes from Microsoft, with support", "i want an audit-able solution, shared-source, or open-source", "is installable through my normal package sources", "something i can build/setup/cluster/manage myself". Thinlinc (iiuc) is none of those. Please correct me, if my info is inaccurate/outdated.
Hum, well it doesn't come from Microsoft but I believe it has paid support, and it is auditable, like you can setup access logs and all that, and it has an admin interface and can be self hosted managed with an admin interface and all that jazz. You can setup a cluster of them as well, I think their main business are schools and such. Though yes, it is closed source (for the most part, since it uses TigerVNC under the hood and ssh I think, so it's partially open source in that sense). And ya you need to install it with their installer.
But I just use it for personal remote desktop, I have a cloud instance and I remote to it for my dev work, while my laptop runs windows. I find it's better than say trying to use WSL.
But I just use it for personal remote desktop, I have a cloud instance and I remote to it for my dev work, while my laptop runs windows. I find it's better than say trying to use WSL.
I run xrdp on Ubuntu and connect to it from a windows machine using the Remote Desktop client. It has some restrictions- and setup issues (https://help.ubuntu.com/community/xrdp) but I use it daily to drive a remote CNC machine's host.
Have you gotten it working with just those steps? Every single tutorial we have tried on our work machines have resulted in failure with Ubuntu 18.04. I can usually get to a login prompt but then logging in just gives me a black screen, or other times the login is always rejected.
VNC works, but is so painfully antiquated in comparison to RDP. It guzzles way too much bandwidth even if all you have is a blinking cursor on screen. I really wish there was a solid RDP server for Ubuntu. I'm quite surprised at the state of things on this front.
VNC works, but is so painfully antiquated in comparison to RDP. It guzzles way too much bandwidth even if all you have is a blinking cursor on screen. I really wish there was a solid RDP server for Ubuntu. I'm quite surprised at the state of things on this front.
I recently found a script, that fixed my issues:
https://c-nergy.be/blog/?p=14093
https://c-nergy.be/blog/?p=14093
Thanks for the link!
Yes, I have gotten it working with those steps.
If you get the black screen I think that means somebody is logged into the console (the hardware X session). That's the big caveat (I used to use x11vnc, which let you vnc into the system's hardware X session then disconnect, and use the console directly).
If you get the black screen I think that means somebody is logged into the console (the hardware X session). That's the big caveat (I used to use x11vnc, which let you vnc into the system's hardware X session then disconnect, and use the console directly).
Thanks. Do you know if you can have a vnc server running in tandem with xrdp? I'm not a big fan of the limitation of only one active session being allowed with xrdp as we do a lot of remote work on our Ubuntu boxes and VNC has been foolproof on that front. Being locked out of my box over the weekend (or during this extended stay at home period) because something got messed up with user sessions would be very annoying/limiting. With an active VNC session, I supposed I could use that as a fallback to ensure that I logout of the local session to ensure continuing connectivity with RDP.
As long as you can log in via SSH, there should be no software error combination w.r.t. graphical surfaces capable of locking you out of your system. From the SSH prompt you can fix everything, should that ever be needed.
Thanks. And you're right, that is very true. I'm just not very familiar myself with how to terminate local/remote graphical sessions via an SSH shell connection to juggle the limitations of xrdp on Ubuntu at the moment. Something for me to explore on a test box at some point I suppose.
If you are trying to setup xrdp on GCP/AWS/Azure then there is a VM available on the marketplace with preinstalled xrdp, GUI and lot of other opensource apps. You can spinoff your instance from that vm and you are good to go with RDP and remote desktop.
https://console.cloud.google.com/marketplace/details/techlat...
https://aws.amazon.com/marketplace/pp/B084L3S2FF?qid=1583409...
https://azuremarketplace.microsoft.com/en-us/marketplace/app...
https://console.cloud.google.com/marketplace/details/techlat...
https://aws.amazon.com/marketplace/pp/B084L3S2FF?qid=1583409...
https://azuremarketplace.microsoft.com/en-us/marketplace/app...
The krdc & xfreerdp combination is terrible. I don't know which program is at fault (probably krdc), but it's not working well at all.
There's the occasional random disconnection to right-click rarely leading to disconnection to a case where xfreerdp asks for a password in the terminal but I don't see it in krdc.
There's the occasional random disconnection to right-click rarely leading to disconnection to a case where xfreerdp asks for a password in the terminal but I don't see it in krdc.
I've used krdc with rdp to connect to windows clients often and always without any issues. Maybe it's a regression introduced only recently?
The first & last are definitely long standing. The second is rare, but I think it got worse recently. All of these are frequent enough to annoy, but not frequent enough to make the combination useless, since I can reconnect.
I will be giving remmina a shot to see if it improves things, though I'd have rather used a Qt-based client as to match KDE better.
I will be giving remmina a shot to see if it improves things, though I'd have rather used a Qt-based client as to match KDE better.
Yep, krdc needs a lot of love - I just use the freerdp command line program and that works great.
I'm growing to like xpra for remoting graphical applications, especially with the HTML5 client.
Not sure if you're aware, so I apologise if you are:
1) X11 is already a network aware display system, so it wouldn't take too much work to run remote.
2) SSH has built-in X11 forwarding with `ssh -X <host>`, when you run commands they will be rendered locally. On OSX this needs an X11 server (XQuartz) to work properly.
3) There are "better" remote desktop solutions like "parsec"[0] which run on Windows and Linux. They offer much lower latency and higher bit-depth. They're designed for games. (obviously this comes at the price of bandwidth).
[0]: https://parsecgaming.com/features/
1) X11 is already a network aware display system, so it wouldn't take too much work to run remote.
2) SSH has built-in X11 forwarding with `ssh -X <host>`, when you run commands they will be rendered locally. On OSX this needs an X11 server (XQuartz) to work properly.
3) There are "better" remote desktop solutions like "parsec"[0] which run on Windows and Linux. They offer much lower latency and higher bit-depth. They're designed for games. (obviously this comes at the price of bandwidth).
[0]: https://parsecgaming.com/features/
X11 is network aware, in that is theoretically possible to speak the protocol over a network. However, anyone considering it should be aware that it is (1) extremely chatty, (2) extremely synchronous, and (3) extremely latency sensitive. It only works well on fast local networks. SSH certainly doesn't make it any faster.
In contrast, RDP and VNC type protocols are screen-replicating designs more suited to higher latency connections.
Finally, if you're using RDP, I'd suggest Remmina as an client. It's fantastic.
In contrast, RDP and VNC type protocols are screen-replicating designs more suited to higher latency connections.
Finally, if you're using RDP, I'd suggest Remmina as an client. It's fantastic.
To pile on against X11 over ssh, forwarding on a modern Linux workstation is spectacularly painful. I recently needed to forward a lightweight gtk app from one workstation to another over 10gbe and a single switch hop.
With ssh and X forwarding, my local gnome constantly threw up modal dialogs that the forwarded window was unresponsive, forcing me to keep clicking "Wait" to dismiss the modal, then quickly interact with the forwarded window before the next "unresponsive" modal popped up.
With ssh and X forwarding, my local gnome constantly threw up modal dialogs that the forwarded window was unresponsive, forcing me to keep clicking "Wait" to dismiss the modal, then quickly interact with the forwarded window before the next "unresponsive" modal popped up.
Forwarding Firefox over X11 _sometimes_ works. Sometimes Firefox on the remote machine will try to join the session of your local firefox -- but fail and then complain that there's Firefox already running. Adding `--new-instance` helps if Firefox is running in a container and X11 socket file is forwarded to the container but it doesn't seem to help if X11 is forwarded over SSH.
Try '-no-remote'. Or was that '--no-remote'? Anyway, that's what I've used for years and years when needing to run firefox over ssh X forwarding.
Firefox is running on the remote, connected to a different X11 session. It is not running on the local. When I use `firefox --new-session --no-remote` on the remote, I see a dialog pop up on my local machine stating Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.
Yes, this is because firefox doesn't allow multiple ff instances to use the same profile at the same time. You can ask firefox to create a new profile (`firefox -ProfileManager`) and then use a seperate profile for the remote instance
> extremely synchronous
X11, the protocol, is actually mostly asynchronous, it's the libraries and the applications that were built around it in synchronous ways. If you run older applications (like 90s to early 2000s) over X11, it's a lot less bad than modern apps.
X11, the protocol, is actually mostly asynchronous, it's the libraries and the applications that were built around it in synchronous ways. If you run older applications (like 90s to early 2000s) over X11, it's a lot less bad than modern apps.
Isn't that mostly because modern apps have richer textures and high resolution, high bit depth images by comparison?
Maybe to some degree; head of line blocking and window sizes are real issues that would cause delays; but most of the problem is around requiring more round trips. This is what has made running X servers as thin clients go from being viable on the 10M ethernet of the 90s to being a terrible idea on 1G ethernet today.
Thanks for suggesting remmina, it might be a teamviewer substitute for a couple old relatives PCs. However I have to solve the dynamic IP problem that doensn't exist on teamviewer, so I was attempting to build a string that sends an email with the IP as payload.
Something like this: curl --url 'smtps://smtp.gmail.com:465' --ssl-reqd --mail-from 'xyz remote IP' --mail-rcpt '[email protected]' --upload-file mail.txt --user '[email protected]:pwd'
Where rather than the mail.txt file I can send the public IP of the remote machine, such as the output of "curl ipinfo.io/ip". Unfortunately I couldn't find how to do that. Backquotes also don't work, it wants a file.
The purpose would be to build a "pre-command" one liner that sends me an email with the remote IP as payload every time the remote user accepts an external connection through remmina. The remote users are old relatives with no knowledge about computers, so the simpler (one click) the better.
Something like this: curl --url 'smtps://smtp.gmail.com:465' --ssl-reqd --mail-from 'xyz remote IP' --mail-rcpt '[email protected]' --upload-file mail.txt --user '[email protected]:pwd'
Where rather than the mail.txt file I can send the public IP of the remote machine, such as the output of "curl ipinfo.io/ip". Unfortunately I couldn't find how to do that. Backquotes also don't work, it wants a file.
The purpose would be to build a "pre-command" one liner that sends me an email with the remote IP as payload every time the remote user accepts an external connection through remmina. The remote users are old relatives with no knowledge about computers, so the simpler (one click) the better.
>it wants a file
Have you tried process substitution?
Have you tried process substitution?
<(curl -s ipinfo.io/ip)
Worked perfectly, thanks!
I find running GUI GNU Emacs over X11 over ssh to be really pleasant, even moreso than using tramp (which occasionally hangs for no understandable reason), with the only problem being that highlighting text is a bit slow and balky. Otherwise, it's indistinguishable from a local Emacs in responsiveness.
Along with better performance and reliability than X11 RDP allows redirection of sound, folders, USB devices, and can present a virtual GPU which allows access to the physical GPU of the remote end.
X11 works remote, but to my knowledge only to start new applications.
Connect to an existing session and just "continue where you were" is not easy though there might be unmaintained solutions.
If you use ssh forwarding and for some reason gets disconnected, the application dies.
I'd love for you to tell me I'm wrong :-)
The way rdp works on windows is the only thing where I think windows is superior.
Vnc, TeamViewer and similar are not remotely close and they will leave your remote screen open for anyone to see.
Connect to an existing session and just "continue where you were" is not easy though there might be unmaintained solutions.
If you use ssh forwarding and for some reason gets disconnected, the application dies.
I'd love for you to tell me I'm wrong :-)
The way rdp works on windows is the only thing where I think windows is superior.
Vnc, TeamViewer and similar are not remotely close and they will leave your remote screen open for anyone to see.
Xpra is what you want for this: http://xpra.org/
I was hopeful that Xpra would provide reconnectable remote sessions for me on my Linux workstations but I found it pretty difficult to configure with poor documentation. If there are any better installation guides out there, I'd appreciate a pointer to them.
Although with teamviewer (maybe others) I think a display driver install can black out the far-end screen.
Isn't RDP more akin to VNC than X11? You can connected and reconnect to existing sessions, something you cannot do with X11 (but can with VNC).
I have never heard of Parsec before but it's not immediately obvious that it's an alternative to RDP (Desktop usage)
I have never heard of Parsec before but it's not immediately obvious that it's an alternative to RDP (Desktop usage)
As far as connecting to existing sessions goes, yes, RDP is closer to VNC to X11. In that respect only though: you can't also simultaneously use the same session locally unlike with VNC.
However, as far as the actual implementation goes, RDP is closer to X11 than VNC. VNC is basically a remote frame buffer, akin to streaming video. This makes it very cross platform friendly, but also IMO feels very slow, even on a local network. RDP is closer to X11 in that it sends display directives (AFAIK, please correct me if I'm wrong) so that it can draw them on the client as they would be drawn on the server. Think sending a "draw button" command rather than sending an image of pixels that are how the button would be rendered. This, combined with compression, helps make RDP feel very fast compared to VNC, and can be used very well even over the internet, unlike X11. I connect to RDP servers in Azure all the time and sometimes forget I'm not working locally, while with VNC you're always aware that it's not as performant.
I really wish there was something like RDP as a server for Linux. (OP seems to be a client AFAICT?) Given Microsoft's recent investment in Linux, maybe this will happen soon?
However, as far as the actual implementation goes, RDP is closer to X11 than VNC. VNC is basically a remote frame buffer, akin to streaming video. This makes it very cross platform friendly, but also IMO feels very slow, even on a local network. RDP is closer to X11 in that it sends display directives (AFAIK, please correct me if I'm wrong) so that it can draw them on the client as they would be drawn on the server. Think sending a "draw button" command rather than sending an image of pixels that are how the button would be rendered. This, combined with compression, helps make RDP feel very fast compared to VNC, and can be used very well even over the internet, unlike X11. I connect to RDP servers in Azure all the time and sometimes forget I'm not working locally, while with VNC you're always aware that it's not as performant.
I really wish there was something like RDP as a server for Linux. (OP seems to be a client AFAICT?) Given Microsoft's recent investment in Linux, maybe this will happen soon?
RDP is definitely closer to the framebuffer style rendering than sending explicit draw commands. Newer versions of the RDP protocol have made this very efficient so it only ends up having to transmit compressed data of the changes per frame, but overall its still more of a video-like stream than true local rendering a la X11.
> RDP is definitely closer to the framebuffer style rendering than sending explicit draw commands.
RDP has capability[1] to send draw commands directly.
From memory it has had this since the early days. At least I used RDP against NT4 servers over a single ISDN link and it was very smooth. I can't believe it could have done that by streaming bitmaps ala VNC.
[1]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
RDP has capability[1] to send draw commands directly.
From memory it has had this since the early days. At least I used RDP against NT4 servers over a single ISDN link and it was very smooth. I can't believe it could have done that by streaming bitmaps ala VNC.
[1]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
> From memory it has had this since the early days.
Found an RDesktop implementation from 2001[1] which implements the draw commands. So yeah, old stuff.
[1]: https://soulsphere.org/hacks/rdesktop-sdl/
Found an RDesktop implementation from 2001[1] which implements the draw commands. So yeah, old stuff.
[1]: https://soulsphere.org/hacks/rdesktop-sdl/
X network protocol isn't really sending draw commands unless you're using Motif or Xaw or something equally outdated.
Thanks! I guess I had been misinformed on that. I was also probably thinking of the RemoteFX stuff, like GPU and media redirection: https://en.wikipedia.org/wiki/RemoteFX
No, you are not misinformed. Both RDP and X11 can send both drawing commands and bitmaps. However, as /u/moonchild says, only older programs seems to be sending drawing commands directly. Newer programs want to be fancy and uses toolkits that do their own drawing to have visual effects. (Witness the speed of Emacs vs. editor-du-jour)
> Newer programs want to be fancy and uses toolkits that do their own drawing to have visual effects
Good toolkits like WPF and UWP implement their own drawing by utilizing Direct3D. These two are using DX 9.0c and D3D 11.0 respectively, and both are supported in RDP protocol.
If you connect to a remote PC and run dxdiag.exe there, you’ll see 3D acceleration is supported, you’ll also see the GPU driver got replaced with completely different one, it’s no longer Intel, Nvidia or AMD, but the one from MS.
This has interesting consequences, e.g. all D3D APIs which move data from system RAM or VRAM or back now become network calls, the system RAM is on the server, VRAM is on the client.
P.S. Modern web browsers use Direct2D and DirectWrite to render stuff on Windows, there’s D3D 11 underneath, i.e. RDP remote rendering is fully supported for browsers and Electron apps.
Good toolkits like WPF and UWP implement their own drawing by utilizing Direct3D. These two are using DX 9.0c and D3D 11.0 respectively, and both are supported in RDP protocol.
If you connect to a remote PC and run dxdiag.exe there, you’ll see 3D acceleration is supported, you’ll also see the GPU driver got replaced with completely different one, it’s no longer Intel, Nvidia or AMD, but the one from MS.
This has interesting consequences, e.g. all D3D APIs which move data from system RAM or VRAM or back now become network calls, the system RAM is on the server, VRAM is on the client.
P.S. Modern web browsers use Direct2D and DirectWrite to render stuff on Windows, there’s D3D 11 underneath, i.e. RDP remote rendering is fully supported for browsers and Electron apps.
Parsec for Linux is only a client; you can't share a Linux desktop using Parsec.
parsec does not support multiple monitors which is a deal breaker in many use cases, so far windows rdp is the best free solution for at least windows -> windows remoting.
There is actually an awesome RDP server (called ogon project) based on FreeRDP available:
https://github.com/ogon-project/ogon
https://github.com/ogon-project/ogon
Looks interesting... thank you. Are you using it in production?
yes! for a customer with many hundred stores in eastern europe. each office has a pc linux server running ogon which is serving their x11 based ERP software via RDP to up to 20 rdp clients (mobile handhelds and stationary thin clients)
When I used X2go a couple of years ago I found it to work quite well.
https://en.m.wikipedia.org/wiki/X2Go
https://en.m.wikipedia.org/wiki/X2Go
XRDP (http://xrdp.org/) seems to be a good alternative. It works really well for us for our cloud VMs.
It's strange nobody mentioned NX (NoMachine). When I tried it ~10 years ago, it was much faster than VNC, nearly identical to RDP. Why isn't it more popular?
NX was fine in the 3.5.x series, but the client is wonkish from 4.x (and out?). X2Go is based on the same (open-source) underlaying library, and seems to be better. At least in my opinion, and maybe in others here too since nobody apparently mention NX anymore.
When I tried it last year it was a pretty horrible experience because it installed client and server on Windows and macOS when I just wanted the client. I had to go in and kill some services for the server part. Having to do stuff like that for security reasons is a bit of a turn off.
The actual performance of NX was good, so I'll give them that. I think other people having licencing concerns, but I'm fine with it.
The actual performance of NX was good, so I'll give them that. I think other people having licencing concerns, but I'm fine with it.
Even better than NX is ThinLinc, much more reliable, faster connections and handle dynamic resolution resizing.
Use this one: https://www.cendio.com/thinlinc/download
I tried them all, and this one is awesome! It is actually better then Windows RDP. Fast, reliable, secure, and can handle all resolutions and allow you to dynamically resize the screen share. Seriously! Free to use for small user groups and home users for free, with a maximum of 5 concurrent users.
Thank me later ;)
I tried them all, and this one is awesome! It is actually better then Windows RDP. Fast, reliable, secure, and can handle all resolutions and allow you to dynamically resize the screen share. Seriously! Free to use for small user groups and home users for free, with a maximum of 5 concurrent users.
Thank me later ;)
I generally use X11 forwarding over ssh provided I trust the host system.
> On Linux I haven't found anything nearly as good.
Xrdp on the server side works pretty well for us once you get it set up correctly.
Xrdp on the server side works pretty well for us once you get it set up correctly.
Idk, I set up one last week and no matter the tunning I did it didn't work at all, like screen tearing and extermly low frame rates.
Weird, we don't get that at all. Are you using the Xrdp backend or the Xvnc backend?
Weird question, how do sysadmins normally administer windows? Rdp? Psexec? Something else?
Mostly RDP, many things (still) require a GUI, and Windows Server Core is something relativly new and has some issues because not everything is exposed to shell.
I'd guess most Unix natives consider SSH to be superior to RDP. SSH give you shell access which is a better interface for working with remote systems than a GUI.
x11vnc is what I use
What do you need and expect? I have never needed more than VNC offers, but I also don't play games on a remote computer or view videos over that connection.
A number of reasons actually. If you're trying to create a multi-user VNC environment on a remote server the displays do not always render correctly certain applications particularly those requiring 3D components. It can be quite frustrating. Moreover not all keyboard keys are recognized in certain applications. The single user version of VNC, i.e. classic VNC, works well, however it does actually show your remote session on the server computer screen and yes, as best I can tell, the server must have a monitor.
I've had about enough of the compromises I've had to make to make my remote VNC sessions work and mostly have opted to run virtual instances of Linux on my local desktop then SSHFD mount a drive remotely but this is such a pain or can be especially in some applications some research applications which can vary results depending on operating system version and kernel libraries.
I never experienced these issues with Windows remote desktop and this is very frustrating as a Linux user.
I've had about enough of the compromises I've had to make to make my remote VNC sessions work and mostly have opted to run virtual instances of Linux on my local desktop then SSHFD mount a drive remotely but this is such a pain or can be especially in some applications some research applications which can vary results depending on operating system version and kernel libraries.
I never experienced these issues with Windows remote desktop and this is very frustrating as a Linux user.
RDP is more suited to text as it renders the screen pixel perfect. VNC, on the other hand, converts the screen into a lossy compressed video stream which is why it’s often slow and fuzzy until the image stabilizes. Night and day difference.
I'd encourage freerd.com to be more descriptive on the landing page - the blurb says "RDP Implementation", but it's not clear if it's client, server, or both. As a client, this is only useful to people accessing Windows.
It also doesn’t mention the supported OSs prominently either...
All the Linux remote desktop server solutions are bad enough over a WAN that I typically VPN into my office, then RDC from my home Windows box into my office Windows box, then ssh -X from there into my office Linux box. It's kinda crazy, but it works better than anything else I've found, and I've tried almost all the options mentioned here. I wish there was a better way, but I don't think there is (for me)...
You are not alone. I am doing it too. RDP on Windows is far superior than VNC in overall.
If you don't care about X11 security at all (e.g. LAN, but be careful!) you can set $DISPLAY in the ssh session without -X option. I found it unencrypted X11 is a way faster than ssh -X forwarding.
If you don't care about X11 security at all (e.g. LAN, but be careful!) you can set $DISPLAY in the ssh session without -X option. I found it unencrypted X11 is a way faster than ssh -X forwarding.
Really? I agree "a new remote desktop" makes me suspicious about usage over WAN because most all suck. I didn't have great luck with Windows Remote Desktop, either. We went with TurboVNC/VirtualGL on the server and recommended, I think, TurboVNC on the client (via ssh). I used macOS Screen Sharing.app because it wasn't Java and was more comfortable to use IMHO (with things like screen scaling and fullscreen). Most other VNC clients performed significantly worse. I usually ran the desktop around 1440x900.
This seemed to be the best setup with high latency and low bandwidth situations. We had people spanning the furthest time zone.
This seemed to be the best setup with high latency and low bandwidth situations. We had people spanning the furthest time zone.
Well, it's been a while, but the last time I tried VNC it was much, much slower than RDP. Also, (and I haven't really thought deeply about why this is) I much prefer "remote desktop" solutions (like RDC) to "screen sharing" solutions (like VNC, TeamViewer, AnyDesk) for day-to-day work. (That having been said, I love TeamViewer for helping my parents with their computer issues. But luckily I don't have to do that too often.) My ideal is something like ssh, but, you know, with graphics. So I should be able to login with my usual credentials, and not have to set a special uber-password that can hypothetically allow someone to connect to an ongoing root session (like VNC does). Bonus points if it's installed by default and I don't really have to configure the server. Windows RDP does all of this.
The OP sounds crazy but it really works for me too. Try RDP on windows. It even works so well over a mobile hotspot!
I've never got this working, but it seems like the best combo, is there an easy GUI way to connect to VirtualGL / TurboVNC and tutorial to do the server side, it didn't look straightforward when I looked a few years ago.
Sorry. Our sysadmin had set it up. We relied on OpenGL applications and had multiple users, so we weren't using :0. I thought I got it working (sans OpenGL/VirtualGL) by just installing the rpm, then each user would run `vncserver -geometry 1440x900 :89` (their per-user port) to launch the server, then connect via the client.
We did have issues periodically. Mostly because the workstations were mostly not interactive, but if someone would plugin or unplug a monitor X would change configuration on the next reboot. Or when we had multiple GPUs we'd tweak things. I wish I kept better notes.
We did have issues periodically. Mostly because the workstations were mostly not interactive, but if someone would plugin or unplug a monitor X would change configuration on the next reboot. Or when we had multiple GPUs we'd tweak things. I wish I kept better notes.
Microsoft should really consider releasing their official implementation as open source and integrating it with Linux desktop in a way that doesn't suck. Vnc sucks pretty bad. NoMachine sucks a bit less, but doesn't seem to be maintained. RDP doesn't suck at all. I've worked with Windows machines halfway across the globe using it, and while the experience wasn't super snappy, it was usable. I also spent thousands of hours working from home using RDP when I was at MS in 00's. With sufficient network bandwidth, in full screen, the experience is indistinguishable from a local desktop.
Microsoft has released[1] the RDP documentation, which is what FreeRDP is based on[2]. Open-sourcing their implementation would not help, since it's deeply integrated into the OS.
I was hoping Wayland would take remote desktop seriously when I heard about the effort, but sadly that was not to be.
[1]: http://www.microsoft.com/openspecifications/
[2]: https://github.com/FreeRDP/FreeRDP/wiki/Reference-Documentat...
I was hoping Wayland would take remote desktop seriously when I heard about the effort, but sadly that was not to be.
[1]: http://www.microsoft.com/openspecifications/
[2]: https://github.com/FreeRDP/FreeRDP/wiki/Reference-Documentat...
How would you propose Wayland take remote desktop seriously?
By taking it into consideration from day 1, as a decent remote desktop experience requires tight integration.
Wayland doesn't work properly even without these considerations though. Horrible tearing in Chrome when watching video, at least on my machine, crazy high CPU usage too. I had to switch back to X.
Has anyone been able to get FreeRDP's Thincast Workstation (based on VirtualBox) product to work?
http://www.freerdp.com/2019/02/20/hi-thincast-workstation
I know it's still in beta, but it was originally released two years ago and I'm still not able to boot ubuntu's mini.iso installation media in this graphics-optimized version of VirtualBox.
If anyone has been able to test Thincast workstation performance, can they compare it to a Hyper-V linux virtual machine connected to X410 through VSOCK:
https://x410.dev/cookbook/hyperv/using-x410-with-hyper-v-lin...
http://www.freerdp.com/2019/02/20/hi-thincast-workstation
I know it's still in beta, but it was originally released two years ago and I'm still not able to boot ubuntu's mini.iso installation media in this graphics-optimized version of VirtualBox.
If anyone has been able to test Thincast workstation performance, can they compare it to a Hyper-V linux virtual machine connected to X410 through VSOCK:
https://x410.dev/cookbook/hyperv/using-x410-with-hyper-v-lin...
I was using (well trying to use) FreeRDP/XRDP for a while to work with my multiple Linux machines from the Windows client. Soon I've discovered that it was not XRDP working for me but the other way around. I replaced it with NoMachine and and never looked back since.
Now I am somewhat curious but frankly from a practical standpoint I have very little motivation to stop doing what I am doing just to check this new one. It will disrupt my routine for the sake of completely unknown outcome which in the best case will let me have what I already have now. And in the worst case - the opposite of sky is the limit.
This is not to discourage developers but just to show what missed opportunity might cost should there be more people like myself.
Now I am somewhat curious but frankly from a practical standpoint I have very little motivation to stop doing what I am doing just to check this new one. It will disrupt my routine for the sake of completely unknown outcome which in the best case will let me have what I already have now. And in the worst case - the opposite of sky is the limit.
This is not to discourage developers but just to show what missed opportunity might cost should there be more people like myself.
Same, Nomachine has a GUI, and importantly discovery of clients on the network.
The performance is a lot better than VNC.
In theory I could setup VirtualGL and TigerVNC, but it seems like a lot of work, and time I just don't have.
Other clients could do well to see how easy NoMachine makes things.
The performance is a lot better than VNC.
In theory I could setup VirtualGL and TigerVNC, but it seems like a lot of work, and time I just don't have.
Other clients could do well to see how easy NoMachine makes things.
Install process is not straight forward in Ubuntu and it is installed in a not usual binary search path (look at /opt). No complain against the software (it's excellent) but I think this is a small bug for usability.
We changed the URL from https://www.freerdp.com/ to the home page since this project doesn't seem to have been discussed on HN before.
I have used NoMachine. Liked the experience while connecting to Ubuntu from Windows client. With client running on Mac & server on Linux - it is Okay experience - not great. Is FreeRDP 2.0 better? Will try it anyways.
Unlike others here, I am non plussed by an open source implementation of an old format mostly used by non free operating systems. It doesn't add much.
I would be far more interested by a GPU accelerated server, with a focus on low latency, like parsec: something more or less equivalent, with native support for wayland or xorg would be much more interesting.
This would superset the uses of RDP: you can use parsec for remote desktops, just like you can with RDP except it's smoother and more responsive.
But you can also use games with parsec, something you can't do with RDP, and everything else that requires low latency.
I would be far more interested by a GPU accelerated server, with a focus on low latency, like parsec: something more or less equivalent, with native support for wayland or xorg would be much more interesting.
This would superset the uses of RDP: you can use parsec for remote desktops, just like you can with RDP except it's smoother and more responsive.
But you can also use games with parsec, something you can't do with RDP, and everything else that requires low latency.
Many people, myself included, use this software to connect to remote windows machines that we have no control over. It's incredibly valuable, you're just not the target audience apparently.
What's the performance vs Remina?
Remmina uses freerdp as its RDP library.
I found it to be somewhat faster when comparing between the packages my distro had, but YMMV.
What did make a _noticeable_ difference was to download the FreeRDP sources and compile everything statically. That blew Remmina out of the water. I did not do the same for Remmina though, so the comparison is not fair.
What did make a _noticeable_ difference was to download the FreeRDP sources and compile everything statically. That blew Remmina out of the water. I did not do the same for Remmina though, so the comparison is not fair.
Remmina is a just GUI frontend. You can choose a RDP backend between FreeRDP and RDesktop.
I was severely disappointed when it turned out the Hyper-V Linux enhanced session relied on RDP and the experience was pretty bad. Was hoping for something from Microsoft that was a step up from VirtualBox and VMWare in every way and particularly the latency department. Maybe this new release of free is a major improvement?
Have you tried FreeRDP's Thincast Workstation (based on VirtualBox)?
http://www.freerdp.com/2019/02/20/hi-thincast-workstation
I know it's still in beta, but it was originally released two years ago and I'm still not able to boot ubuntu's mini.iso installation media in this graphics-optimized version of VirtualBox.
Interested also if anyone who has been able to get Thincast workstation to boot linux can compare it to a Hyper-V linux virtual machine connected to X410 through VSOCK:
https://x410.dev/cookbook/hyperv/using-x410-with-hyper-v-lin....
VSOCK could improve RDP latency since it should be faster than a localhost network socket.
http://www.freerdp.com/2019/02/20/hi-thincast-workstation
I know it's still in beta, but it was originally released two years ago and I'm still not able to boot ubuntu's mini.iso installation media in this graphics-optimized version of VirtualBox.
Interested also if anyone who has been able to get Thincast workstation to boot linux can compare it to a Hyper-V linux virtual machine connected to X410 through VSOCK:
https://x410.dev/cookbook/hyperv/using-x410-with-hyper-v-lin....
VSOCK could improve RDP latency since it should be faster than a localhost network socket.
The RDP server is one thing I miss from Windows though. On Linux I haven't found anything nearly as good. It's really surprising to me too - given that a good visual remoting tool allows for such ease in cross platform living.
I suppose there are a lot of reasons for this, but primarily I guess that most Unix natives would consider SSH to be good enough.