RDP Clients for Debian: An incomplete review(smackeyacky.blogspot.com)
smackeyacky.blogspot.com
RDP Clients for Debian: An incomplete review
https://smackeyacky.blogspot.com/2022/03/rdp-clients-for-debian-incomplete-review.html
69 comments
I would like an RDP server for Debian / Linux. I currently use NoMachine as an adequate replacement, and to be honest it enables me to do the limited amount I need to do with minimal "getting in the way" and I've been using it satisfactorily for a few years. But it's just not the same smooth experience that I remember from using RDP; feeling like you're actually sitting at the machine (pending network bandwidth and conditions).
NoMachine is brilliant, however, given how much I paid for it. The "Enterprise client" is a free and no-install-necessary executable client, which I've found useful for allowing remote administration from a machine on which I don't have admin / install privileges.
NoMachine is brilliant, however, given how much I paid for it. The "Enterprise client" is a free and no-install-necessary executable client, which I've found useful for allowing remote administration from a machine on which I don't have admin / install privileges.
Try http://xpra.org/ - that's a "gnu screen" for X11, but bandwidth-optimized, can also relay USB, audio, ...
Just to give you an idea: I used it for forwarding a Firefox window across an UMTS connection when sitting in a train. (Long story: 32bit Java required to remote desktop into a client's environment across the Atlantic, ugh.)
Just to give you an idea: I used it for forwarding a Firefox window across an UMTS connection when sitting in a train. (Long story: 32bit Java required to remote desktop into a client's environment across the Atlantic, ugh.)
I have tried xpra, and it was my go-to option until I tried NoMachine. I did try just forwarding windows, Firefox it was too, but there was some(times) frustrating delays.
I may re-visit, however, as the delays could have been network/environment issues rather than the technology.
I may re-visit, however, as the delays could have been network/environment issues rather than the technology.
Yeah I wonder why RDP on Windows is just so efficient. It is another block pusher as far as I understand. But it performs so well.
I've even used it over a 9600 baud dialup connection (a long time ago from a 2G mobile that didn't have GPRS) and it was usable to my suprise.
I've even used it over a 9600 baud dialup connection (a long time ago from a 2G mobile that didn't have GPRS) and it was usable to my suprise.
> It is another block pusher as far as I understand.
While that is the most basic thing RDP allows for[1], it also supports sending GDI draw calls[2] which is more like X-forwarding.
It also hooks into the stack at a lower layer than VNC and friends so when sending bitmap block updates it has the dirty area information directly available, and doesn't have to do a frame-by-frame delta to recover that information. This is a huge CPU hog from my experience when I did some work on the FreeRDP server component years ago.
It also supports using UDP[3] with forward error correction to improve performance over WANs.
[1]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
[2]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
[3]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
While that is the most basic thing RDP allows for[1], it also supports sending GDI draw calls[2] which is more like X-forwarding.
It also hooks into the stack at a lower layer than VNC and friends so when sending bitmap block updates it has the dirty area information directly available, and doesn't have to do a frame-by-frame delta to recover that information. This is a huge CPU hog from my experience when I did some work on the FreeRDP server component years ago.
It also supports using UDP[3] with forward error correction to improve performance over WANs.
[1]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
[2]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
[3]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
Aha I had no idea it worked like that, with the GDI calls. That makes sense. There is definitely a performance advantage I've seen that's not matched when you run RDP on Linux. I assumed this was because of implementation issues but of course Linux doesn't use GDI so this makes sense, so it has to revert to block pushing. Thanks for pointing it out.
Are you sure on that first statement? I always thought it was akin to 'X' in that it simplified the connection based on an understanding of the windowing system. I guess I could have just made that up though.
No, I was wrong.. I've looked at the code of a Linux RDP server before (to identify an issue), and it was block pushing so I assumed this was also the case on Windows. But magicalhippo above corrected me. I didn't know about the GDI calls thing.
> I've even used it over a 9600 baud dialup connection (a long time ago from a 2G mobile that didn't have GPRS) and it was usable to my suprise.
Yeah, you can pretty much forget that with newer Windows versions.
Yeah, you can pretty much forget that with newer Windows versions.
You can tune down the graphical bells and whistles to make this work with newer versions as well.
Some discussion of this downthread:
https://news.ycombinator.com/item?id=30694601
https://news.ycombinator.com/item?id=30694601
apt install xrdp xorgxrdp will install the session manager and the Xorg modules to do that.
x2go is the best one so far.
Regarding remoting, I've found that running firefox through ssh -X makes sshd on the server max out the CPU and cause a very slow repaint. But eliminate ssh from the equation (use X11 forwarding without ssh, just let the remote firefox talk directly to your local X11 server) and firefox performance is indistinguishable from running it locally. Of course, for insecure network it's a bit of a hazard, but my usecase is forwarding a firefox instance running in a local virtual machine, so it's fine. Firefox over ssh -X brought me to the edge of sanity. I recommend trying direct X11 forwarding if someone has a similar problem and usecase (security-wise).
Obviously it depends on your use case whether this is useful, but I recommend just using your local Firefox and configuring it to tunnel connections over the SSH connection as a SOCKS proxy using "ssh -D".
Maybe you have compression enabled by default in SSH?
No changing of compression settings affected the issue in any way.
In my experience, remote desktop solutions that use hardware accelerated encoding (Parsec, Nvidia GameStream, Steam Remote Play) are virtually indistinguishable from a local session when using wired Gigabit Ethernet. Even over the internet, the delay is only really noticeable in fast games. Would be great if RDP or VNC could catch up with this technology.
Speaking of this, I make a shameless plug.
I'm a contributor for the Sunshine project: https://github.com/SunshineStream/Sunshine project, which allows Nvidia GameStream to be used on Linux systems with Moonlight clients. I haven't tested the Linux side of things, but it has many ways to both encode the screen or acquire it (via KMS, Pipewire or x11grab IIRC).
I'm a contributor for the Sunshine project: https://github.com/SunshineStream/Sunshine project, which allows Nvidia GameStream to be used on Linux systems with Moonlight clients. I haven't tested the Linux side of things, but it has many ways to both encode the screen or acquire it (via KMS, Pipewire or x11grab IIRC).
RDP at least is probably vastly more efficient as it doesn't encode the entire screen as a video every frame. This is what gives it the flexibility to have the remote display resolution and DPI be independent of the local settings, for one. It's actually quite sophisticated, unlike VNC and its ilk, but it isn't optimized for gaming.
Not true anymore. RDP encodes the entire desktop as it is more efficient than relaying the draw commands. You will notice compression artifacts on a poor network connection as RDP reduces the bitrate to compensate.
Gnome-remote-desktop in Gnome 42 (to be released soon) uses NVENC for H.264 encoding, if available. Of course, the client must support that too (many do, if the user left everything at 'auto').
I would love for Parsec to support Linux as servers.
Try out Sunshine as mentioned in https://news.ycombinator.com/item?id=30697718
Don't have direct experience with Sunshine but my moonlight experience in general was great
Don't have direct experience with Sunshine but my moonlight experience in general was great
There's also FreeRDP (xfreerdp/wlfreerdp) and rdesktop. Looks like all of the ones in the article (Vinagre, Remmina, Boxes) use libfreerdp as a backend.
I was very happy with xfreerdp on Debian 10, but something on Debian 11 is making it crash/disconnect from my work computer every so often. Haven't yet figured out what it is.
I was very happy with xfreerdp on Debian 10, but something on Debian 11 is making it crash/disconnect from my work computer every so often. Haven't yet figured out what it is.
rdesktop lost its maintainer[1] 2 years ago, and it looks like it just recently started having activity[2] again.
I run xfreerdp nightly builds for everything, and I rarely have issues, might be worth looking into for your crashing issue.
[1] https://groups.google.com/g/rdesktop-announce/c/AddglSNxK90
[2] https://github.com/rdesktop/rdesktop/commits/master
I run xfreerdp nightly builds for everything, and I rarely have issues, might be worth looking into for your crashing issue.
[1] https://groups.google.com/g/rdesktop-announce/c/AddglSNxK90
[2] https://github.com/rdesktop/rdesktop/commits/master
Give this one a shot: https://apps.kde.org/krdc/
I've been pleasantly impressed coming from Remmina
I've been pleasantly impressed coming from Remmina
Krdc doesn't scale RDP connections strange enough. So I can't zoom a 1920x1080 remote to my 4k screen :(
Very weird because it can do it just fine when it's using the VNC protocol. Never understood why the same app can't do it when it's RDP.
Other than this it's great (like most apps from the KDE world) but I really need the scaling. 1:1 scaling is just too small on 4k 24". I really need to zoom it in.
PS I use it on FreeBSD, never tried it on Linux so perhaps that's the reason but I doubt it.
Very weird because it can do it just fine when it's using the VNC protocol. Never understood why the same app can't do it when it's RDP.
Other than this it's great (like most apps from the KDE world) but I really need the scaling. 1:1 scaling is just too small on 4k 24". I really need to zoom it in.
PS I use it on FreeBSD, never tried it on Linux so perhaps that's the reason but I doubt it.
last time I tried a few months ago, It simply crashed on my wayland kde fedora machine. I wonder if they've fixed that issue for me.
On openSUSE Tumbleweed, Wayland now works with the package `freerdp-wayland`, but integration is not complete (some resolution scaling doesn't work, the viewer window doesn't dock in KRDC like it does with X11).
I tried krdc, but it's messed up in the Wayland session. I tried the more barebones freerdp directly and it works fine.
This is what I use on Manjaro and it works well.
Another vote for krdc, works great for me.
I’m surprised no one’s mentioned bare rdesktop.
I also find this amushing.
Almost 15+ years ago i contributing some code to rdesktop linked to libsvga
Almost 15+ years ago i contributing some code to rdesktop linked to libsvga
It seems TeamViewer and Anydesk also work on Debian. Has anyone any thoughts on these commercial solutions? (They both have free versions)
I've been using a paid Teamviewer license to manage a fleet of Raspberry Pi 3b+ (50+ devices installed, 50+ incoming), doing some monitoring behind either a 3G/4G router or behind a firewalled enterprise NAT.
So far, it has been the most reliable way to connect. I've tried multiple VNC and RDP clients, and when dealing with "hidden behind a network" systems, Teamviewer works very well, with little to no overhead. Specially since they have an special client for RPi monitoring, which works fantastic in my opinion.
If you don't have the option to pay for those licenses (which I did for several months), and no direct SSH access is possible to the machines, you can setup a cloud gateway SSH server or a VPN network.
So far, it has been the most reliable way to connect. I've tried multiple VNC and RDP clients, and when dealing with "hidden behind a network" systems, Teamviewer works very well, with little to no overhead. Specially since they have an special client for RPi monitoring, which works fantastic in my opinion.
If you don't have the option to pay for those licenses (which I did for several months), and no direct SSH access is possible to the machines, you can setup a cloud gateway SSH server or a VPN network.
TeamViewer at least is basically just a commercial wrapper over a slightly enhanced (Ultra) VNC.
Which makes it great for remote support sessions, but I wouldn't use it for the same purposes as RDP.
Which makes it great for remote support sessions, but I wouldn't use it for the same purposes as RDP.
I don't care much for TeamViewer, largely because you can't just install the "viewer" and also have to install the client. It doesn't work on Wayland either.
Before you start setting up connections, it insists on you making an account, which also sucks.
The good news is that it's an easy install (they supply a .deb). Even better news is that uninstalling it is just as fast.
Not sure about Anydesk.
Before you start setting up connections, it insists on you making an account, which also sucks.
The good news is that it's an easy install (they supply a .deb). Even better news is that uninstalling it is just as fast.
Not sure about Anydesk.
Just tried AnyDesk.
It's crippled without creating an account (fair enough I guess), also has the annoying feature of installing the AnyDesk server software like TeamViewer.
It does share the great feature with TeamViewer that it can be uninstalled quickly.
It's crippled without creating an account (fair enough I guess), also has the annoying feature of installing the AnyDesk server software like TeamViewer.
It does share the great feature with TeamViewer that it can be uninstalled quickly.
[deleted]
though it wont work for the author's usecase, if anyone is looking for a good remote X11 solution, take a look at xpra.
freerdp is a good option. Works well both with X11 and Wayland.
https://tracker.debian.org/pkg/freerdp2
https://tracker.debian.org/pkg/freerdp2
What's a good RDP Server on Linux?
As far as I'm aware there are no good RDP servers on Linux.
By good I mean one that would give an experience at least somewhat close to RDP on Windows. All the ones I've tried have been orders of magnitude away.
A good one should also allow for a key RDP feature which is to seamlessly transition between physical and remote desktop sessions. Meaning, I log in to my desktop at home, I leave and log in via RDP and get the same desktop session, which I can again resume when I get back home.
This is either not possible or doesn't work well last time I tested xrdp and friends.
Of course, if things has changed in the last year or so, I'd be delighted to hear about it. A good RDP server for Linux is what's keeping me from transitioning away from Windows on my main machine.
By good I mean one that would give an experience at least somewhat close to RDP on Windows. All the ones I've tried have been orders of magnitude away.
A good one should also allow for a key RDP feature which is to seamlessly transition between physical and remote desktop sessions. Meaning, I log in to my desktop at home, I leave and log in via RDP and get the same desktop session, which I can again resume when I get back home.
This is either not possible or doesn't work well last time I tested xrdp and friends.
Of course, if things has changed in the last year or so, I'd be delighted to hear about it. A good RDP server for Linux is what's keeping me from transitioning away from Windows on my main machine.
> Meaning, I log in to my desktop at home, I leave and log in via RDP and get the same desktop session, which I can again resume when I get back home. This is either not possible or doesn't work well last time I tested xrdp and friends.
This works with x2go.
This works with x2go.
> This works with x2go.
Ah, I don't think I even got that far with x2go. Dismissed it due to performance.
But good to know!
Ah, I don't think I even got that far with x2go. Dismissed it due to performance.
But good to know!
Strange because x2go performs better than anything else. Though you have to set the "Connection" settings correctly for your use. Setting for too low a bandwidth is just as bad as too high. "WAN" with "256-jpeg" works pretty well for me.
> Strange because x2go performs better than anything else
If you mean better than anything else available on Linux, you're probably right.
The problem is that it's still an order or magnitude behind Windows-to-Windows RDP, which is my benchmark.
But thanks for reminding me, I'll give it another whirl.
If you mean better than anything else available on Linux, you're probably right.
The problem is that it's still an order or magnitude behind Windows-to-Windows RDP, which is my benchmark.
But thanks for reminding me, I'll give it another whirl.
A volunteer has programmed and glued all the pieces together for Gnome's session sharing using RDP: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues...
NoMachine has been the nicest option I've found. I've previously tried x2go and xrdp, and whilst they worked, I kept looking for something better until I found NoMachine.
Funny. NoMachine is exactly what I use right now. Decent functionality. Reputable company. Etc.
But, RDP's bandwidth efficiency on Windows is unbeatable AFAIK. I wish the Linux and macOS world had something like that.
But, RDP's bandwidth efficiency on Windows is unbeatable AFAIK. I wish the Linux and macOS world had something like that.
The best alternative I've found for macOS is Jump Desktop's Fluid protocol.
How does Jump Desktop Connect[0] compare? I hear really good things about it on macOS
[0] https://jumpdesktop.com/connect
[0] https://jumpdesktop.com/connect
Jump Desktop’s Fluid protocol is shockingly good- by far the best remote desktop solution I’ve ever found for macOS.
Can it be run independently OR does it depend on Jump Desktop's servers as a connection mediator?
You're probably aware of this, but once the connection has been mediated via the cloud, data will usually flow directly between client and server. But yes, to avoid this initial connection mediation, you'll need the "Cloudless Fluid Connections" from the Enterprise team plan[0]. I use the basic $35 single user macOS program which requires cloud mediation.
I don't like the forced cloud mediation either, but the protocol is just so much better, almost comically better, than NoMachine, RDP-over-macOS, VNC, X11-forwarding, Screen Sharing.app, etc.
[0] https://app.jumpdesktop.com/pricing
I don't like the forced cloud mediation either, but the protocol is just so much better, almost comically better, than NoMachine, RDP-over-macOS, VNC, X11-forwarding, Screen Sharing.app, etc.
[0] https://app.jumpdesktop.com/pricing
Thanks for this info.
I wish they did offer Cloudless in their regular version.
I wish they did offer Cloudless in their regular version.
[deleted]
Debian, Ubuntu and Fedora ship with packages for it: xrdp (the session manager) and xorgxrdp (the actual X server that speaks the RDP protocol). I’ve been using them for almost a decade, and even got remote audio working on Ubuntu:
https://github.com/rcarmo/ubuntu-xrdp
https://github.com/rcarmo/ubuntu-xrdp
Only one I know of is xrdp. It usually works.
Why is RDP so much better than VNC?
VNC handles the display as, essentially, just a stream of screenshots. RDP is actually quite sophisticated and has knowledge of a lot of the underlying windowing system information it can work with. It also treats the remote client as a completely separate display from the local, allowing it to have different resolution and DPI settings and even use multiple monitors appropriately. That's without even getting into that Windows can have multiple logged-in user sessions and RDP will correctly take over the right one regardless of who is using the local terminal and forward the running session instead of whatever happens to be on the attached monitor.
Basically, VNC is a cheap hack and RDP is a well thought-out remote graphical terminal.
Basically, VNC is a cheap hack and RDP is a well thought-out remote graphical terminal.
Thanks for the info!
I hate both Windows and VNC. Is there any solution for me on Linux with RDP level performance?
I hate both Windows and VNC. Is there any solution for me on Linux with RDP level performance?
To oversimplify a bit, VNC sends a sequence of images of the screen that are then painted. It optimises this pretty well - only sending the fragments of the screen that change, allowing translation of blocks (e.g. for window dragging), but it's a pretty simple way of transmitting screen information. That's also a good thing because it is completely agnostic to the UI and the client and server.
RDP has a much more complex set of window painting commands - instead of sending 'this block of image goes here' it sends 'draw a window here with this decoration'. It's much more complex but also more performant as a result.
RDP has a much more complex set of window painting commands - instead of sending 'this block of image goes here' it sends 'draw a window here with this decoration'. It's much more complex but also more performant as a result.
Thanks for the info!
I hate both Windows and VNC. Is there any solution for me on Linux with RDP level performance?
I hate both Windows and VNC. Is there any solution for me on Linux with RDP level performance?
[deleted]
# For client, I use:
- Remmina - https://remmina.org/
- Apache Guacamole (HTML5, browser based) - https://guacamole.apache.org/
# For server on Linux I use:
- X11: xrdp - for a KDE guide, see https://pilabor.com/blog/2021/05/remote-desktop-with-xrdp-an...
- Wayland / GNOME: Already integrated (alpha state, some caveats) - for a guide, see https://gitlab.gnome.org/-/snippets/1778 (read the comments first, there is some good additional info and I think someone has crafted a script)
# Further notes:
- RDP Server on Linux is very fiddly to get working reliable, while on X11 systems I found xrdp pretty straight forward - this link was pretty helpful: http://c-nergy.be/blog/?cat=79
- On modern GNOME systems the RDP server is already integrated, but there is a lot of missing stuff and I did not find a solution for a working RDP after reboot
- Remmina as RDP client is good, but it takes some fiddling, if you are using HiDPI
- Guacamole is not as good, but I use it as backup, which works in the browser