15 ms·

This is very cool. I still think MS RDP is the best remote desktop client and protocol. The performance is just insanely good, and the client is easily availabl

by kayson 2y ago

This is very cool. I still think MS RDP is the best remote desktop client and protocol. The performance is just insanely good, and the client is easily available on 95% of computers. The multi-monitor support is also awesome. The only downside is that it's Microsoft...

DaiPlusPlus 2y ago
> The performance is just insanely good, It's still artificially capped to a really awkward framerate (maybe 24fps or ~32fps?), even today.
- rcarmo 2y ago
  You can set that to 60fps - https://taoofmac.com/space/protocols/rdp https://taoofmac.com/space/protocols/rdp
  - DaiPlusPlus 2y ago
    That article instructs readers to use H.264 rendering and to set DWMFRAMEINTERVAL - thing is, DWMFRAMEINTERVAL is a host-side parameter and apparently all it does is set an upper-limit on the possible refresh rate [1], rather than force the entire RDP system (client and server) to run at a specific frane-rate. This also conflicts with a personal experience of mine: possibly around 2007-2009 I remember using a FOSS RDP client meant for Linux but ported to Windows for some reason, and I preferred using it to connect to a shared WS2003 TermSrv box on the LAN because it sure felt like 60fps, despite everything else wrong with a barely-complete Win32 port (I don’t think they even used MINGW; mad lads…). It was my own TermSrv box and I know I didn’t do anything server-side to make it work so buttery-smooth. …which tells me that the compromised user-experience caused by the artificially capped frane-rate of the RDP session is entirely at the direction of the client, not the server. But that was… 15+ years ago (…fuck), it’s possible the protocol has changed and maybe it’s something both host and client negotiate, but clearly its possible and clearly someone in the Windows Server group at MSFT enjoys cinema too much because they seem to think 24fps is good enough for everyone. Also, when you use H.264 in RDP, it defaults to 4:2:0 chroma subsampling[2] which is going to ruin fine-details and make text ugly if not unreadable - there’s a reason we use H.264 for movies but not text documents. I remember around 2013 when a bunch of competing remote-access companies all launched hardware-accelerated-video-based remote-desktop products and being impressed with how they handle remote-Netflix over a pre-LTE mobile tether, but reeling and gasping to throw-up after their aggressive codec motion-estimation, subsampling, and YUV colorspace absolutely butchered a 100% zoom Word document with ClearType enabled. Using the system instilled oneself with a strong discipline against ever moving or resizing a window on the desktop, lest the smears of low-bitrate macroblocks start to appear, warning you the text-on-screen is about to become painfully unreadable for the next few seconds while you curse the DSL connection you’re still forced to use because your apartment complex’s HOA got a sweet deal on satellite TV from the incumbent telco by blocking the local cableco, with their sweet sweet DOCSIS 4, from adding service to the building and I’m done. [1] https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/frame-rate-limited-to-30-fps#setting-frame-rates https://learn.microsoft.com/en-us/troubleshoot/windows-serve... [2] https://learn.microsoft.com/en-us/azure/virtual-desktop/graphics-encoding#chroma-subsampling-support-for-420-and-444 https://learn.microsoft.com/en-us/azure/virtual-desktop/grap...
sitkack 2y ago
And they claim patent protection on it. You have to buy a license for Microsoft.
- IcyWindows 2y ago
  Still?
  - tracker1 2y ago
    The main protocol should be well outside patent protection, but some of the extensions (RemoteFX, audio support, etc) may still be covered, would have to double-check. Likely fine. I would like to see something as capable make its way into Linux and Mac that's as ubiquitous. RDP tends to work better than the VNC options most other solutions are using under the hood.
    - bee_rider 2y ago
      I’m really baffled as to why anybody would downvote this comment, anyone want to explain?
    - iforgotpassword 2y ago
      How about spice? I don't know anything about the technical details, but it seems to offer most of the advanced features like usb redirect and I think currently gets video support. It's currently really only used in qemu but I don't see a reason why you can't use it as a general open rdp alternative.
    - inversetelecine 2y ago
      Gnome and KDE both support RDP in recent releases. Works ok, but connecting is not as seamless as Windows, at least with mstsc.exe. I’ve found it somewhat buggy too (blank or black screens until rebooted for example.) One of the big things holding me back was good Remote Desktop experience on Linux. Using Gnome RDP has been good enough for basic use for me.
      - 2y ago
