> The shift away from X11 means no more forwarding X11 applications over ssh, which is slow at best and buggy and insecure at worst.
Yes but sometimes you really need that and it's a life saver.
EDIT: I just remembered about LTSP (Linux Terminal Server Project) which many schools used to lower the TCO of computing infrastructure. That relied heavily on Xorg's network transparency. I wonder what will happen to LTSP
Honestly, I think people's reliance on X forwarding is just due to the fact that it happens to exist, not because they really need it. There's nothing like X forwarding on Windows to my knowledge. If X forwarding didn't exist people would have figured out how to do what they needed over SSH with text or when GUI's are irreplaceable sysadmins would have set up an actual remote desktop solution like on other modern operating systems.
Yet, many people use windows and I still miss X forwarding. RDP and VNC are just not a replacement for being able to start 3 different programs on 3 different remote computers, and have them all sitting together on screen next to each other.
Technically, RDP allows you to only launch one application as opposed to a whole desktop. They call that RemoteApp.
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.
RDP works well if you want to connect to a remote machine, then work only on that machine for a significant amount of time. For me, I need to switch in and out of several different RDP sessions, which is a nightmare. Alt tab works either within a session if full screened, or within the local computer if not full screened. That means I need to also periodically use ctrl alt break to switch between full screen and windowed.
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.
> 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.
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).
My point was that RDP, the protocol, works very well and is able to adapt to network conditions.
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.
You just got me to do a little digging... apparently, as of Windows 10, RemoteApp itself isn't restricted by licensing (at least, any more than Remote Desktop itself is)-- Windows 10 Pro (and Enterprise) can now host RemoteApp applications.
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
RemoteApp mode for RDP lets you interact with server-hosted apps like a client-hosted one. Also, I recall using apps with rdesktop in seamless mode, which worked pretty well.
The happens to exist bit turns out to be very important. I can login to a machine and run an X client without installing and configuring extra software on the server. If I am using a desktop with X installed (most *ix based systems), there is no extra software to install and configure on that end either. The worse case scenario is the necessity to install an X server on platforms like macOS and Windows.
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.
> 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.
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.
Right, the shift away from X doesn't mean the death of using GUI apps remotely, it just means moving to a Remote Desktop model instead of telling apps that their render target is your X server through a tunnel.
What if I don't want a remote desktop though? 99% of the time I only want a the remote application I am interested in to seamlessly display on my screen, why do I have to bring along a full desktop?
Seems like such a fundamental use case that should be made simple but is ignored (or made very difficult) by modern systems.
I hesitate to call it an official model but the short version of the current direction is that the compositor acts as the glue -- providing the final rendered scene and the final merged audio stream to the client over some protocol (like VNC but doesn't have to be) and providing inputs and events to itself and the client applications.
How all of this works on the backend is a combination of PipeWire to multiplex video sources and PulseAudio to multiplex audio sources.
> 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.
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.
And the adoption has been huge outside of Unix circles...
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.
Gosh, the technology only lasted 36 years so far, and definitely has a few years left to go in it before it is "dead". What a striking condemnation that it only made it 40-ish years before being replaced.
Windows and MacOS have been (and are) based on the model of buying a copy of a piece of software for each piece of hardware. The idea of only buying a copy for one machine and running it somewhere else is difficult for that model.
Ubiquitous networking is common in the Unix world, but much less prevalent in the Microsoft and Apple worlds.
> Windows and MacOS have been (and are) based on the model of buying a copy of a piece of software for each piece of hardware.
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.)
I haven't used Apple's App Store; is it really true that, say, Ford Motor Company can buy one $9.99 (or $99.99) copy of some useful application and use it on all of the corporate Macs?
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.
> I haven't used Apple's App Store; is it really true that, say, Ford Motor Company can buy one $9.99 (or $99.99) copy of some useful application and use it on all of the corporate Macs?
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 have encountered it -- but, the way I read the original post was more about individual usage rather than computer license, e.g., I don't need a license for every computer I have my personal copy of BBEdit installed on, because they're all "my" computers, even including my work computer. And, any computer or device that uses my Apple account can download and use applications purchased on it.
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."
> There's nothing like X forwarding on Windows to my knowledge.
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.
For terminal server use cases, there are things like VNC, SPICE, NX, etc. The X11/ssh thing is for when you want to run a mix of local and remote applications on a single desktop, which i think is pretty unusual these days.
Wheelchair users are also pretty unusual and we don’t go removing ramps from everywhere. I’m growing pretty tired of the “your use case is unusual, so fuck you” argument.
Despite having felt this way about so many things, I have never seen this argument put so well and succinctly. I am going to be using this ALL THE TIME.
Also, is this "sildur" of Minecraft shader fame? If so, much thanks, you've given me and my daughter many instances of "ooh pretty look at our house."
Please do not so blithely invoke disability just because someone removed the feature you cared about. It sucks, but I promise you navigating the world in a wheelchair sucks a lot more.
I don't want to speak for anyone in particular but X11 was definitely not a friend to people who cared about a11y or l10n. It wore its origins in "80s MIT students" on its sleeve, for good and bad - and for non-English-speaking or disabled people, mostly bad.
Hey, this is not a contest about who had the crappiest life, and if it was, I can assure you that there are things in life that suck more than navigating the world in a wheelchair, and I’m not asking people to stop complaining about that just because they happened to me.
Anyways, replace wheelchair users with pregnant women, or old people. Ramps help them too, and the argument is still valid.
Supporting "unusual" cases is difficult and takes more effort. In the dog-eat-dog world of commercial development, to win you have to get the majority.
My remaining use case for X11 remote display doesn't quite fit in the VNC/etc. remote display paradigm. At work, I submit a job to queuing software that picks a server (based on load and resource requirements) from a pool on the internal network. The GUI for that job then pops up on my X11 display. I don't really care which server is running the job, and the job is just using $DISPLAY -- we don't even forward over ssh.
I’m not an X hater but just know you’ve given that server access to your display socket which is effectively remote command execution.
In most cases this could be solved with a good web user interface, but you can rest assured X won’t be dead in the next 5-15 years, and you can use an intermediary box w/VNC if security is that much of a concern.
Is it really that unusual to do some data reduction/analysis on a beefy dedicated machine and wanting to look at the results right away using the same terminal instead of having to copy the result files or using a shared network file system? Even more important if it involves any graphical interactions.
Sure, one could use a remote desktop to do same thing, but it's a bit annoying if all you want is one window from the remote machine.
> it's a bit annoying if all you want is one window from the remote machine.
You should try xrdp. It can work like X forwarding (single application window forwarding), but you can also attach or detach from a running application (like screen or tmux for X).
That's only really an alternative for long-running applications since it still seems quite tedious to do if I am not missing anything (with modifying initial_program and all).
Right now the workflow is simply ssh -X machine and then run some scripts that may or may not open interactive windows and then look at the result files using some graphical application.
The same as if I was running it locally really (except on a beefy machine)..
I haven't tried all of the xpra options, but it would be a matter of starting an instance on the remote machine and then running the command to attach to it in the local machine.
I suppose that you could start a terminal session on the remote machine and spawn GUI applications from that. I'm not sure if xpra allows for a terminal session directly from the command line though.
Yes but sometimes you really need that and it's a life saver.
EDIT: I just remembered about LTSP (Linux Terminal Server Project) which many schools used to lower the TCO of computing infrastructure. That relied heavily on Xorg's network transparency. I wonder what will happen to LTSP