I'd like to be able to disconnect from drawterm session and pick up where I left off. In an ideal world, I'd be able to switch between graphical sessions on the fly and have sessions running in the background like one can on unix ttys with tmux and with a simple enough interface. I'm pledging 200 USD for this. Thanks.
Quoth Larkin Nickle <me@larbob.org>:
> I'd like to be able to disconnect from drawterm session and pick up
> where I left off. In an ideal world, I'd be able to switch between
> graphical sessions on the fly and have sessions running in the
> background like one can on unix ttys with tmux and with a simple enough
> interface. I'm pledging 200 USD for this. Thanks.
I use multiple vncs sessions for this. It works quite
well and I don't need to port drawterm to all niche
platforms I use.
Michael
On 7/8/22 15:24, michael.grunditz@gmail.com wrote:
> Quoth Larkin Nickle <me@larbob.org>:
>> I'd like to be able to disconnect from drawterm session and pick up
>> where I left off. In an ideal world, I'd be able to switch between
>> graphical sessions on the fly and have sessions running in the
>> background like one can on unix ttys with tmux and with a simple enough
>> interface. I'm pledging 200 USD for this. Thanks.
>
> I use multiple vncs sessions for this. It works quite
> well and I don't need to port drawterm to all niche
> platforms I use.
>
> Michael
Yep, things like Xpra or VNC or whatever to another machine work for
now, but a native solution would be much nicer in my opinion.
On July 8, 2022 3:33:24 PM EDT, Larkin Nickle <me@larbob.org> wrote:
>On 7/8/22 15:24, michael.grunditz@gmail.com wrote:
>> Quoth Larkin Nickle <me@larbob.org>:
>>> I'd like to be able to disconnect from drawterm session and pick up
>>> where I left off. In an ideal world, I'd be able to switch between
>>> graphical sessions on the fly and have sessions running in the
>>> background like one can on unix ttys with tmux and with a simple enough
>>> interface. I'm pledging 200 USD for this. Thanks.
>>
>> I use multiple vncs sessions for this. It works quite
>> well and I don't need to port drawterm to all niche
>> platforms I use.
>>
>> Michael
>
>Yep, things like Xpra or VNC or whatever to another machine work for now, but a native solution would be much nicer in my opinion.
>
why?
vnc gives you everything but /mnt/term/, even shared snarf buffer.
sl
On Fri, Jul 08, 2022 at 03:40:59PM -0400, Stanley Lieber wrote: > why? Well, > vnc gives you everything but /mnt/term/, even shared snarf buffer. and I want /mnt/term. khm
>
> why?
>
> vnc gives you everything but /mnt/term/, even shared snarf buffer.
>
> sl
>
also no audio, os command, ann and worse performance compered to
drawterm in poor connections.
Audio, performance, /mnt/term, convenience.
On July 8, 2022 3:51:09 PM EDT, mkf9 <mkf9@riseup.net> wrote:
>>
>> why?
>>
>> vnc gives you everything but /mnt/term/, even shared snarf buffer.
>>
>> sl
>>
>
>also no audio, os command, ann and worse performance compered to drawterm in poor connections.
>
my experience with poor connections has been the opposite, especially with stuff like webfs and mothra.
for some reason I thought our vnc supported audio (obviously, I've never tried to use it).
/mnt/term is a sticking point, I guess.
sl
> my experience with poor connections has been the opposite, especially with stuff like webfs and mothra.
> how it's affects drawterm's performance?
> my experience with poor connections has been the opposite, especially with stuff like webfs and mothra. Fair enough, but from my experience I prefer drawterm. > > for some reason I thought our vnc supported audio (obviously, I've never tried to use it). Don't see anything about it in the man page, but maybe. Regardless, /mnt/term would be very nice as well. > > /mnt/term is a sticking point, I guess. Yep. Also, if I'm using someone else's box, it might be bad etiquette to start spawning vnc servers (for example sdf 9 bootcamp server, which is genuinely multiuser). And less seriously, I just think this would be cool.
How would open fd's to files and binds to things in /mnt/term be
handled on reconnect on a different machine with a different
/mnt/term?
Maybe fixing vnc audio is a better bounty for now.
On Fri, Jul 8, 2022 at 1:50 PM Larkin Nickle <me@larbob.org> wrote:
>
> I'd like to be able to disconnect from drawterm session and pick up
> where I left off. In an ideal world, I'd be able to switch between
> graphical sessions on the fly and have sessions running in the
> background like one can on unix ttys with tmux and with a simple enough
> interface. I'm pledging 200 USD for this. Thanks.
On 7/8/22, Thaddeus Woskowiak <tswoskowiak@gmail.com> wrote:
> How would open fd's to files and binds to things in /mnt/term be
> handled on reconnect on a different machine with a different
> /mnt/term?
that's a great question.
i never noticed this problem.
the things that are always required from /mnt/term/dev (kbd, mouse,
draw) have to be handled specifically. i made a prototype for that
once. most of the work went to draw as the OP seems to also be aware
of :)
about the performance discussion: i agree that mothra sucks over
drawterm, that's because huge uncompressed images are being
transferred over 9p in relatively small chunks without any form of
streaming/pre-fetching, so it becomes latency-bottlenecked.
otoh: if you mostly have text rio/sam windows open and no modern
multimedia stuff (no pdf, no images/mothra), drawterm saves a lot of
*bandwidth*. i've been using it on 64kbit and 128kbit connections and
as long as your latency is alright (over LTE i had 30ms to my 9front
vps in france), it's super snappy.
if you do all the work required for the draw detach, then you can kick
out draw clients that cannot keep up with the draw updates,
effectively limiting their outstanding draw RPCs, and then batch
everything like in the reconnect-attach process, effectively removing
latency-bottlenecks, in other words, the clients become asynchronous
and thus the main draw can continue much faster (being local, network
delay wouldn't effect draw anymore).
you could also micro-manage this, compress all uncompressed Dimages
before syncing to the clients, and even more involved: only transmit
differences after re-attach.
also, i'd prefer if mothra and page didn't decode jpegs and instead
devdraw got support for that compression format.
i have a prototype that's super hacky, i didn't really want to go on
before we have a good generalized streaming solution e.g. for
something simple like distributed pipes.
and the compression part is too hard for me, too :D
also thought burnzez would report back his findings after he tested my
prototype. but i guess it was too hacky :D
now that there's clear interest expressed in true currency values i
might think about cleaning it up and finding other non-9p-layer
workarounds for speeding up streaming for my few specific cases. i'll
not do the compression or other crazy ideas i described above though.
On 2022-07-08 16:28, Thaddeus Woskowiak wrote:
> How would open fd's to files and binds to things in /mnt/term be
> handled on reconnect on a different machine with a different
> /mnt/term?
>
> Maybe fixing vnc audio is a better bounty for now.
>
Maybe fair, but I'll stick to my bounty as I'd have more of a use for it.
In terms of the filesystem, for my own uses, I'd be fine with just
expecting the user to not have anything open from the terminal's fs when
disconnecting and putting the onus on them as much as possible. As hiro
said, /mnt/term/dev is a different story.
On 2022-07-08 16:51, hiro wrote:
> now that there's clear interest expressed in true currency values i
> might think about cleaning it up and finding other non-9p-layer
> workarounds for speeding up streaming for my few specific cases.
Would be great!
Thaddeus Woskowiak wrote:
> How would open fd's to files and binds to things in /mnt/term be
> handled on reconnect on a different machine with a different
> /mnt/term?
>
> Maybe fixing vnc audio is a better bounty for now.
I don't think vnc supports any form audio at all.
some vnc clients/servers use hacks with pulseaudio and things like that.
maybe having a sndio server could work in our case?
> also, i'd prefer if mothra and page didn't decode jpegs and instead
> devdraw got support for that compression format.
>
> i have a prototype that's super hacky, i didn't really want to go on
> before we have a good generalized streaming solution e.g. for
> something simple like distributed pipes.
> and the compression part is too hard for me, too :D
Can I try the prototype? :D I've already been trying to get a VPS as close as possible for lower latency but it's still not as fast like on a local network