To pile on against X11 over ssh, forwarding on a modern Linux workstation is spectacularly painful. I recently needed to forward a lightweight gtk app from one workstation to another over 10gbe and a single switch hop.

With ssh and X forwarding, my local gnome constantly threw up modal dialogs that the forwarded window was unresponsive, forcing me to keep clicking "Wait" to dismiss the modal, then quickly interact with the forwarded window before the next "unresponsive" modal popped up.

Forwarding Firefox over X11 _sometimes_ works. Sometimes Firefox on the remote machine will try to join the session of your local firefox -- but fail and then complain that there's Firefox already running. Adding `--new-instance` helps if Firefox is running in a container and X11 socket file is forwarded to the container but it doesn't seem to help if X11 is forwarded over SSH.

Try '-no-remote'. Or was that '--no-remote'? Anyway, that's what I've used for years and years when needing to run firefox over ssh X forwarding.

Firefox is running on the remote, connected to a different X11 session. It is not running on the local. When I use `firefox --new-session --no-remote` on the remote, I see a dialog pop up on my local machine stating Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

Yes, this is because firefox doesn't allow multiple ff instances to use the same profile at the same time. You can ask firefox to create a new profile (`firefox -ProfileManager`) and then use a seperate profile for the remote instance

> extremely synchronous

X11, the protocol, is actually mostly asynchronous, it's the libraries and the applications that were built around it in synchronous ways. If you run older applications (like 90s to early 2000s) over X11, it's a lot less bad than modern apps.

Isn't that mostly because modern apps have richer textures and high resolution, high bit depth images by comparison?

Maybe to some degree; head of line blocking and window sizes are real issues that would cause delays; but most of the problem is around requiring more round trips. This is what has made running X servers as thin clients go from being viable on the 10M ethernet of the 90s to being a terrible idea on 1G ethernet today.

Thanks for suggesting remmina, it might be a teamviewer substitute for a couple old relatives PCs. However I have to solve the dynamic IP problem that doensn't exist on teamviewer, so I was attempting to build a string that sends an email with the IP as payload.

Something like this: curl --url 'smtps://smtp.gmail.com:465' --ssl-reqd --mail-from 'xyz remote IP' --mail-rcpt '[email protected]' --upload-file mail.txt --user '[email protected]:pwd'

Where rather than the mail.txt file I can send the public IP of the remote machine, such as the output of "curl ipinfo.io/ip". Unfortunately I couldn't find how to do that. Backquotes also don't work, it wants a file.

The purpose would be to build a "pre-command" one liner that sends me an email with the remote IP as payload every time the remote user accepts an external connection through remmina. The remote users are old relatives with no knowledge about computers, so the simpler (one click) the better.

>it wants a file

Have you tried process substitution?

  <(curl -s ipinfo.io/ip)

https://en.wikipedia.org/wiki/Process_substitution

Worked perfectly, thanks!

I find running GUI GNU Emacs over X11 over ssh to be really pleasant, even moreso than using tramp (which occasionally hangs for no understandable reason), with the only problem being that highlighting text is a bit slow and balky. Otherwise, it's indistinguishable from a local Emacs in responsiveness.