[-- 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 --]
[-- 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 --]
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
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
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