That you can't just launch that on every machine you want (in particular non server installs) is more a limitation of Microsoft's licensing model than of the protocol itself.
For me, from a usability point of view, RDP runs circles around the other solutions. I've used this fairly often during the lockdowns and even over a shitty DSL connection there was close to no lag.
In windowed mode, I can either have scrollbars to view a subsection, or I can scale the window. Doing the right thing, changing the size of the remote desktop when the local window is resized, isn't an option because that is set at connection time.
Sometimes, for firewall reasons, I need to have needed RDP sessions. At this point, everything performs poorly, and I need to drag the overlayed blue bars off of each other, then interact with one or the other.
I miss SSH, and want better support for it. Nested connections can be handled with SSH tunnels. Text connections are fast enough to do anything on the slowest of connections. If I need a GUI, I can open up a single window through X11, without additional setup with RemoteApp. Windows remote management through RDP is slow, clunky, error-prone, and inflexible by comparison.
Side note: if the server is running Windows 8.1 or later (or the equivalent server versions, Server 2012 R2 or later), this isn't the case any more-- RDP sessions can be resized freely at any time.
Naturally, the built-in RDP client that comes with Windows doesn't support this (because, of course, why would it?), but the UWP Remote Desktop app in the Windows Store does (as does the current Mac client).
For your "nested session", the problem is that the adaptive nature of the protocol breaks down if the first hop has a very good connection to the destination. However, you're holding^w using it wrong. In this kind of scenario, I think MS recommends using a remote desktop gateway, which also works very well. I think one of the great advantages of RDP over ssh X forwarding is that it can use UDP.
I definitely dislike how you have to have a Windows server installation and specific license to set up remote app, though. But I've filed this under "it's Microsoft, what can you expect?".
I also find windows administration horrible, be it via remote desktop or keyboard plugged directly in the server. I grew up with Linux and macOS, so it was always a pain when I absolutely had to give someone a hand with something windows-related (my client has a bunch of Windows servers).
But still, I'm not the kind to throw away the baby with the bathwater and to think that if I generally dislike and would avoid a company's products every single thing that they do is bad. I really wish Linux could have something similar to RDP in performance. It makes me sad when I vnc to a computer across the room and the thing lags more than RDP to some windows box in another country.
edit: Regarding your having to work with several RDP sessions at the same time, it baffles me that the worst RDP client I have ever used is the windows one. I don't use windows on my machines, and the Linux client (Remmina) is absolutely a dream, especially when running on i3 (so there's no conflict with win / alt-tab / etc). Also, MS's mac client works very well and there's no key conflicts there either. You may want to look into the new Remote Desktop app on windows (not quite sure what it's called, it's on the windows store). It now supports window resizing and easier switching between sessions.
The catch is that the UI to configure RemoteApp isn't present on client versions of Windows. It can be configured manually (by editing the registry then creating RDP files by hand), or there are open source tools that will do the work themselves: https://github.com/kimmknight/remoteapptool
Somewhat outdated Microsoft docs on how to do this by hand: https://techcommunity.microsoft.com/t5/microsoft-security-an...
https://techcommunity.microsoft.com/t5/microsoft-security-an...
The same sort of thing can be said for Remote Desktop. If you're using a version of Windows that includes it, it is wonderful to use because it is just there.
Which is better? It depends on how you're using it. I generally prefer Remote Desktop for my use case because it takes care of audio and it is easy to resume sessions. That being said, those features don't matter to me most of the time so X is just as useful.
Doesn't every Windows include it? I can't remember the last time I used a version of Windows that didn't have it, it must have been 20 years ago.
Seems like such a fundamental use case that should be made simple but is ignored (or made very difficult) by modern systems.
How all of this works on the backend is a combination of PipeWire to multiplex video sources and PulseAudio to multiplex audio sources.
There's nothing outright preventing something like X forwarding and https://mstoeckl.com/notes/gsoc/blog.html is a really cool project that makes it work.
From that author:
> The main difficulty in producing such a tool is that Wayland protocol messages primarily include control information, and the large data transfers of graphical applications are implemented through shared memory. waypipe must then identify and serialize changes to the shared memory buffers into messages to be transferred over a socket.
https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
https://docs.kde.org/trunk5/en/kdenetwork/krfb/krfb-configur...
You most likely won't see an implementation "for Wayland" because that's like asking for a websocket implementation "for HTTP" the actual compositors that speak Wayland need to implement remote desktop capabilities and then expose an API for managing remote desktop sessions (org.freedesktop.portal.RemoteDesktop) to programs that want to leverage it.
MacOS doesn't use it, Windows doesn't use it. Even Linux is moving away from it. That's pretty damning for X as a technology during a time when even Windows has started to offer native curl and ssh, just saying.
Ubiquitous networking is common in the Unix world, but much less prevalent in the Microsoft and Apple worlds.
At least anecdotally, I'm not sure I can find a whole lot of supporting evidence for this -- the vast majority of the commercial applications I use on a daily basis let you install them on any compatible system that you own. This isn't just a byproduct of "well, they're not checking"; it's usually explicitly written in the license, it happens with programs that make you enter license codes they validate before running, and notably, it's very explicitly the model of the Mac App Store. Sometimes the license says only one copy of the program can be in use at a time without a site license, but for individual use that's generally fine in practice. (I haven't seen a program that's actually annoying enough to check for running copies of itself on a LAN and shut down if you're violating the license in decades at this point, although I'm sure they're still lurking out there in weird niches. It sounds like something Autodesk software would do.)
Anyway -- maybe running programs remotely using the Xserver model never took off in the Mac world, even after OS X, because there was no prohibition against just installing the software on multiple machines? In practice, it's not something I've missed very often, I admit; while I sometimes like to edit text files remotely, that's not something that feels like it would really be improved by this model over using a local editor that can open files over the network. (Edited to note that I'm not suggesting there aren't still valid use cases for X11's server/client model! They're just not ones that have impacted me; if they did, I'd run XQuartz, which I don't love, but it'd probably get the job done.)
Individual use (there's a funny story here) doesn't really matter; what matters is groups, corporations, with tens to tens of thousands of users, and yes, Autodesk is an example (and GitLab (https://about.gitlab.com/pricing/), sort of). Things that make X necessary and useful are typically, something that you absolutely need, that requires custom support and big hardware, but not something that everyone on your staff needs all the time.
Funny story: At one point, a security researcher realized you could run a program through an instruction-level compiler, reordering operations without changing behavior, so that the machine running the program would broadcast RF signals containing the program's license number. It wouldn't really do anything for single machines because the signal was too weak, but if everyone at a company were using the same license for program X, you could drive around the neighborhood with a van and pick that fact up clearly.
Microsoft was completely uninterested. If it would not prevent every individual from pirating even one copy, they didn't care. Which may be why I recently typed in a twenty-odd character string into my new gaming machine.
No. :) I tried to be clear that I was thinking about individual licenses rather than site licenses, but might not have been, and you're absolutely right about corporate site licenses. Apple's App Store is designed for handling individual licenses -- they're tied to Apple accounts, not machines. (With the asterisk that this isn't necessarily true for iOS devices which can be managed by your company, and there's a whole different way of managing those, but companies I've worked for haven't used those.)
I'm not sure I knew Microsoft was still requiring license keys like that for Windows, but I suppose I shouldn't be surprised.
I believe that latter condition is actually true for Microsoft 365 Personal[1], too -- it's tied to your Microsoft account, and the one "seat" you're buying is that user, regardless of the number of devices you have. Business editions tend to be licensed differently.
[1] I know that looks like I got the name wrong, but apparently in April they changed "Office 365" to "Microsoft 365."
if windows was enough for my needs I'd use it ?
You can run an X server on Windows, there's a bunch to choose from. That lets you run an application on a remote unix system and show it on a Windows system in front of the user. It might be nice to run an application on a remote windows system, but that's always tied to expensive licenses; some of those systems sound like they could be pretty seamless (at least as seamless as remote X), but I don't have experience with them.
Remote X has its problems, but it enables a lot of use cases with a minimum amount of hassle. Connect, run the application, close it when you're done. Other solutions with a remote desktop require starting that session somehow, and either leaving it running or shutting it down somehow. That can be useful if you want a long running session, but is more hassle if you don't.
Which is why the people who need this functionality run Linux, not Windows.
Visual Studio Code has "Remote Development" (which is under a Non-Open Source License(!)) because they don't have "X11 Forwarding".
Think about the waste of implementing that code--in every application--rather than being able to do display forwarding.