Re: Emacs in the Cloud

[Tim Cross]

On Sat, Jul 30, 2011 at 8:59 AM, Andrew W. Nosenko
<address@hidden> wrote:
> On Mon, Jul 25, 2011 at 17:09, Julien Danjou <address@hidden> wrote:
>> On Mon, Jul 25 2011, address@hidden wrote:
>>
>>> I use a graphical gtk based emacs everyday, and I also use terminal
>>> based Emacs sessions every day. Hardened remote servers will continue to
>>> actively not have any X installations for years to come. Terminal Emacs
>>> sessions clearly makes life more liveable in those cases.
>>
>> Does not sound like a good argument. Tunneled display over ssh already
>> exists for X11 for years. Tunneling HTML data does not sound like
>> something very hard to accomplish neither. :)
>>
>
> 1. Are you even tried to do such in real live (tunnel X11 through
> SSH)?  Not in laboratory environment and fast LAN, but in the real
> live, through not so fast channels and with server in a some another
> country?  Hint: I tried and found that 3 seconds for redraw Open File
> dialog is too much for me.
>

I use to do this back between '98 and 2000 when I worked for a company
that had systems I was responsible for maintaining scattered between 3
countries - Australia, NZ and US.

This worked just fine, though you did need to use one of the X
compression protocols. On some days, you would see a few seconds
delay, but most of the time, it was quick enough to seem fairly
instant.

While I would imagine in most cases, network speeds and reliability
have increased, there are areas in the world which would still be
considered slow or unreliable. If you have satellite connectivity, you
can often experience delays (i.e. pipeline filling delay/latency etc).
However, none of these network issues are magically cured with "the
cloud" - in fact, anyone with really slow and unreliable connectivity
will likely find the cloud paradigm far worse.

The reality is that while X11 was primarily designed as a LAN
protocol, it is a protocol with large amounts of redundancy and
benefits a lot from things like differential compression algorithms.
If you are using X over a WAN connection and don't use any form of X
protocol compression and experience performance issues, the problem is
due to not trying IMO. This information is readily available and easy
to configure.

> 2. Even inside one machine and one user always exists a room for
> terminal.  It was not once and not twice when ability to connect to
> Emacs server from a terminal (from console, if more preciously) was a
> lifebuoy when local X session become mad.

The ability to connect to the emacs server from virtual consoles etc
is a very recent additon IIRC. Maybe emacs 22 or 23. However, this is
not a feature I've found necessary. I do use an ssl based vpn to
connect to my office machine from home and then use emacsclient (with
X) to connect to the emacs server I've left running on that system,
which I find extremely useful as it means I can leave my work emacs
session running for weeks at a time.

Tim