Hacking the planet with Notcurses

Posted Mar 20, 2020 20:04 UTC (Fri) by nivedita76 (subscriber, #121790)
In reply to: Hacking the planet with Notcurses by ledow
Parent article: Hacking the planet with Notcurses

What is the hassle in setting up? Assuming you already have an X server running on your local machine, it's as simple as ssh -Y server emacs

Hacking the planet with Notcurses

Posted Mar 20, 2020 22:32 UTC (Fri) by nix (subscriber, #2304) [Link] (6 responses)

Quite. Frankly, the environment in which remote X (and X forwarding) are useful is the one in which it was originally designed: you have a local area network and you want to run your graphical app on a big powerful machine which isn't the one you're sitting in front of (and which may well not have a screen attached at all). It works great there (though 3D is not terribly wonderful, honestly that's not likely to be the major use case for big powerful remote machines on a LAN in any case). It's not good at high-latency WANs, but then it never was.

(I do almost all my work that way, on an Emacs on a big LAN-remote server, and have for my entire working life.)

Hacking the planet with Notcurses

Posted Mar 22, 2020 10:50 UTC (Sun) by evgeny (subscriber, #774) [Link] (4 responses)

I really don't understand why people use X remotely if the response times etc are intolerable. Even within the same LAN it's annoying sometimes. Why not run the GUI app locally and provide instead remote access to the data (files)?

E.g., I mount (user-level, with sshfs) a remote directory I'm working on, and have the files appear as local ones to the locally running GUI apps. Then fusermount -u, and that's all. The only remote traffic takes place when I hit the "save" or "load" buttons, and since the file sizes are typically small, this is almost unnoticeable. Or at least predictable.

Hacking the planet with Notcurses

Posted Mar 22, 2020 13:43 UTC (Sun) by sorpigal (guest, #36106) [Link] (2 responses)

> Why not run the GUI app locally and provide instead remote access to the data (files)?

A few reasons: you can avoid needing to install and configure the program on each client, and for resource-intensive activities a beefier remote system can be better.

Hacking the planet with Notcurses

Posted Mar 22, 2020 17:13 UTC (Sun) by evgeny (subscriber, #774) [Link] (1 responses)

> you can avoid needing to install and configure the program on each client,

which is a one-time and (typically) trivial task. Commercial software with a per-client licensing is a separate story, of course. But, and also responding to your next comment,

> and for resource-intensive activities a beefier remote system can be better.

at least for this whole thread, you'll see many people complaining & comparing their performance figures not about some resource-intensive activities, but about emacs and like.

Hacking the planet with Notcurses

Posted Apr 8, 2020 22:44 UTC (Wed) by nix (subscriber, #2304) [Link]

> at least for this whole thread, you'll see many people complaining & comparing their performance figures not about some resource-intensive activities, but about emacs and like.

Emacs is an application manager as much as it is a text editor. Forking off performance-sensitive and/or memory-hungry subprocesses at the drop of a hat is downright common. (Even if you don't use magit. :P )

Hacking the planet with Notcurses

Posted Apr 8, 2020 22:42 UTC (Wed) by nix (subscriber, #2304) [Link]

I run multiple Emacsen: usually one for Gnus and one for work, under different uids. They use about 10GiB RAM each these days (Gnus is a bit of a pig and so is EDE/CEDET and I often have many hundreds of buffers open at once). My desktop doesn't have enough memory for that. They also like to talk to subprocesses which are better not "ssh BLAH" because the semantics of signal-handling across ssh sessions is screwed by the remoteness: you can't ctrl-Z one process inside an ssh you forked if you're that ssh's parent! Many of those subprocesses are things like compilations, and dammit I'd like to compile on the remote box with 20 cores and 128GiB ECCRAM and terabytes of SSD-cached storage, not the local box with 16GiB non-ECCRAM (half of which is eaten by Chrome/Firefox) and only two slow cores optimized for low power usage. (The local box has fast graphics, which is what matters for a desktop.)

The response latencies caused by doing this stuff over remote X are completely imperceptible. There's a reason I have 10GbE on the desktop! but the response times were completely ignorable even when it was only 100MbE. X is latency-sensitive above all else, and Ethernet is low latency.

Hacking the planet with Notcurses

Posted Mar 23, 2020 18:20 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

There is one other mode in which it is useful: Letting (remote) TUI applications interact with the (local) system clipboard. See for example Vim. This works well even over the public internet, because latency is basically irrelevant. A yank command taking an extra few hundred milliseconds is barely perceptible to me, and my keystrokes are buffered anyway.