qsort 2y ago
It's very good at being a remote _desktop_ protocol, but the fact that it lacks features like tunneling and that authentication is the usual MS mess makes me wish they just went with SSH as transport protocol.
- tomjakubowski 2y ago
  Windows does support SSH now, so maybe you could rig RDP-over-SSH yourself with port forwarding.
  - p_ing 2y ago
    RD Gateway leverages SSL for encrypted transport for RDP between client and host. Maybe it is possible :-)
    - chupasaurus 2y ago
      RD Gateway has nothing to do with tunneling, it's just a reverse proxy for RDP connections. Funny note: as you've mentioned in other comment, my guess is that RDG was also licensed from Citrix but at the later point.
  - awakecoding 2y ago
    RDP-over-SSH will break Kerberos authentication for two reasons: 1) you'll point the RDP client to localhost and a random port and 2) you won't get a KDC line-of-sight. The irony is Microsoft has demoed this with SSH over Azure Arc, which can only result in an NTLM downgrade. IronRDP is designed to work with Devolutions Gateway (https://github.com/Devolutions/devolutions-gateway https://github.com/Devolutions/devolutions-gateway) for just-in-time RDP connections made from the web or through the desktop client. Devolutions Gateway also supports just-in-time KDC proxying alongside the main RDP connection, making Kerberos possible. You can install the free standalone web access package of Devolutions Gateway to try it out, it will give you a simple web interface where you can enter the hostname, username and password. But if you really want the simplest solution, it's with the rest of the Devolutions stack with Remote Desktop Manager and Devolutions Server. In the end, you'll be able to make RDP connections from RDM or through the web with just a double-click, and it'll automatically generate short-lived tokens and make RDP + Kerberos work seamlessly: https://devolutions.net/gateway/ https://devolutions.net/gateway/
SirMaster 2y ago
I feel like a more modern approach like whatever RustDesk uses is way better. It has such good performance that I can practically play an FPS video game through it or watch a movie through it. The big thing I hate about regular Microsoft RDP is you aren't getting to use your remote GPU through it.
- raggles 2y ago
  > you aren't getting to use your remote GPU through it. Um yes you are? I use AutoCAD and other software using GPU all the time over rdp
  - vekatimest 2y ago
    I've had issues with some software & games not being able to get a proper display context and refusing to start.
    - raggles 2y ago
      Yes I have seen OpenGL applications refuse to start with AMD cards in some circumstances due to a bug in the AMD drivers, but never had a problem on NVIDIA cards
- jeroenhd 2y ago
  RDP GPU acceleration should be available (on Windows, at least) with the right quality settings. AFAIK nothing API-wise prevents GPU software from running. That said, RDP is an edge case few software developers bother testing so I'm sure there are lots of programs out there that ignore edge cases when it comes to rendering APIs. It's not optimised for games, though. Something like Parsec would be much better for interactive stuff like that, or maybe something like Moonlight for Nvidia cards if you're looking to go without closed source software.
  - SirMaster 2y ago
    I know it's not made for games, but the thing is I am seeing Parsec-level performance and quality from RustDesk which why I am liking it so much. With modern hardware with RustDesk you are getting HEVC or even AV1 hardware encoded high framerate stream of your desktop. I have never seen this kind of performance through MS RDP personally.
wkat4242 2y ago
It's usually pretty good on windows because it does a lot of local drawing but most Linux servers don't support that and use it just as a dumb blockpusher like VNC :(
aappleby 2y ago
If you think RDP performance is good, you should try Sunshine+Moonlight. I regularly stream at 4k 120hz from my gaming PC to my laptop and it's basically indistinguishable from running locally. I've even run it over Tailscale from a thousand miles away (though at 1080p60) and it was still markedly better than RDP. Caveats - You really want a Windows host for fully accelerated on-GPU hardware video encoding, the server setup is _slightly_ more involved than RDP which is usually preinstalled, and Sunshine+Linux+NVidia requires an annoying driver patch. But overall it's _amazing_.
- winkelmann 2y ago
  I'd still pick RDP for remote managing any day, its server and client are so much better integrated (clipboard, peripherals, etc.) for this task than Sunshine/Moonlight. It also avoids the whole issue of setting up a virtual display output[1] as is required by Sunshine. I use both for different tasks. On a related note, as of recent versions, Sunshine and Moonlight stable releases support 4:4:4 chroma subsampling and bitrates up to 500Mbit/s with HEVC, which results in almost indistinguishable image quality compared to native output[2]. Bitrates that high are unusual in normal content, but at least Apple's Media Engine (on M-series Macs) appears to be capable of decoding it. [1] Here is a pretty good solution that piggybacks off of Parsec's driver, which is fully signed, though its EDID lacks HDR support. The project also includes a C header file for custom implementations: https://github.com/nomi-san/parsec-vdd https://github.com/nomi-san/parsec-vdd [2] Note: I found that I had to enable 10-bit color streaming (which is available when using Parsec's driver) to get rid of some gradient banding that isn't present in native 8-bit. I suspect it's some encoder and/or color space issue.
  - wtallis 2y ago
    I wonder how Apple's ProRes would work for remote desktop over wired networks, especially now that consumer equipment is starting to move beyond 1GbE. They have hardware encode and decode on everything newer than the original M1, and ProRes only does intra-frame compression so a fairly low-latency implementation should be possible.
- gryn 2y ago
cryptonector 2y ago
Anytime there's a timeout the Microsoft RDP client makes you wait way longer than you might have had to otherwise. That kills me.
- inversetelecine 2y ago
  Yeah. I usually just close the client and reconnect that way instead of waiting for it to auto reconnect.
singhrac 2y ago
It is really nice, I'm very sad that Apple's RDP implementations seem fragmented and difficult to use. I've tried a few times with my Mac Mini, and it just doesn't seem to work that well.
- naikrovek 2y ago
  They use simple VNC but with some special “applesauce” that makes every non-Mac client I have ever tried break after a minute or so. But, on a mac, when you “screen share” into another Mac (this is what they call it for some reason; you “screen share into” the remote) it is flawless and quite snappy.
  - awakecoding 2y ago
    If you want to connect to the built-in macOS remote desktop server, don't use a standard VNC client, use a real ARD client like Remote Desktop Manager. While the server accepts standard VNC, you will only get zlib the codec, which has very poor performance. With ARD, you get a special codec inspired by progressive JPEG, along with server-side downscaling and chroma subsampling, etc. It's actually closer to RDP RemoteFX in terms of performance: https://devolutions.net/integration-center/apple-remote-desktop/ https://devolutions.net/integration-center/apple-remote-desk...
EthanHeilman 2y ago
At Cloudflare we used IronRDP to build our Cloudflare Access RDP product [0] and scale RDP access across our edge using workers. I can't say enough good things about the IronRDP project. I didn't write the RDP code deployed in Cloudflare Access, but I did some of the prototyping with IronRDP. * IronRDP code was excellent, thoughtful and well designed. * The IronRDP project was friendly, responsive and helpful. They answered some pretty obscure RDP questions I had. I would recommend anyone doing RDP protocol work to use the IronRDP project. *edit:* I didn't even realize it until someone pointed it out but our blog post on Cloudflare using IronRDP went live today. [0]: RDP without the risk: Cloudflare's browser-based solution for secure third-party access https://blog.cloudflare.com/browser-based-rdp/ https://blog.cloudflare.com/browser-based-rdp/
- vfclists 2y ago
  Can IronRDP work with HTML5? I find myself using Guacamole because a lot of firewalls block WebSockets or the admins block WebSockets in their browsers.
bob1029 2y ago
I got so used to working in RDP that I can't really process the difference for non-gaming use cases. At the end of every day on my personal machine, I will inevitably mouse up to the top-middle of my screen and realize I am not inside some W365 instance.
teleforce 2y ago
If I recall correctly one of the main reasons replacing X windows with Wayland is so that we can similar performance of remote desktop for Linux as provided by RDP for Windows. Along that many commentaries on how lousy and ad hoc it was the Linux remote desktop solutions based on X windows unlike RDP and Wayland is touted as modern Linux desktop saviour. I'm wondering after many years now, what is is the state-of-the-art of Linux remote desktop status that now Wayland is the default Linux desktop windowing system for Linux, is it comparable to Windows RDP now or better? It will be good to have high performance remote desktop based on Rust or any strongly typed compiled language for Wayland. This can be a good showcase of Rust for Linux instead of the recent Linux kernel brouhaha.
tomjen3 2y ago
Agreed. Its not just that its better, it is also that most of the settings for Linux ends up not using the same desktop you would get if you were sitting in front of it. I still haven't found a solution for where I can login over the network and accessing the same session I would have gotten by sitting in front of the computer (including GPU acelleration). The guides are either for something like NoMachine that requires your screen to be on and often that you are logged in first, or they start a separate environment up using something like VNC. Meanwhile Remote Desktop, as you said, just works.

by kayson 2y ago

DaiPlusPlus 2y ago

> The performance is just insanely good, It's still artificially capped to a really awkward framerate (maybe 24fps or ~32fps?), even today.

rcarmo 2y ago
You can set that to 60fps - https://taoofmac.com/space/protocols/rdp https://taoofmac.com/space/protocols/rdp
- DaiPlusPlus 2y ago
  That article instructs readers to use H.264 rendering and to set DWMFRAMEINTERVAL - thing is, DWMFRAMEINTERVAL is a host-side parameter and apparently all it does is set an upper-limit on the possible refresh rate [1], rather than force the entire RDP system (client and server) to run at a specific frane-rate. This also conflicts with a personal experience of mine: possibly around 2007-2009 I remember using a FOSS RDP client meant for Linux but ported to Windows for some reason, and I preferred using it to connect to a shared WS2003 TermSrv box on the LAN because it sure felt like 60fps, despite everything else wrong with a barely-complete Win32 port (I don’t think they even used MINGW; mad lads…). It was my own TermSrv box and I know I didn’t do anything server-side to make it work so buttery-smooth. …which tells me that the compromised user-experience caused by the artificially capped frane-rate of the RDP session is entirely at the direction of the client, not the server. But that was… 15+ years ago (…fuck), it’s possible the protocol has changed and maybe it’s something both host and client negotiate, but clearly its possible and clearly someone in the Windows Server group at MSFT enjoys cinema too much because they seem to think 24fps is good enough for everyone. Also, when you use H.264 in RDP, it defaults to 4:2:0 chroma subsampling[2] which is going to ruin fine-details and make text ugly if not unreadable - there’s a reason we use H.264 for movies but not text documents. I remember around 2013 when a bunch of competing remote-access companies all launched hardware-accelerated-video-based remote-desktop products and being impressed with how they handle remote-Netflix over a pre-LTE mobile tether, but reeling and gasping to throw-up after their aggressive codec motion-estimation, subsampling, and YUV colorspace absolutely butchered a 100% zoom Word document with ClearType enabled. Using the system instilled oneself with a strong discipline against ever moving or resizing a window on the desktop, lest the smears of low-bitrate macroblocks start to appear, warning you the text-on-screen is about to become painfully unreadable for the next few seconds while you curse the DSL connection you’re still forced to use because your apartment complex’s HOA got a sweet deal on satellite TV from the incumbent telco by blocking the local cableco, with their sweet sweet DOCSIS 4, from adding service to the building and I’m done. [1] https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/frame-rate-limited-to-30-fps#setting-frame-rates https://learn.microsoft.com/en-us/troubleshoot/windows-serve... [2] https://learn.microsoft.com/en-us/azure/virtual-desktop/graphics-encoding#chroma-subsampling-support-for-420-and-444 https://learn.microsoft.com/en-us/azure/virtual-desktop/grap...

sitkack 2y ago

And they claim patent protection on it. You have to buy a license for Microsoft.

IcyWindows 2y ago
Still?
- tracker1 2y ago
  The main protocol should be well outside patent protection, but some of the extensions (RemoteFX, audio support, etc) may still be covered, would have to double-check. Likely fine. I would like to see something as capable make its way into Linux and Mac that's as ubiquitous. RDP tends to work better than the VNC options most other solutions are using under the hood.
  - bee_rider 2y ago
    I’m really baffled as to why anybody would downvote this comment, anyone want to explain?
  - iforgotpassword 2y ago
    How about spice? I don't know anything about the technical details, but it seems to offer most of the advanced features like usb redirect and I think currently gets video support. It's currently really only used in qemu but I don't see a reason why you can't use it as a general open rdp alternative.
  - inversetelecine 2y ago
    Gnome and KDE both support RDP in recent releases. Works ok, but connecting is not as seamless as Windows, at least with mstsc.exe. I’ve found it somewhat buggy too (blank or black screens until rebooted for example.) One of the big things holding me back was good Remote Desktop experience on Linux. Using Gnome RDP has been good enough for basic use for me.
    - 2y ago

qsort 2y ago

It's very good at being a remote _desktop_ protocol, but the fact that it lacks features like tunneling and that authentication is the usual MS mess makes me wish they just went with SSH as transport protocol.

tomjakubowski 2y ago
Windows does support SSH now, so maybe you could rig RDP-over-SSH yourself with port forwarding.
- p_ing 2y ago
  RD Gateway leverages SSL for encrypted transport for RDP between client and host. Maybe it is possible :-)
  - chupasaurus 2y ago
    RD Gateway has nothing to do with tunneling, it's just a reverse proxy for RDP connections. Funny note: as you've mentioned in other comment, my guess is that RDG was also licensed from Citrix but at the later point.
