The "loop and a half"

Peter J. Holzer hjp-usenet3 at hjp.at
Mon Oct 9 17:43:22 EDT 2017


On 2017-10-09 09:44, Mikhail V <mikhailwas at gmail.com> wrote:
>>>> Have you ever worked on a slow remote session where a GUI is
>>>> completely impracticable (or maybe even unavailable), and redrawing
>>>> the screen is too expensive to do all the time?
>>>
>>> So where does the redrawing happen? The machine youre sitting on (let's
>>> call it 'A') and send remote commands or retrieving text files? Or the
>>> redrawing must be synced on both A and
>>> the remote machine? If so, then why so?
>
> Peter J. Holzer wrote:
>
>> Because you want to see what you are typing. Imagine you are logged into
>> a server on the other side of the world. You want to edit a file on that
>> machine (for example a configuration file for the web server). You
>> invoke the editor on that server.
>
> I've never done this, but if one told me to edit a file,
> my first attempt would be like:
> - get read/write access to the file system
> - browse it (e.g. some file browser plugin?)
> - get the file to the local machine
> - edit locally
> - write it back to the remote machine

I've mentioned that possibility, but as I've also mentioned it may not
even be possible, and even if it is, it feels clunky to me. I'm already
on the server because I'm investigating an issue. I can simply edit the
file there. Why should I switch to a different tool (e.g. WinSCP), open
another connection, navigate to a directory again, copy a file, edit it,
copy it back (ok, the actual copying back and forth may happen
automatically, so I don't have to do that)?

Of course I am assuming that I have an editor I'm familiar with on the
server. For me this is almost always the case (I use vi (or rather vim)
- yes, I'm currently writing this posting with vim). For a Windows user
this will usually not be the case: There will be no Notepad++, Atom or
PyCharm installed on a typical Linux server.

(Of course there are those who maintain that you should never ever log
in to server: All interaction should be through APIs and management
systems. That may be true if you have thousands of servers. If you have
a few dozen I think that to get a management system into place which is
even close to the linux CLI tools in veratility is way too much work.)


>>> And not in a nice editor with normal fonts?
>>> Am i missing something or your 'A' machine cannot use graphics?
>
>> ... The server may not be able to
>> (it's a server, why would anyone install a GUI on it?)
>
> If I ever work on it (locally) why would I want a GUI on it?
> o_O   I'm not sure if I'm getting you.
> You mean probably a server which is never worked on locally?

Typically yes. T usually am sitting in front of a server just long
enough to make sure I have a network connection. Then I go back to my
office and continue from there. Server rooms are loud, drafty, and
either too cold or too warm.

But it really doesn't matter to me: On the text console I can use
exactly the same programs that I would use remotely over ssh. The only
differences are that there is only one window and I can't resize it.


>> streaming the screen contents of a rich GUI around the world may be not
>> be possible for bandwidth or delay reasons.
> Sure, streaming video consumes a lot, but that is what one tries to
> avoid if under limitations so streaming messages only is faster.

Streaming video is basically what RDP or VNC are. A command line shell
is closer to streaming messages. X11 is really message-based but it's
slow.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp at hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel



More information about the Python-list mailing list