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.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31811 invoked from network); 24 Aug 2022 18:58:11 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 24 Aug 2022 18:58:11 -0000 Received: from orthanc.ca ([208.79.93.154]) by 9front; Wed Aug 24 14:56:29 -0400 2022 Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id 51c24e74; Wed, 24 Aug 2022 11:56:28 -0700 (PDT) From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" To: 9front@9front.org, ori@eigenstate.org In-reply-to: References: Comments: In-reply-to ori@eigenstate.org message dated "Wed, 24 Aug 2022 13:37:03 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16352.1661367387.1@orthanc.ca> Date: Wed, 24 Aug 2022 11:56:27 -0700 Message-ID: <6381c6d9cb1ff9f2@orthanc.ca> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: responsive factory replication hosting Subject: Re: [9front] [PATCH] programmable menus for rio Reply-To: 9front@9front.org Precedence: bulk ori@eigenstate.org writes: > At the same time, I've got some hesitation because this > is part of the rio interface -- and the more we add to > the rio interface, the less it becomes a general interface > it becomes. I'm with Ori on this. > In the past, there's been talk of a notebook style rio > replacement, and every knob and feature we add to rio > would become something that we'd need to fit into (or > shoehorn into) this hypothetical rio alternative. Given that rio has had a couple of decades to bake, the world has changed around it, and thinking of new stuff is always a good idea. But diddling with rio just seems a path to feechur bloat. If you really want to try new things, it's best to start from the ground up (IMO). But the joy of rio is you can write and experiment with your new stuff inside of rio, without breaking your existing environment. But what I *am* really reluctant to embrace is thowing new files into /dev in a willy-nilly fashion. The current scheme for /dev files and how they get used has some deep thought behind it, and I think anyone should think long and hard about how new facilities can be merged into the existing interfaces before throwing new files at /dev (or anywhere else). As always, try to solve for the general case. --lyndon