From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28892 invoked from network); 8 Jul 2022 20:54:11 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 8 Jul 2022 20:54:11 -0000 Received: from mail-ua1-f51.google.com ([209.85.222.51]) by 9front; Fri Jul 8 16:51:50 -0400 2022 Received: by mail-ua1-f51.google.com with SMTP id s38so6155733uac.6 for <9front@9front.org>; Fri, 08 Jul 2022 13:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=40cziDgodQ08r5SEkZubivSqVdhwJboiiFlZbrcxs30=; b=LVFIb2N3QqZGXcIOPWSOq3tZtvSNCjTiQJbF7+DFNzVcmQoomyjkXFkVkNx70fcgwJ FmC8rxQIARs/aeCtXDwA2R242gFinXSLYZ6pbhGgMlQphiLBcIjxVF1UBaPyIuUVTPtW KnsvGNq2HxLmKcu8Ki6va8NW9nEItzei+cZnEiQ17M45HF+CFariSg6jQnqeu2fhcejX R6J6ZnKDz3XWqY/USaap9n/Q6HqmCiOW0ZzgABCW5acDrz5RHso6Z7CzRe+L8yZFMSMh t+YQ3pG/UfN3wgwfYqLWDV9945/ZGa3kIcm+LXUzLm/t8KT5tplBZpgBFptNQpsq49S+ DaGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=40cziDgodQ08r5SEkZubivSqVdhwJboiiFlZbrcxs30=; b=7DqU5PW5X/8NiaiiMYD8wzPgAB8SdlbEHCOHxoB2zwyEl+TMajD1wmvXupPv8Wcio4 QQLBKxy5pCS1gkvyngRYrdQdQgq35JKA/yRhDgDvGgZ5KIz4+RlYua1FUzG/mAEVQMI/ 8HlfUZEZdF0f/1LH455zOo6IFTZxQZLHGfGwdpnHQmYFjKH8ssvObYD5hoEmMSkK9Y8Y AQThudPymtfPn6SLjK32DltcZTUfOq7OtszHZrcg3fzngFlhEoo1bgbq9z8yYVBTFSvu ckeU4wPPsmx2HIyVrvJW8ncYLvEDNZCmuvn4TqqfTx0+TUcPrMyaPGgHJ+I19VEUqVjX juQQ== X-Gm-Message-State: AJIora+NPivHiFmb7xHzfYCMfgzLIvboC/NNh4nyvU1PY+zXk5Khlczx IZGfiT5y8/RUlMces3JC1zXU8Mku8I5k15lzFH9D3wIW X-Google-Smtp-Source: AGRyM1tYJSW+utb17WPlF4WMV2F43vAehjdUodbDz9BjTvh4BsT1a0SLzGdVn+JYp0ZSURU7U84XoJBUFKEwxIjXEno= X-Received: by 2002:ab0:162b:0:b0:382:4733:532c with SMTP id k40-20020ab0162b000000b003824733532cmr2411835uae.62.1657313506769; Fri, 08 Jul 2022 13:51:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9f:2c06:0:0:0:0:0 with HTTP; Fri, 8 Jul 2022 13:51:46 -0700 (PDT) In-Reply-To: References: <76b27c59-d0d5-a733-7182-4aeeebd959ff@larbob.org> From: hiro <23hiro@gmail.com> Date: Fri, 8 Jul 2022 22:51:46 +0200 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: object-oriented generic ActivityPub deep-learning STM generator Subject: Re: [9front] Bounty: tmux-esque /dev/draw intermediary Reply-To: 9front@9front.org Precedence: bulk On 7/8/22, 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? 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.