From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 85636215C2 for ; Wed, 8 May 2024 10:43:25 +0200 (CEST) Received: from dpmailmta01.doteasy.com ([65.61.219.2]) by 9front; Wed May 8 04:39:50 -0400 2024 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=192.168.101.81; Received: from dpmailrp01.doteasy.com (unverified [192.168.101.81]) by dpmailmta01.doteasy.com (DEO) with ESMTP id 134559828-1394429 for <9front@9front.org>; Wed, 08 May 2024 01:39:41 -0700 Received: from dpmail01.doteasy.com (dpmail01.doteasy.com [192.168.101.1]) by dpmailrp01.doteasy.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTP id 4488deIl015666 for <9front@9front.org>; Wed, 8 May 2024 01:39:41 -0700 X-SmarterMail-Authenticated-As: fde101@fjrhome.net Received: from [192.168.1.95] (pool-173-67-134-57.hrbgpa.fios.verizon.net [173.67.134.57]) by dpmail01.doteasy.com with SMTP (version=Tls12 cipher=Aes256 bits=256); Wed, 8 May 2024 01:39:23 -0700 Message-ID: Date: Wed, 8 May 2024 04:39:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: Content-Language: en-US From: "Frank D. Engel, Jr." In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Exim-Id: e377d7a0-2adf-404a-ad33-4119637d4150 X-Bayes-Prob: 0.5 (Score 0, tokens from: base:default, @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.1 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01ckwDF2F - 362be4e80a65 - 20240508 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.81 X-Originating-IP: 192.168.101.81 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: overflow-preventing asynchronous replication just-in-time backend Subject: Re: [9front] Enabling a service Reply-To: 9front@9front.org Precedence: bulk Some of this latency problem might be helped, at least for reading, by keeping a local cache of the data in the remote file system. Fossil/venti may actually suggest a way of doing this. Think of having blocks of data cached locally in a modified venti structure based on (usage_time, venti-hash, data_block), such that instead of making the data permanent, data with a sufficiently old usage_time may simply be overwritten when more space is needed, and the usage_time is updated when the data is used again. The fossil remote filesystem would be fossil-like, holding the hash for the data blocks, such that data written to it is write-through from the remote (laptop) end of things, being written to the cache using the calculated hash (yes, that rhymes) as well as sent to the disk server across the (latent) network; when data needs to be retrieved, it obtains the hash from the remote side, then checks the local cache to see if a copy is available.  If so, it can simply use the local copy it has from the cache, otherwise it requests it from the other end. On 5/8/24 00:09, sl@stanleylieber.com wrote: >> Contrary to many people's experience, I actually find >> that for the kind of latency I get over coffee shop wifi >> to my home, remote rio sessions behave fairly well (though >> displaying static images is quite painful). > but this doesn't actually sound contrary. > > text is generally fine, even in drawterm-over-the-internet. it's when > you try to work with anything other than text that life gets hectic. > i never had a lot of complaints until plan 9 became more than a text > editor for me and i started trying to live in it full-time. > > people nowadays are doing a lot more with their plan 9 than they were > even when we started 9front. but most of that stuff is either too > painful to be practical or flat out impossible unless your constituent > distributed parts live close together on a fast network. > > the end result is that many of the very cool features we come to plan > 9 for in the first place are pretty much useless most of the time. > and this drives travelers to just running stand alone systems. > > this inherent tension between "plan 9 is a distributed environment" > and "nobody expected us to be quite *that* distributed" remains > unresolved, and largely unaddressed. it's not really a fault of the > original concept, but it does expose weaknesses (or, perhaps more > accurately, period appropriate shortsightedness nobody could blame > them for) in the specific implementations of various components. > > i like the suggestions made so far about automatic caching schemes. i > have played around with cfs partitions, but that mechanism at least > never seems to deliver the promised results. > > sl >