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 0C99121D20 for ; Wed, 8 May 2024 02:39:13 +0200 (CEST) Received: from gaff.inri.net ([168.235.71.243]) by 9front; Tue May 7 20:35:21 -0400 2024 Message-ID: <021A5DC3A3EB95E2C477B02B69C922D3@gaff.inri.net> Date: Tue, 07 May 2024 20:35:21 -0400 From: sl@stanleylieber.com To: 9front@9front.org In-Reply-To: <8557C94F-E6DF-42BA-B92E-6BBB0751116A@ecloud.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: object-oriented shared shader-oriented deep-learning-aware control Subject: Re: [9front] Enabling a service Reply-To: 9front@9front.org Precedence: bulk > And yet, the FQA recommends laptops. the fqa lists hardware that is known to work. most users who start out with hardware that doesn't work never get to the stage of complaining about what the installer does and doesn't do. i keep track of the stuff i've used, and share that information, just in case someone else stumbles across the same machines. if you'd prefer to get a taste of the pre- fqa3 plan 9 experience, you can buy a random laptop manufactured in 2024 and report back on its status, re: booting and running 9front. if you do that, i'll add the information to the hardware inventory linked in fqa3. if instead you'd prefer the pre- 9front experience, you can keep this information all to yourself and nobody will ever know what you accomplished. for the highest level of fidelity to the pre- 9front experience, you could opt to brag vaguely about all the cool stuff you got working on your computer, but never, ever make details or source code available to the general public. bonus if you lord any of this over the newbs who are even newer to plan 9 than you are, assuring them that, yes, all these wonderful things you're claiming you did are trivial to accomplish in plan 9. laptops are useful beyond the obvious use case because of they come with built-in battery power. > Usually the assumption with a > laptop is you can take it on the subway or to the coffee shop and keep > working. you'd think so, right? but if you read through the 9fans archives, labs people basically blew off laptop problems as being irrelevant to plan 9. the system as designed never accounted for most the things people today want to do with laptops, and not only because the system assumes fast access to the disk file server. here are some other unsolved, laptop-specific problems you'll encounter: - how do i sleep and resume? (we don't do state) - how do i lock my screen? (this exists, but relies on the network, lol) > That implies that you want to have some relevant files with > you. (So it’s good the default install has a local filesystem.) Then > later you get back to the home/office and maybe want to use a machine > with a bigger monitor and more files available, but some work in > progress is on the laptop so maybe you want to rcpu to it for a while. > Eventually files get synced up again (manually or automatically). > Maybe at home there is a file server, sure it’s good to have the > dumps. That’s probably how I’d use it as soon as I get to the point > of depending on Plan 9 for any particular task, not just trying > things. (It reminds me of learning how to use Linux, 30 years ago. > It was at a similar level of development back then.) it's funny because all of this started with rob's experiments with graphical terminals. the terminal itself ran a small, custom operating system that would be downloaded from the server at the start of a session. the user would do operations on data in local memory, periodically syncing with the remote file server over the network. there is a remnant of this design in how the sam editor's gui operates on files. and of course, plan 9 itself. for many years i ran diskless terminals at home over wired ethernet and wifi. it was great because my environment was always the same, my files were always exactly where i left them, and when i was finished i could just power off the machine without worrying about unclean shutdowns. some people say, we have drawterm, best of both worlds! but drawterm also sucks when there's latency. moody may run doom in drawterm over local ethernet, but that's not happening over the internet. today, i'm almost always remote, in different places at different times. my network is a wifi access point provided by my mobile phone. over many years i've tried lots of different ways of running plan 9 with this setup, from tls booting over the internet, to drawterm<->9front running in a local qemu on openbsd, etc., etc. what i typically do now is boot my laptop from a local disk (so, local binaries), but all my critical work files live on the remove disk file server i physically operate at home. sometimes this is painfully slow, so i'll work on files on the local disk and then sync them up. i never, ever, need to rcpu into my terminal. i just do whatever syncing is necessary before i turn it off. if i need a modern web browser, i connect to openbsd over ssh/vnc (which is also sometimes painfully slow). this is far from ideal but works better than the other combinations i've tried so far. pick this apart, but this is me telling you what worked and didn't work for me, and i'm happy to answer questions in detail. > trying to preserve the labs experience personally, i don't care at all about preserving the labs experience. we already dumped fossil, made tons of changes. but before you start proposing all sorts of changes to the system it's important to understand exactly what you're changing. plan 9 was not designed by idiots, or by accident. everything that went in is the way it is for a reason. you may disagree with the reason, but it's important to understand that reason before blowing it off. and yes, people involved with 9front will challenge you on every little detail, because the details are important, and that's why we're all here. this isn't linux. > I agree that setting up a mail server should be more effort. turning on listeners by default is bad practice. by now, all operating systems err on the side of this principle. obviously, there is leeway here when it comes to services needed to actually use the system. >> 9p vs latency is a losing battle. trying to run a diskless terminal >> over the internet really, REALLY sucks. even drawterm is not great >> in this context. > > I left a 9front machine running on my LAN in Norway while I’m in > Phoenix for a while, and set up a wireguard vpn on the openwrt router > in Norway so that I can connect to home. Latency in Phoenix is worse > than normal (Verizon wireless internet: it's only meant to be > temporary). Despite that, the performance I see connecting with rcpu > or drawterm halfway around the world is comparable to connecting to > Linux over VNC: not bad for an experiment (as long as wifi on 9front > is not in the path! ;-) I don’t expect to play video over that link. > But I also have qualms about letting the router connect 9p over the > Internet to that Plan 9 machine, since I don’t know yet all the > varieties of half-assedness to expect by default. I think I have to > try the Plan 9 network forwarding at some point though, see if the > claim that it’s as good as a VPN really holds up. But I have to learn > enough about security before even trying, it seems. for a while i was actually carrying around an ipad and connecting to 9front with vnc over ssh: ipad -> internet -> openbsd/ssh -> ethernet -> 9front/vncs this probably worked better than any other remote internet setup i ever tried. of course, you get none of the local plan 9 benefits that way. and no sound. sl