- awakecoding 2y ago
  RDP-over-SSH will break Kerberos authentication for two reasons: 1) you'll point the RDP client to localhost and a random port and 2) you won't get a KDC line-of-sight. The irony is Microsoft has demoed this with SSH over Azure Arc, which can only result in an NTLM downgrade. IronRDP is designed to work with Devolutions Gateway (https://github.com/Devolutions/devolutions-gateway https://github.com/Devolutions/devolutions-gateway) for just-in-time RDP connections made from the web or through the desktop client. Devolutions Gateway also supports just-in-time KDC proxying alongside the main RDP connection, making Kerberos possible. You can install the free standalone web access package of Devolutions Gateway to try it out, it will give you a simple web interface where you can enter the hostname, username and password. But if you really want the simplest solution, it's with the rest of the Devolutions stack with Remote Desktop Manager and Devolutions Server. In the end, you'll be able to make RDP connections from RDM or through the web with just a double-click, and it'll automatically generate short-lived tokens and make RDP + Kerberos work seamlessly: https://devolutions.net/gateway/ https://devolutions.net/gateway/

SirMaster 2y ago

I feel like a more modern approach like whatever RustDesk uses is way better. It has such good performance that I can practically play an FPS video game through it or watch a movie through it. The big thing I hate about regular Microsoft RDP is you aren't getting to use your remote GPU through it.

raggles 2y ago
> you aren't getting to use your remote GPU through it. Um yes you are? I use AutoCAD and other software using GPU all the time over rdp
- vekatimest 2y ago
  I've had issues with some software & games not being able to get a proper display context and refusing to start.
  - raggles 2y ago
    Yes I have seen OpenGL applications refuse to start with AMD cards in some circumstances due to a bug in the AMD drivers, but never had a problem on NVIDIA cards
jeroenhd 2y ago
RDP GPU acceleration should be available (on Windows, at least) with the right quality settings. AFAIK nothing API-wise prevents GPU software from running. That said, RDP is an edge case few software developers bother testing so I'm sure there are lots of programs out there that ignore edge cases when it comes to rendering APIs. It's not optimised for games, though. Something like Parsec would be much better for interactive stuff like that, or maybe something like Moonlight for Nvidia cards if you're looking to go without closed source software.
- SirMaster 2y ago
  I know it's not made for games, but the thing is I am seeing Parsec-level performance and quality from RustDesk which why I am liking it so much. With modern hardware with RustDesk you are getting HEVC or even AV1 hardware encoded high framerate stream of your desktop. I have never seen this kind of performance through MS RDP personally.

wkat4242 2y ago

It's usually pretty good on windows because it does a lot of local drawing but most Linux servers don't support that and use it just as a dumb blockpusher like VNC :(

aappleby 2y ago

If you think RDP performance is good, you should try Sunshine+Moonlight. I regularly stream at 4k 120hz from my gaming PC to my laptop and it's basically indistinguishable from running locally. I've even run it over Tailscale from a thousand miles away (though at 1080p60) and it was still markedly better than RDP. Caveats - You really want a Windows host for fully accelerated on-GPU hardware video encoding, the server setup is _slightly_ more involved than RDP which is usually preinstalled, and Sunshine+Linux+NVidia requires an annoying driver patch. But overall it's _amazing_.

winkelmann 2y ago
I'd still pick RDP for remote managing any day, its server and client are so much better integrated (clipboard, peripherals, etc.) for this task than Sunshine/Moonlight. It also avoids the whole issue of setting up a virtual display output[1] as is required by Sunshine. I use both for different tasks. On a related note, as of recent versions, Sunshine and Moonlight stable releases support 4:4:4 chroma subsampling and bitrates up to 500Mbit/s with HEVC, which results in almost indistinguishable image quality compared to native output[2]. Bitrates that high are unusual in normal content, but at least Apple's Media Engine (on M-series Macs) appears to be capable of decoding it. [1] Here is a pretty good solution that piggybacks off of Parsec's driver, which is fully signed, though its EDID lacks HDR support. The project also includes a C header file for custom implementations: https://github.com/nomi-san/parsec-vdd https://github.com/nomi-san/parsec-vdd [2] Note: I found that I had to enable 10-bit color streaming (which is available when using Parsec's driver) to get rid of some gradient banding that isn't present in native 8-bit. I suspect it's some encoder and/or color space issue.
- wtallis 2y ago
  I wonder how Apple's ProRes would work for remote desktop over wired networks, especially now that consumer equipment is starting to move beyond 1GbE. They have hardware encode and decode on everything newer than the original M1, and ProRes only does intra-frame compression so a fairly low-latency implementation should be possible.
gryn 2y ago

cryptonector 2y ago

Anytime there's a timeout the Microsoft RDP client makes you wait way longer than you might have had to otherwise. That kills me.

inversetelecine 2y ago
Yeah. I usually just close the client and reconnect that way instead of waiting for it to auto reconnect.

singhrac 2y ago

It is really nice, I'm very sad that Apple's RDP implementations seem fragmented and difficult to use. I've tried a few times with my Mac Mini, and it just doesn't seem to work that well.

naikrovek 2y ago
They use simple VNC but with some special “applesauce” that makes every non-Mac client I have ever tried break after a minute or so. But, on a mac, when you “screen share” into another Mac (this is what they call it for some reason; you “screen share into” the remote) it is flawless and quite snappy.
- awakecoding 2y ago
  If you want to connect to the built-in macOS remote desktop server, don't use a standard VNC client, use a real ARD client like Remote Desktop Manager. While the server accepts standard VNC, you will only get zlib the codec, which has very poor performance. With ARD, you get a special codec inspired by progressive JPEG, along with server-side downscaling and chroma subsampling, etc. It's actually closer to RDP RemoteFX in terms of performance: https://devolutions.net/integration-center/apple-remote-desktop/ https://devolutions.net/integration-center/apple-remote-desk...

EthanHeilman 2y ago

At Cloudflare we used IronRDP to build our Cloudflare Access RDP product [0] and scale RDP access across our edge using workers. I can't say enough good things about the IronRDP project. I didn't write the RDP code deployed in Cloudflare Access, but I did some of the prototyping with IronRDP. * IronRDP code was excellent, thoughtful and well designed. * The IronRDP project was friendly, responsive and helpful. They answered some pretty obscure RDP questions I had. I would recommend anyone doing RDP protocol work to use the IronRDP project. *edit:* I didn't even realize it until someone pointed it out but our blog post on Cloudflare using IronRDP went live today. [0]: RDP without the risk: Cloudflare's browser-based solution for secure third-party access https://blog.cloudflare.com/browser-based-rdp/ https://blog.cloudflare.com/browser-based-rdp/

vfclists 2y ago
Can IronRDP work with HTML5? I find myself using Guacamole because a lot of firewalls block WebSockets or the admins block WebSockets in their browsers.

bob1029 2y ago

I got so used to working in RDP that I can't really process the difference for non-gaming use cases. At the end of every day on my personal machine, I will inevitably mouse up to the top-middle of my screen and realize I am not inside some W365 instance.

teleforce 2y ago

If I recall correctly one of the main reasons replacing X windows with Wayland is so that we can similar performance of remote desktop for Linux as provided by RDP for Windows. Along that many commentaries on how lousy and ad hoc it was the Linux remote desktop solutions based on X windows unlike RDP and Wayland is touted as modern Linux desktop saviour. I'm wondering after many years now, what is is the state-of-the-art of Linux remote desktop status that now Wayland is the default Linux desktop windowing system for Linux, is it comparable to Windows RDP now or better? It will be good to have high performance remote desktop based on Rust or any strongly typed compiled language for Wayland. This can be a good showcase of Rust for Linux instead of the recent Linux kernel brouhaha.

tomjen3 2y ago

Agreed. Its not just that its better, it is also that most of the settings for Linux ends up not using the same desktop you would get if you were sitting in front of it. I still haven't found a solution for where I can login over the network and accessing the same session I would have gotten by sitting in front of the computer (including GPU acelleration). The guides are either for something like NoMachine that requires your screen to be on and often that you are logged in first, or they start a separate environment up using something like VNC. Meanwhile Remote Desktop, as you said, just works.