I use it, but generally only at work on a local network, where the performance is fine. My most common use is to run R on a big server but still have plots pop up on my laptop. There are other ways to do this, e.g. one of the IDEs for R (RStudio) apparently has some infrastructure that would let me run R on my laptop and then farm out the computations remotely. But I find just ssh -X the easiest for now.

It was pretty great when I was a university student using X forwarding within the campus network between my dorm and the CS department (in either direction). Certainly not as fast as local, but extremely usable when not trying to do graphics-centric things. (Even using Eclipse was viable.)

Your mileage may vary by use case and bandwidth, especially over the public internet. But if someone has a similar use case to mine in 2019, it's still probably usable.

Even if it's usable, it's probably not a good idea. X windows are not rendered by the server anymore. The client (i.e. the application) renders them and just transmits a full pixmap to the server. Depending on the redraw strategy, you could have a worst-case scenario where 60 frames per second of the entire window are transmitted completely uncompressed (except for the compression that SSH applies). You'll be sailing much more efficiently by using a VNC client.

To be pedantic, this is true with "modern" toolkits (like, this cemtury). Applications using Motif or Xt or anything similarly ancient still do server side drawing and they absolutely shine with todays network latency and speed. But most applications moved on from.these toolkits, with good reason.

+1 to this. For my first two years the university didn't have student Matlab licenses but the CS department machines had copies so I would ssh -X for my coursework requiring Matlab (needed the GUI to see plots).

Yup, I did this in college all the time as well. It was usable for most applications.

Even wireshark is usable this way.

It's not only ssh. I start GUI applications as a different user than the current desktop user constantly. It's a way for me to separate uses from each other. It gives you a huge amount of flexibility.

I do a lot of these things with Linux, you cannot do in Windows:

   - Log in, start an arbitrary program. Then log out, without the program stopping
   - Start a GUI application as a different user than the one logged in graphically
   - Start a GUI application that resides inside a container
   - Start a GUI application in the local LAN over ssh

Take those away and you take away the biggest edge Linux has over Windows.

> Start a GUI application that resides inside a container

I do this all the time to confine an application to a network namespace.

It is great for forcing some GUI applications (for example a browser) through VPN while keeping everything else going over the default route.

This way you can make sure the browser in your network namespace can only use the VPN.

    Start a GUI application as a different user than the one logged in graphically

the xauth command will let you do this (which is what ssh X forwarding does)

Re. performance. Did you use SSH's “-C” switch for data compression? The first time I used X over SSH it was lagging as all hell, until I used this switch, and after that everything ran much smoother.

We use it semi-regularly at work. (I do Linux Administration for a hosting company.) Or, more precisely, our Oracle team uses it, as there seem to be several Oracle-related utilities that require a GUI. I don't work with it directly, but I have helped to set it up on that team's behalf from time to time. For that purpose, it seems to be quite stable.

I don't think X-forwarding is a good substitute for VNC(-alikes) if you need to do long sessions, but for occasional one-off GUI work where either there's no CLI equivalent, or the CLI version isn't the best choice, it does get the job done.

X forwarding seems to work enough for my primary use case. I have some supermicro servers for work with a java applet for KVM. Because of a series of reasonable but unfortunate policies, I can't run the applet directly in the laptop's host OS. The best way is to run it in a VM. It's a lot better experience for me to run the applet over X forwarding despite some issues with window resizing that I suspect are related to hidpi, than to run a full X desktop in the VM. Host is osx, guest is freebsd with linux compat and oracle jre for linux.

It was also useful when I wanted to output some pixel graphics from Erlang to my Windows desktop from a program running on unixy devices. x server windows, x client on linux, freebsd, os x -- occasionally also ran with os x as x server and linux or freebsd as x client.

The key thing for me is the ability to export the gui for a single application on one system to a desktop environment on another --- I think this is possible with other systems, but it's not easily exposed. Performance and fidelity of the experience is usually not that important for me, as long as it's usable.

I use it regularly with VMs. I find it a much better experience to have a bunch of terminals open on my host that are ssh'ed into the VM and can open new GUI windows on the host (generally meld for either git-merge or git-diff).

The main draw is just that it works so seamlessly. All you have to do is remember to add the "-X" flag when you call ssh and everything just works.

I use this a lot at work. I ssh into a server from my linux desktop and run things there, including GUI applications. Over a local network it works fine. It's much nicer to have local and remote applications displayed in the same way. I can also run things from remote networks, although I have to use the -C compression option on ssh.

I use it constantly (including across different OS/architectures), have been using it for more than 20 years and really can't live without it.

It works great. And Mozilla/Firefox has been working wonders with it (when you open a web link on a remote application, it opens the URL in the local, already opened Firefox and has been doing so since Netscape times).

With a 500Mbps internet connection and a 10ms ping to the server, the performance is quite usable. There is some lag when updating large bitmap areas, but for anything not graphic intensive, it works just fine.

Believe it or not, there are production environments that use X-forwarding over ssh. Modern computing relies more and more on remote streaming of interfaces. Even games are going that way.

In my experience NX / x2go blows everything else out of the water. VNC isn’t even comparable.

NX allowed me to work on my Linux desktop in Iceland from a hotel room in China.