9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] plan9port: acme remoting
@ 2021-01-04  4:40 marius a. eriksen
  2021-01-04 11:00 ` Ole-Hjalmar Kristensen
  2021-01-05  3:01 ` Lyndon Nerenberg
  0 siblings, 2 replies; 5+ messages in thread
From: marius a. eriksen @ 2021-01-04  4:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 5115 bytes --]

Lately, I have needed to do a great deal of my work on remote servers. It's
been difficult to do this with acme. Previously, I have attempted to run
acme entirely remotely, and then attach to a local devdraw instance
<https://github.com/mariusae/devdrawserver>. This works okay, but also has
many drawbacks, among which: (1) it's not economical with networking, and
so not great for high latency or otherwise poor connections; (2) it's not
resilient to connection disconnects; (3) often I want access to local
resources too.

I built an experimental remoting layer in acme to see how far I could get
in recreating a modern "remoting" experience with acme. Since acme itself,
of course, is designed around a bunch of 9p servers, this turned out to be
fairly easy to do, and the resulting experience is nearly transparent.

A remote may be attached to one or more path prefixes. These are similar to
mount points in a file system. Thus, if the prefix /home/meriksen is
attached to the remote "dev", then any file with this prefix is transparely
fetched from the dev. Similarly, when commands are run from any directory
with this prefix, the command is transparently run on the remote. The
command is run in an environment that includes the acme and plumber 9p
servers (forwarded from the local host), and so even acme programs just
work. For example, if you run 'win' from a directory that is attached to a
remote, 'win' is run on the remote host, but it accesses the acme 9p file
tree (which is forwarded from the local acme) and creates its window and
interacts with acme. It "just works". (I regularly run other programs like
this too, e.g., acme-lsp, which uses the plumber to coordinate interaction).

The design of the feature is quite simple: a new program, acmesrv
<https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme/acmesrv> is
run by acme (through ssh) on the remote host. Acme becomes a client of
acmesrv, through which all further interaction is facilitated. Acmesrv
itself is really just a 9p multiplexer: the local acme program exports the
acme and plumber 9p servers; acmesrv provides two new 9p servers (exportfs
and cmdfs) that gives the local acme access to the remote's file system
(exportfs) and to run commands (cmdfs).

The local acme manages a session for each remote, and properly deals with
session disconnect/reconnect, etc. Thus, poor network conditions and
disconnects are easily supported. Since acme's file handling is anyway
stateless (the file is not kept open during editing), file state is easily
maintained through disconnect-reconnect cycles.

There are some synchronous code paths in acme, and these may cause
temporary freezes when using remoting. For example, when acme queries for
the existence of a file (stat), this blocks UI updates in acme. On session
establishment (e.g., the first time a file is accessed on a remote), this
can cause additional delays, since the file cannot be queried before first
establishing a new session. I've not found this to be a big deal.

This has been my "daily driver" for about a month at this point, and
overall I'm very happy with the experience. It creates a nearly transparent
experience editing remote files, and retains most of acme's functionality
in remote settings as well. I never hesitate to shut my laptop lid while in
the middle of a project. Most things just work. There are wrinkles, of
course, and there are some sharp edges in this (experimental)
implementation, but, to me, this provides really very useful functionality
that lets me use acme in more challenging environments. (Not to mention
that this means I can use a beefy remote host for heavy lifting.)

In case this would be useful to anyone else, this version of acme resides
in my plan9port tree on github
<https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme>.
(Currently, these diffs: 1
<https://github.com/mariusae/plan9port/commit/dd56712c9d09fc89e8cb0e0b2ead42e1d52698cd#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
2
<https://github.com/mariusae/plan9port/commit/a74049761a902a88502c9dfd3acd3f97591073d5#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
3
<https://github.com/mariusae/plan9port/commit/edeba6c4cb652f99d4de79d151fd94b8eea7988f#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
4
<https://github.com/mariusae/plan9port/commit/2fa8e435b6fedb7914bb6a2d7e1f48bba784ccdb#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>
.)

-m.

