X11 forwarding works with the latest Linux distros as well a 20+ year old systems running motif apps. Note: the old systems are now virtualized but we still need them, I work in the aeronautic industry and these are the time scales we are working with.
I don't know of any replacement, at least not one with that level of adoption. Again, we really want to run graphical applications on a server, not a remote desktop.
And BTW, things are getting troublesome. More and more Linux apps integrate accelerated web browser components and these tend not to play well with X11 forwarding.
Love the irony of using a remote display to show an Electron app BTW.
We also have a homemade documentation system, again outdated but certified. I don't remember the system but it is definitely not a modern Linux. I think there is also a Fortran tool used to compute the lifespan of parts on the same system.
A bit more recent, we have test benches made of several computers, mostly Linux desktops, each one deal with different things like real or simulated avionic hardware, they can be remote controlled but some apps run locally and have their own displays.
We also have certified build chains running on specific systems, and while a GUI is typically not needed. It may be useful from time to time, mostly for debugging.
We are in a process of modernizing all that stuff, but because of certification and the average lifespan of a program, it is a very slow process...
Things seems to be going backwards in this area..
[1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platf...
It was "slow" when I did it over 10Base2 Ethernet spanning an entire building. These days our CPUs are several orders of magnitude faster, and so are our networks. I don't need it to play the latest 3D games, I need it to display a user interface to an app that runs on a different machine. It's plenty fast enough.
On a local network, it's not significantly slower to run most apps through X11 forwarding than running them locally, and I use this extensively. The only daily application that's too slow is a browser, but Firefox (and before it, Mozilla did it too, and before it Netscape) automatically opens calls to the browser in the existing local window anyway (and there's always some pre-existing Firefox window open), even when running on some markedly different system (POSIX for the win).
When I used MacOS more regularly, Quartz always was the first application I installed.
When I see the comments from philistines unable to understand the obvious superiority of the one true Unix way, I always think of this Dilbert comic : https://dilbert.com/strip/1995-06-24
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
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.)
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."
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.
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.
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.
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).
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...
if windows was enough for my needs I'd use it ?
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.
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.
Seems like such a fundamental use case that should be made simple but is ignored (or made very difficult) by modern systems.
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.
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.
Which is why the people who need this functionality run Linux, not Windows.
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.
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.
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.
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).
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 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.
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."
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.
Anyways, replace wheelchair users with pregnant women, or old people. Ramps help them too, and the argument is still valid.
With love, The Chrome Team
Google continues the war against its own users.
Yes, I had that conversation with a friend.
Great. Which of those, if any, do you think might be installed on the machines I want access to?
Which of those, if any, do you think might be installed on the machines I want access from?
What do you think are the odds that the intersection of those is non-empty?
You have absolutely no basis for thinking this.
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.
Granted there is also sixel and tek4014 support in xterm, but they are quite limited in what they can do and not too many applications have display frontends for that.
And screen tearing? Didn't SGI have that solved in the 90's?
Which works fine and isn't a problem.
> A small price to pay for eliminating tearing and actually-secure screen locking.
Not necessarily. Not in all use cases.
"It doesn't work for me, therefore nobody needs it," isn't a valid argument.
And thinking about it a bit, it wouldn't have made any sense to keep the feature around for so long if it weren't useful.