Just for funsies, I'll throw in the latest remote desktop that I have tried for Linux, the Sunshine server. It uses the Moonlight protocol, so you can use any NVIDIA GameStream client, like I have used Moonlight from f-droid to stream my PC to my Android phone. Clients exist for Windows and Linux too, and a lot of other platforms as well. Sharing the desktop works out of the box, just download the server, run it, very minimal config to set a password, pair it with a client, and then next time, you just need to run the server and connect with the pre-configured client.
It works by converting screen or windows's content to video. It's low latency by design, bandwidth is up to you, and sound also works by default.
Moonlight/Sunshine developer here, having all of these people praising the work done by us is a wonderful thing. We developers work very hard to make Sunshine faster, smoother and more powerful each day. So thank you!
Thanks so much for building it! My non gaming use case is scientific research, processing massive images and 3D renders coming off microscopes. You need high image quality, low latency, and often accelerated graphics, which VNC etc al are maximally bad at, but sunshine/moonlight let me run the GUI tools I need on a high performance cluster and access it from my laptop.
Thanks! It's definitely cool to be able to use my Raspberry Pi (running Kodi with the Moonshine addon) as a "dumb terminal" to stream from my gaming rig from the other side of the house onto my big ass living room TV :).
Thanks so much for all your hard work. Sunshine/Moonlight are _incredible_. I could never get Steam streaming working but S/M just worked flawlessly from the go. The quality is so good that I ended up selling my Steam Deck and playing everything on the desktop streaming to various Apple devices over S/M. Feels like magic.
Sunshine and Moonlight are as close to magic as I've ever felt for incredibly low-latency streaming. I used it a lot early in the pandemic to play games from my PC in a shared space in my home on a low spec laptop while I was sick with COVID.
Later, I tried it while traveling and was shocked at how well it worked over a pretty bad link and a VPN (Wireguard).
These sort of client/server game streaming systems are great modern alternatives to something like RDP. They take advantage of hardware accelerated h264 encoding to get fast video/audio transmission with fast input mapping.
To me these seem like more modern, simpler alternatives to older remote desktop protocols as they are designed around modern hardware and one of the most demanding use cases, gaming. Seems like an easy win to me. RDP does have more features, but they seem mostly for niche/side things.
This is especially true for Hyper-V VMs without network connectivity. The enhanced session is RDP over a local socket (I think), so copying and pasting files via RDP becomes the best way to move files between your host and VM.
And it's just one specific implementation of the RDP channel. You can also share drives and printers, or write your own custom stream virtual channels.
Thats broken in the sdl freerdp client (which is the one they recommend for wayland since they deprecated wlfreerdp). Its go8ng to be annoying for a while until sdl3 comes out and they code that bavk into the sdl client.
For Windows Server 2019 and newer, as well as Windows 10 and 11, Microsoft now provides their own OpenSSH server for Windows, which I found to be pretty easy to set up, personally.
Currently using sunshine/moonlight to play PC games on my M2 Mac at 4k 60fps and its been very solid cannot tell its remote over gigabit connection at 70 Mbps HVEC from Radeon card. Amazing tech for sure, only way to really game on Mac and can locate PC anywhere in house, right now in garage.
Still use RDP for work though its better suited to lower bandwidth higher latency text editing IMO plus copy paste etc.
How about pushing this stream to an OBS client? I've been looking for a multiple stations to single, local, hub streaming for some time now and other than terrible NDP implementations and RTSP middle man, there seems to be none that can support it all. Meanind low latency, high quality and not filling whole gigabit connection.
I recently tried to get remote desktop working on my KDE laptop with xrdp. Spent days trying to get it working properly with all the fixes and workarounds I've found online and yet it didn't even come close to how smooth it all works in Windows. In the end, I accepted defeat, depressed about the state of linux desktop even more.
That's great news. At the beginning of the year, I had to decide between Windows and Kubuntu for our company's remote desktop developers.
Windows RDP outperformed every Kubuntu option I tested by far. 2023 hasn't been the year of the Linux desktop (remote edition) for us. With these news, it seems 2024 might just be the year!
To me the more important point would be if it can connect to an existing session (like Windows can). AFAIK XRDP on all current major linux distros only work with X11 (not Wayland) and if you try to log in using an account that is already logged in locally, you get a black screen.
IIRC Gnome recently launched something the opposite, where you can only share the screen of an already logged-in session (but it does work with Wayland, but only on Gnome).
A built-in KDE Plasma RDP implementation would be a game-changer, especially if it worked with Wayland (I assume it will) and even more so if it could connect to both existing logged-in sessions and start a new session on demand, like Windows does out of the box.
Been using KDE Neon on a NUC as a second desktop for years and been loving it, but the complete lack of a usable remote desktop solution for it (I've tried them all, they all suck) has meant my main desktop stays on Windows.
With how Windows 11 is shaping up the future was looking rather depressing.
Love KDE! Thank you for the excellent work! The release of the abomination known as Windows 11 has really given a lot of people the opportunity to evaluate new, and better, things!
Last time I played with RDP on Linux it really just seemed to be a wrapper around {the equivalent of} a VNC connection - so even when it worked, it was nothing like the streaming experience when RDP'ing into a Windows machine. Not sure if things have improved since, or FreeRDP does things differently.
I had a quick glance through the FreeRDP site but didn't spot any immediate clues as to whether this is a true Windows-style optimised/streamed RDP implementation or a "we'll send you a constanst stream of compressed bitmap screenshots" VNC-style...
RDP on Windows is one of the few things I really miss from the Windows ecosystem. There is nothing on Mac or Linux that I've seen to date which comes even close to the near-instantanous experience of using a Windows machine over RDP.
You need to set sesman.ini to use Xrdp instead of the Xvnc back-end - that is a packaging issue in some distros. With the right gear you can do 60fps without any issues: https://taoofmac.com/space/blog/2022/10/23/1700
Hell yeah. I spent a lot of time on RDP (Working remotly on my work laptop).
Its great protocol, and over LAN its very very snappy, you can pretty much stream video via it but it will choke bandwidth like there is no tomorrow ;) (around 80Mbit 640x400@25)
Indeed, comparing it to Xserver, its much better. I use quite a lot Xserver on windows too, to render for example remote Firefox. It works pretty well, but not that good compared to RDP.
About 15 or maybe even 20(?) years ago I could RDP into a Windows server over a crappy mobile phone data connection connected to my laptop on a moving train and get stuff done. It is a phenomenal protocol, when implemented correctly!!
I too have gone down that rabbit hole with xrdp. I compiled a step-by-step guide that worked on an older version of Ubuntu but it broke with later versions and I gave up.
I can't speak for KDE, but modern versions of gnome+wayland have a built-in RDP server that "just works" (Settings, select Sharing, and enable Remote Desktop). It doesn't perform quite as well as windows RDP (a bit more lag) but is vastly superior to other options I've tried (VNC, NoMachine).
If you just need an RDP _client_ on Linux, Remmina is really solid.
Sarah from NoMachine here. Your comment is truly appreciated :-) We would be interested in hearing from you to learn how we can make it even better. Would you be willing to reach out to us so we can ask you some further questions? You can contact us via the Contact Us link in the footer of the website https://www.nomachine.com/contact-request. Thanks once again and keep nomachining!
NoMachine was the closest to Windows RDP that I could find, and I tried FreeRDP, xpra, x2go, various vnc flavours and forwarding X windows / sessions. It was a few years ago that I tested them so alternatives may have improved.
NoMachine is still snappy enough for my needs: primarily browser usage.
It does need the remote machine to be logged in, however, which can be annoying and is a differentiator from how Windows RDP works.
NoMachine seems the only one (that worked well?) I've tried a few years back that could be used to access remotely a local session and viceversa. Which is my use case.
Sadly the local session must be logged in, as you said. The black screen feature sometime would fail and any passer by would then be able to use the machine locally. Also if there was a problem with the connection or you forgot to disconnect remotely there was no way to take over the session locally. Complete dealbreaker for me
Sarah from NoMachine here. Would you be able to reach out to us so we can investigate the blank screen not working properly? I understand that you are not using NoMachine anymore, but it would be useful for us to know more details about your setup at the time. You can use the contact us link in the footer of our website. Thank you!
I've only really used it for a VM, and using it "locally" via the hypervisor console works fine - in fact, I can operate both at the same time (NoMachine plus hypervisor console view) and you can see actions on one occurring on the other (since it's using the same desktop).
I've never used xrdp but I've used Remmina (snap and also flatpak) without an issue. In fact and as a confession, it's what I use when working from home to connect to my work laptop and be able to work from my Linux desktop.
> I've been using Remmina now for several years. I love how it's integrated into Ubuntu by default and how I can access the multiple platforms I have to support in one application. I mostly use RDP and VNC (Ultra VNC).
Remmina is great but it's a client only, no server.
I use it for both RDP and VNC to my Windows desktop. The flatpak currently has a bug with audio over RDP so I've gone back to the version in my distro's packages.
Remmina is a client only, and when it works, it works great. Supports all the basic protocols and has a bunch of plugins (including Teamviewer!) for protocols that don't come with the program.
It used to have some weird bugs on Ubuntu though, making it crash after clicking the wrong buttons for some reason. That seems to have been corrected and now it just works. Make sure to use an up to date version, especially if you're on an older LTS machine.
I work out of a reminna session every day. I rdp into my windows work laptop from my linux desktop and use it all day. Works great. Audio and video passthrough working well enough that i can use my speakers and boom mic for meetings without getting echo.
I have i3wm configured to always launch my work rdp session in virtual desktop 10. Switching between work and personal desktops is instantaneous. 10x more convenient than the kvm and thunderbolt dock setups I’ve used before.
I did it on a Gnome desktop recently and had the opposite experience - it was really simple! There was (of course) one issue regarding profiles, but it was very easy to fix and it auto logs in from my saved credentials in the MacOS Remote Desktop client.
Same, with Gnome it worked amazingly well for me. I didn't even have to install anything since it's built in to Gnome (under Sharing -> Remote Desktop)
Just in case anyone uses NixOS, the following simple piece of code just works for me, and I spent no time setting up a new NixOS machine that enables remove desktop with RDP:
For similar reasons, I ended up using x11vnc as server, and Remmina as the client. Granted, it has been a few years since I last needed it, but this was what worked best, and mostly out of the box too.
One advantage of a remote desktop protocol over x11 forwarding is being able to keep the application(s) open and in the same state when you disconnect and connect from another machine or access the host machine.
I haven't really used xrdp, but I have used xpra and have been able to attach to running instances of applications that I left open on the host machine remotely (much like I can reattach to a screen or tmux session remotely).
exactly this. i cant get over why people need to reinvent the wheel again and again.
i dont get why there isnt SPICE implementation outside of libvirt. because, thats even better. i mean - usb redirection, sound, (possibly even 3d accel)...
and suggesting doubt-ware like anydesk or even worse - teamviewer...
okay, these last ones make sense in some situations.
RDP / xRDP / Windows -> Linux is a complete shitshow. I forget this about every 14 months, try to get it working, get extremely mad, and just resign myself to using the completely awful VNC protocol.
Thanks for the suggestion. What do you use it for? Is it good for coding? Reading emails? I am in a position where I have to do student work from two computers and I would love to host this on my server and always work using it.
I haven't tried it yet, but I'm hopeful the experience is better than last time I tried Hyper-V enhanced linux experience. I imagine this use case is getting FreeRDP way more attention.
For years I've developed in a Linux VM on a Windows host via VirtualBox. The typing lag on this, particularly in IDEs like VSCode and Rider, finally got to me. So, I moved over to WSL and have to say; the experience is amazing.
Edit: I should say that I haven't used the WSL GUI functionality yet. Been using VSCode's WSL support and it's been amazingly seamless so far. I get native Windows VSCode performance while my project and all its plugins are actually running in the Hyper-V backed WSL linux VM.
VSCode remote also works equally well via "remote SSH" to your VirtualBox Setup. I still use the virtualbox setup because I feel it has advantages compared to WSL:
- I don't need to enable Hyper-V, which hijacks virtualization and disables other softwares (like VirtualBox) from using it. In fact, when you enable WSL/Hyper-V, your windows itself boots as a kind-of-VM from a Hyper-V root, so WSL is just an additional VM inside that cage.
- Services run normally, since it's a normal linux box. No need to "service docker start" on every WSL boot.
- Easier to image/snapshot/transfer to another box or even another operating system, as VirtualBox runs in other OSes.
And you get the same native VSCode experience. Try it out (VSCode+Remote SSH to Vbox), you'll enjoy just the same as VSCode+WSL
One tip that I have is: Set a secondary NIC in your VirtualBox VM to a 'host only network' and use 'virtio-net' instead of the default emulated Intel Pro1000 cards. Much better performance since it's essentially a virtual device with unbounded speed. With the virtio-net device, even remote X11 becomes a real possibility with windows apps like VcXsrv. I'm a Pycharm user (and Pycharm unfortunately has meager support for remote, where VSCode shines) and I use it graphically like this -- there's still some input lag tho, but it's quick enough for me.
There are other benefits to me and I'm not missing anything by moving to WSL.
VirtualBox still works if I need to access something off my old VMs, it's just dog slow for some reason using Hyper-V on my system.
I haven't needed to restart docker after booting WSL. Maybe I will, but hasn't happened yet.
The WSL vm feels much more performant to me. It supports dynamic memory allocation and in the new 2.0 release I believe it can free memory. This is really nice in general but particularly on laptops with less RAM.
Resource sharing seems.. Just easier. I like the default drive and network sharing. Both seem to work fast and I don't have to do anything with them..
I can still run multiple VMs if I need to with Hyper-V.
There is a level of integration that is pretty nice. I like typing "code ." in the WSL term and having it just launch VSCode in Windows and be connected. The WSLg system seems really nice for any software I might run that doesn't support remote hosts.
For me, it's all upsides and no real downsides to just running WSL.
RDP is definitely the better protocol (cached client side assets, hardware accelerated video compression), but I’ve always had trouble making it work.
For Linux, FreeBSD and OpenBSD hosts, and Unix / MacOS clients, I use tigervnc (be sure to also use their client). It’s the fastest vnc implementation I have seen, and reasonably trouble-free.
My main complaint is that the MacOS client hasn’t been updated for hidpi mode, so MacOS applies a gaussian blur to the session window. (Screen Sharing is the built in MacOS VNC client. It supports HiDPI, but the session immediately hangs when I use it.)
Honestly, WSL has got nothing over a VirtualBox VM using a virtio-net network device on it.
- Real VM you can snapshot and transfer to another computer running VirtualBox, even on another OS, as VBox supports other operating systems.
- With VcXsrv or Xorg on Cygwin, you'll get graphical apps just the same, and with the virtio-net network card on the VM (instead of Virtualbox's default Intel Pro1000 - my protip :D) you'll get enough speed to watch youtube on google chrome -- e.g.: More than sufficient speed for using an IDE like PyCharm etc
- With VSCode, you don't even need a X server. Just use "Remote - SSH" and connect to your VM and keep your local lower input lag - Works just the same as "Remote - WSL" as both essentially use the same mechanism - a remote connection to a Linux server.
- Services run automatically, as it's just a normal Linux install. No need to 'service docker start' on every WSL run
- Doesn't hijacks your Virtualization extensions, like with WSL, which need Hyper-V which actually boots your computer with a Hyper-V hypervisor and blocks nested virtualization, meaning, you can't use other virtualization technologies properly outside of Hyper-V if you use WSL*
* Btw, you also get a (small, but non-zero) performance hit on your Windows box by using WSL, even when it is not running, since now Hyper-V is what boots your system as the ring-0 guy. Yes, your Windows install basically becomes a "VM" hosted by Hyper-V.
Unpopular opinion: WSL is okay for getting work done quick, but there are better solutions with better tradeoffs in how you handle control of your PC's hardware if you do a good VirtualBox set up imo.
One nice thing about WSL: GPU "passthrough" (via GPU-PV) is handled out-of-the-box.
There are some solutions (such as https://github.com/jamesstringerparsec/Easy-GPU-PV) that makes the process easy if you are using Hyper-V as the hypervisor, but it is not a straightforward task yet. Hopefully that will change in the future!
>- Real VM you can snapshot and transfer to another computer running VirtualBox, even on another OS, as VBox supports other operating systems.
I just migrated my home setup to UnRAID. Among the things I was looking forward to was an improved VM experience; I had been happy with VirtualBox, but KVM in UnRAID is a "real Type 1 hypervisor" so had to be better, amirite fellas? Boy, was I shocked when I saw how poor the VM functionality is compared to VirtualBox.
(Yes, I know that UnRAID's GUI does not contain all the functionality `virsh` has (I've heard that the next major release will improve on this). None of that changes the fact that KVM snapshots don't survive beyond reboots, making it impossible to do what I took for granted from back in the VMware days: Rebooting the server and expecting that my VMs will gracefully and automatically save, restart, and continue on.)
Hyper-V is enough for most of us, no need for other virtualization technologies.
I also don't mind that type 1 hypervisors have won, and if one is doing any kind of local Docker or Kubernetes development, the tiny impact of running Windows as a guest hardly matters in the grand scheme of things.
Even though WSL hardly brings anything new over VMWare, much more feature rich than Virtual Box, it saves me the headache of being yet another thing I would care to install, or pay for.
You mention a small performance hit with wsl...It's brother WSA (android subsystem) hits super hard on Windows 11 for some reason.
I somewhat miss the kernel translation in favor of the new VM style for these like you mentioned since it's really a VM without some of the benefits like network management and clear cut performance boundaries
If someone is looking for a working RDP config, that can be used without manually logging in at the machine and that works completely remote, I would recommend using xrdp.
Problems I ran into:
- Black screen after login
- Permission issues / strange password prompts
- Login does not work if not logged in / having a HDMI connected
- Copy & Paste did not work
- Shift key led to caps lock /wrong keymapping on Remmina
Black screen after login is a GNOME problem, which is caused by trying to remote in as a user that is logged into the desktop already. I solved this by creating an additional user. It was intensely annoying.
It's not just a GNOME issue; it happens with KDE, and I think basically any common desktop environment (although my own experience over the past several years is mainly with those two).
There are workarounds, but they are "not recommended" for reasons I forget. (I don't mean the workaround of creating a separate user; that is the recommended "solution" but it doesn't solve the problem of "I need to log into this user's active session" which is probably about half of the total use cases for remote desktop in general.)
The "Permission issues / strange password prompts" is generally polkit (formerly PolicyKit), which annihilates the user experience when coming in over RDP; the famous c-energy script referenced in the parent solves a few of those issues, but not nearly all of them. You should expect errors when you try to adjust display properties, try to use any app that looks at disks/partitions, any app that does anything wrt Wi-Fi or Ethernet settings, any app that deals with VMs in any way, and like 357 other things. Each one can be solved by googling for 1-2 hours and then writing some arcane PolKit config file, but it ends up taking about as much time as designing and building a bear-proof suit of armor from scratch, and then testing it against several live bears.
Just curious, how do all the different alternatives compare. I know VNC iirc uses raw screenshots, and some implementations will do their best to only send the differences over the network. How do others compare in approach? I almost always reach for VNC because I'm already familiar with it.
Windows RDP is a much better experience than basically everything else, it's not diffing a big jpeg of the screen like almost everything else does it sends more primitives to do more compositing on the client end. If the latency is low you often can't tell you're remote. You can actually work on it all day rather than just for doing odd bits of tech support. Plus it maps printers, audio etc.
+1 for Windows RDP. One thing Windows RDP excels at is working over low bandwidth connections. My remote desktop is in a rural area with very poor internet service -- uploads under 1 Mb/sec. With Win RDP I set the "Experience" to "56k Modem" (not joking) and it eliminates eye candy stuff like font smoothing and window animations, which is fine, at least I have a steady connection that works. I've tried other RDP programs and they always say "connection lost" due to insufficient bandwidth.
For VMs, I find RDP to be on par with SPICE (which is more of a qemu/libvirt thing). Both have support for device/drive mapping, I believe. That's both over ssh sessions (I know RDP has encryption, but I'd rather not trust it).
RDP itself in its earliest versions is just a windows GDI async RPC. Which is why its so fantastically fast/responsive on windows. And as of last time I mess with this, thats the way it still behaves for things like MS office, and basically anything that is older than a half dozen years or so, because they are still sitting on the win32 GDI.
But, yes your right if you have a "modern" application that is basically doing all the drawing on the CPU to a generic canvas with custom libraries none of that works, and RDP has to fall back to diffing and compressing. Which is really terrible on any number of fronts.
At that point you might as well just use VNC because the perf is going to be roughly the same.
I wrote a man-in-the-middle recording for RDP way back when. We did recording for both, RDP is much more sophisticated.
Besides using a TLS style encryption (VNC at the time had none). RDP tries as hard as possible to not just send bitmaps. It first shares what fonts it wants to use, then a cache of bitmaps from the previous session (for the wallpaper for example). When Windows move it doesn't send bitmap updates, it sends window updates and tells the client to paint a rect, then draw fonts, etc..
That said, it's a bear of a protocol with countless versions and "speed mode" hacks that bypass the layered protocol setup, tons of weird features, etc..
Interesting, is there software that still records RDP sessions? I'm not sure if Teams uses RDP or what, but I know it lets you record a call, whether there's screensharing or not.
RDP is a crazy complex protocol, and you have options for pretty much everything.
On the graphics side, you can send over draw commands "draw the letter A here using this font", or you can send opengl calls, or you can send dumb bitmap updates. You can get the other end of the connection to do compositing ("blur this buffer and overlay it over that buffer with 50% transparency").
You can also get the remote end of the connection to decode videos - so when you hit play on an MP4 video inside an RDP connection, the actual video decoding gets done on the client not the server.
RFB (the protocol used for VNC) implements at its base level rectangle-based updates which can be used to send over just rectangle-bound differences between frames. It's just that some shoddy server implementations send over the entire screen at once without damagerect tracking.
I've long been a huge fan of Xpra https://github.com/Xpra-org/xpra , both because of its "screen for X" original focus (though now it supports shadowing an existing session).
There was NoMachine / nx / freenx but it always seemed to be a weird animal to me, requiring installation as a separate unix user, at least at the time.
Windows has a special rendering mode for applications when RDP is being used to optimise the connection by redrawing as little as possible. It has the ability to dynamically switch between crisp, pixel accurate forward-chunked-GDI-draw-calls mode to a connection speed based compression level of an H.264/H.265 stream. There are also a bunch of extensions related to GPU acceleration.
If you use RDP on a Windows server with a consumer GPU, you van hack the Nvidia driver to make more NVENC streams available (they're capped in software) to run more RDP heads without overhead.
RDP also does sound forwarding, local drive forwarding, printer forwarding, and USB device forwarding (up to a point). It also supports a wide range of security features and authentication as security requirements have increased over the years, and has built-in support for bastion hosts/gateways.
One very interesting feature is the ability to RDP only specific applications rather than the desktop. Cassowary will let you "use Windows applications" by using a Windows VM and using RDP to run the applications on Linux as if they were running locally (Cassowary also automatically suspends the VM which is what sets it apart). It's a bit like X11 forwarding, except your local files and drives available without extra commands to set up reverse SSHFS mounts.
VNC is to RDP what telnet is to HTTP/3. The underlying concepts are the same, but the implementations have very different feature sets and advancements. Does VNC even support passwords longer than right characters yet? Last time I checked, VNC servers still truncated your password.
Being proprietary, RDP support on Linux is very limited in comparison. RDP clients like Remmina support a surprising amount of features, but on the server side things aren't as compatible. For example, connecting to xrdp works great from desktop clients, but the Microsoft client on Android is slow as hell.
I've also experienced buggy behaviour on Gnome when FreeRDP tries to render window borders in app mode. Window borders don't get drawn right and clicks seem to be shifted by it for some reason.
I don't blame the FreeRDP/xrdp developers for any bugs or problems because RDP is a terribly complex protocol with tons of features, but sadly Linux doesn't seem to have an implementation or alternative that compares to Windows and RDP together.
> VNC is to RDP what telnet is to HTTP/3. The underlying concepts are the same, but the implementations have very different feature sets and advancements.
I don't know a lot about http3. This comparison does not make a lot of sense to me with regards to http2. What changes have been made in http3 to make it conceptually close to telnet?
You set up a connection between two servers and exchange text. HTTP/3 does a boatload more than telnet, but in its core it's just sending text back and forth with some optional special tricks.
VNC and RDP both solve "log in to a remote computer", but RDP does a lot more than just sending images one way and sending HID input the other way.
VNC is dog-slow compared to RDP. RDP is slow compared to xpra. What xpra does is sending a h.264 video stream (some other compression algos are also available). Also, xpra can forward the whole desktop as well as single applications. Far preferable to any kind of RDP server.
However, the xpra client is somewhat strange and inconsistent when it comes to CLI/UI behaviour.
RDP will also send a video stream depending on what's happening on screen. It'll try to detect the appropriate transfer mechanism as chunked screen updates increase and decrease in frequency, assuming both sides support the necessary protocol versions.
Video streams can be a real issue if you're working over a slow connection, especially when your application is using small text. RDP will handle remote GUIs much better, as low bitrates tend to make text unreadable.
Of course RDP also supports streaming individual applications.
Personally, I think RDP is undefeated at what it was designed for: controlling desktop GUI applications. On Linux, that's not the case, though, and xpra will provide a very good alternative.
However, I find very few good xpra clients outside of Linux distros. For example, when I look for xpra in Google Play, the first three options are Microsoft's RDP client, two X11 servers, and RealVNC. F-Droid lists nothing at all. I suppose u could try the HTML5 client but it's kind of a bummer. The situation seems to be the exact inverse of RDP: very good Linux server, difficult to use Windows clients on all other platforms.
It would be helpful if it was specified prominently anywhere whether this was a client, a server, or both. I've been looking at the screenshots to try to make an educated guess.
We've been using X2go for a couple of employees to access their work machines (Windows) from home, but it hasn't been a fun experience. Excessively fiddly to configure and often doesn't work and hard to trouble-shoot. Haven't been able to get new people configured and working.
Recently found Mobixterm which allows you to setup RDP running through an SSH tunnel. This looks to be the winner for us.
I'll probably still use X2go while it still works for me as I'm running Linux at home, but as soon as it get's too tricky I'm going to replace it with a script that fires up the SSH tunnel and uses Freerdp.
AFAIK, FreeRDP is largely what is underneath most of the iOS/Android/etc RDP clients. Largely because rdesktop which preceded it is GPL licensed. Which focused a lot of commercial development to create an alternative, and hence freeRDP. Which also did a better job of not being as tightly integrated with X11 as rdesktop is/was because a lot of the windows GDI API has corresponding X11 functionality, so if the function is an Xored Blit operation, or a hatched pen fill, then rdesktop just offloadeds to X11 and presumably the graphics card rather than being software rendered.
Am I the only person here that has found FreeRDP to be really good? I used to use it a lot in my previous job. I never had a compat issue, the distro-packaged version worked fine, performance was perfect, it even had less bugs than the Windows RDP client (like weird tray balloon z-order stuff).
Perhaps you are all using some frontend to it and that adds issues? Not sure. I ran it on the commandline.
My only serious complaint is lack of printer passthrough. That's it.
I discovered something utterly bizarre with vanilla RDP the other week: connecting to a machine with an optical reader which also has a CD in it? More or less renders playback of that CD useless. And will until that machine is rebooted! Apparently, this is by design. Just in case you wanted to remote into some machine and listen to a CD on that machine.
What the hell.
Anyway, that sent me on a search for a replacement.
assuming that you have a potentially compromised linux host (or VM)
what level of client-side risk are you taking connecting a freeRDP client to that host ?
(i'm not worried about the case of the client infecting the host)
what is the most secure similar application ?
i prefer a linux client, though would be willing to consider windows if there was a client that was significantly more secure
I'm also curious about this; I don't know how secure the traditional native clients are (FreeRDP, Vinagre, Remmina, etc.).
On the other hand, there are browser-based clients such as Apache Guacamole and noVNC, which are protected by the browser's security sandbox. They require a server component, but that can be run in a sandbox or on the untrusted server. There are some limitations to running in a browser (e.g. some keyboard shortcuts might not be forwarded).
It works great! I use it for RDP, VNC, and SSH sessions for business users. Can hook it up to LDAP, manage users and groups. If the user's profile only has one connection configured, it automatically dumps them into it when they log in, so there's no learning curve at all, save hotkeys if they want to do something fancy.
I went through all the major platforms, and settled with something less enterprise-ey.
Windows Remote Desktop Services (RDS) gateway requires a lot of configuration across several services, but the overall experience is pretty good.
I used Kasm for a bit, but the integration with AzureAD authentication was flaky. It’s a pretty god platform overall though.
Guacamole is mature, but by Jove it’s a fickle thing to configure.
Now I just use a Remmina docker container, which is maintained by Kasm. I have a separate container to route a reverse proxy through to CloudFlare, which uses Azure AD for authentication. Now just go to rep.domain.com, login with AAD creds, and i’m presented with a basic remmina jump host where I can log into whatever VM or host.
It sounds janky, but it’s much more stable and much leas demanding from the administration side of things. It also works over HTTPS port 443, so it (usually) just works on guest wifi.
CloudFlare can also render VNC in the browser, but I didn’t find the experience great, and it just seemed wrong.
Note that using FreeRDP (directly or via a client like Remmina) can be a great option for accessing a Windows virtual machine on KVM/libvirt, as it often performs a lot better than SPICE but supports much of the same features (remote audio, USB and serial port forwarding, etc.)
Recently, somebody had asked me to automate the build process of FreeRDP for Windows x64 via GitHub Actions.
Spent almost 2 full days making it work.
That guy seems to have ghosted me.
Anybody wants it? mail: hello [at] amo [dot] fyi
Are any of the RDP style systems rootless? That’s one of the things I enjoy about X is simply firing up an app on a remote server and there it is like any other window without all the desktop that I mostly don’t care about.
I use NoMachine for remote desktop across all 3 platforms (the client runs on Android too). Works out of the box with zero configuration needed. Even supports copy/paste.
It works by converting screen or windows's content to video. It's low latency by design, bandwidth is up to you, and sound also works by default.
https://github.com/LizardByte/Sunshine
https://f-droid.org/packages/com.limelight/