(And of course, I realize that this approach goes against the spirit of
acme and plan9 -- acmesrv here is recreating a very specific slice of
functionality that could be recreated by standard means if we had real
filesystems. But we don't live in that world, and this is immensely useful
to me.)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5915 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] plan9port: acme remoting
  2021-01-04  4:40 [9fans] plan9port: acme remoting marius a. eriksen
@ 2021-01-04 11:00 ` Ole-Hjalmar Kristensen
  2021-01-04 11:43   ` Pouya Tafti
  2021-01-05  3:01 ` Lyndon Nerenberg
  1 sibling, 1 reply; 5+ messages in thread
From: Ole-Hjalmar Kristensen @ 2021-01-04 11:00 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 6050 bytes --]

Very interesting. In the past, I have resorted to using a combination of
Sam/9term/plumber in similar scenarios, but I really prefer Acme. At the
moment I'm running Acme over X11, since I'm constrained to using Windows on
the desktop, and I've got a working X server, but no Acme on Windows.
Anyone got plan9port to work under Cygwin?

On Mon, Jan 4, 2021 at 5:41 AM marius a. eriksen <marius@monkey.org> wrote:

> Lately, I have needed to do a great deal of my work on remote servers.
> It's been difficult to do this with acme. Previously, I have attempted to
> run acme entirely remotely, and then attach to a local devdraw instance
> <https://github.com/mariusae/devdrawserver>. This works okay, but also
> has many drawbacks, among which: (1) it's not economical with networking,
> and so not great for high latency or otherwise poor connections; (2) it's
> not resilient to connection disconnects; (3) often I want access to local
> resources too.
>
> I built an experimental remoting layer in acme to see how far I could get
> in recreating a modern "remoting" experience with acme. Since acme itself,
> of course, is designed around a bunch of 9p servers, this turned out to be
> fairly easy to do, and the resulting experience is nearly transparent.
>
> A remote may be attached to one or more path prefixes. These are similar
> to mount points in a file system. Thus, if the prefix /home/meriksen is
> attached to the remote "dev", then any file with this prefix is transparely
> fetched from the dev. Similarly, when commands are run from any directory
> with this prefix, the command is transparently run on the remote. The
> command is run in an environment that includes the acme and plumber 9p
> servers (forwarded from the local host), and so even acme programs just
> work. For example, if you run 'win' from a directory that is attached to a
> remote, 'win' is run on the remote host, but it accesses the acme 9p file
> tree (which is forwarded from the local acme) and creates its window and
> interacts with acme. It "just works". (I regularly run other programs like
> this too, e.g., acme-lsp, which uses the plumber to coordinate interaction).
>
> The design of the feature is quite simple: a new program, acmesrv
> <https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme/acmesrv> is
> run by acme (through ssh) on the remote host. Acme becomes a client of
> acmesrv, through which all further interaction is facilitated. Acmesrv
> itself is really just a 9p multiplexer: the local acme program exports the
> acme and plumber 9p servers; acmesrv provides two new 9p servers (exportfs
> and cmdfs) that gives the local acme access to the remote's file system
> (exportfs) and to run commands (cmdfs).
>
> The local acme manages a session for each remote, and properly deals with
> session disconnect/reconnect, etc. Thus, poor network conditions and
> disconnects are easily supported. Since acme's file handling is anyway
> stateless (the file is not kept open during editing), file state is easily
> maintained through disconnect-reconnect cycles.
>
> There are some synchronous code paths in acme, and these may cause
> temporary freezes when using remoting. For example, when acme queries for
> the existence of a file (stat), this blocks UI updates in acme. On session
> establishment (e.g., the first time a file is accessed on a remote), this
> can cause additional delays, since the file cannot be queried before first
> establishing a new session. I've not found this to be a big deal.
>
> This has been my "daily driver" for about a month at this point, and
> overall I'm very happy with the experience. It creates a nearly transparent
> experience editing remote files, and retains most of acme's functionality
> in remote settings as well. I never hesitate to shut my laptop lid while in
> the middle of a project. Most things just work. There are wrinkles, of
> course, and there are some sharp edges in this (experimental)
> implementation, but, to me, this provides really very useful functionality
> that lets me use acme in more challenging environments. (Not to mention
> that this means I can use a beefy remote host for heavy lifting.)
>
> In case this would be useful to anyone else, this version of acme resides
> in my plan9port tree on github
> <https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme>.
> (Currently, these diffs: 1
> <https://github.com/mariusae/plan9port/commit/dd56712c9d09fc89e8cb0e0b2ead42e1d52698cd#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
> 2
> <https://github.com/mariusae/plan9port/commit/a74049761a902a88502c9dfd3acd3f97591073d5#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
> 3
> <https://github.com/mariusae/plan9port/commit/edeba6c4cb652f99d4de79d151fd94b8eea7988f#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
> 4
> <https://github.com/mariusae/plan9port/commit/2fa8e435b6fedb7914bb6a2d7e1f48bba784ccdb#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>
> .)
>
> -m.
>
> (And of course, I realize that this approach goes against the spirit of
> acme and plan9 -- acmesrv here is recreating a very specific slice of
> functionality that could be recreated by standard means if we had real
> filesystems. But we don't live in that world, and this is immensely useful
> to me.)
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-M1347b1d8513480d11627e4eb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6731 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] plan9port: acme remoting
  2021-01-04 11:00 ` Ole-Hjalmar Kristensen
@ 2021-01-04 11:43   ` Pouya Tafti
  2021-01-04 12:58     ` Semyon Novikov
  0 siblings, 1 reply; 5+ messages in thread
From: Pouya Tafti @ 2021-01-04 11:43 UTC (permalink / raw)
  To: 9fans

On Mon, 4 Jan 2021, at 12:00, Ole-Hjalmar Kristensen wrote:
> Anyone got plan9port to work under Cygwin?

Never tried it on Cygwin, but I once had the misfortune of having to use Windows for work and got p9p to work on WSL w/o much trouble afaicr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcac494e4a963278fdb5b31b1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] plan9port: acme remoting
  2021-01-04 11:43   ` Pouya Tafti
@ 2021-01-04 12:58     ` Semyon Novikov
  0 siblings, 0 replies; 5+ messages in thread
From: Semyon Novikov @ 2021-01-04 12:58 UTC (permalink / raw)
  To: 9fans

Same here, works flawlessly with WSL2 and VcXsrv.
Also there is an option of Edwood, but it's not quite worked well for me in the past.

On Mon, 4 Jan 2021, at 14:43, Pouya Tafti wrote:
> On Mon, 4 Jan 2021, at 12:00, Ole-Hjalmar Kristensen wrote:
> > Anyone got plan9port to work under Cygwin?
> 
> Never tried it on Cygwin, but I once had the misfortune of having to
> use Windows for work and got p9p to work on WSL w/o much trouble afaicr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-M29e6fd3ba30aefcd492daeb0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] plan9port: acme remoting
  2021-01-04  4:40 [9fans] plan9port: acme remoting marius a. eriksen
  2021-01-04 11:00 ` Ole-Hjalmar Kristensen
@ 2021-01-05  3:01 ` Lyndon Nerenberg
  1 sibling, 0 replies; 5+ messages in thread
From: Lyndon Nerenberg @ 2021-01-05  3:01 UTC (permalink / raw)
  To: 9fans

I've always just used aan(8) + cfs(4) for this sort of situation.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mb3f8fff0efe927f263afe55f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-01-05  3:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-04  4:40 [9fans] plan9port: acme remoting marius a. eriksen
2021-01-04 11:00 ` Ole-Hjalmar Kristensen
2021-01-04 11:43   ` Pouya Tafti
2021-01-04 12:58     ` Semyon Novikov
2021-01-05  3:01 ` Lyndon Nerenberg

9fans - fans of the OS Plan 9 from Bell Labs

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9fans

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9fans 9fans/ http://inbox.vuxu.org/9fans \
		9fans@9fans.net
	public-inbox-index 9fans

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9fans


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git