I've no problem with making the "easy path onto Plan 9" idea external to 9front or any other code base. The role of the foundation is education, and we can consider this a foundation responsibility.
On Mon, Jun 2, 2025 at 12:12 PM Jacob Moody <[email protected]> wrote: > > On 6/2/25 11:23, hiro wrote: > > sorry to disagree moddy, but we already document how to use qemu in > > the 9front fqa. qemu virtualized amd64 is one of the easy ways to boot > > up a real 9front kernel, so i wouldn't say we don't support this > > "target". > > There's a big difference between running a real 9front kernel in > qemu for editing and programming the system and using your own > editor with a locally served(fromt the qemu host) root filesystem. > > > > > i'm happy to see other plan9 folks have returned to actually booting > > real plan9 kernels, even if it's just on a virtualized pc. > > if this goes on people will realize plan9 is more than just a text > > editor (acme) or a filesharing network protocol (9p). > > Agreed, which is why I want to keep pushing for that. I think you > misunderstood my prior email. > > > > > this is something i didn't know about until now: > > guestfwd=tcp:10.0.2.1:564-cmd:../sys/src/cmd/unix/u9fs/u9fs -a none -u > > $USER .. > > > > so, thanks. > > > > i also see no reason to reject alien scripts (bourne shell) that help > > create compatibility. there's no real cost. right now we maintain > > something like this in the fqa, which is bigger overhead (.ms > > formating is painful) and less directly usable (cannot be directly > > executed) by the user. > > The issue is where to put them, do we have a /README.md? > Do we have /alien or /unix? > Do we target everything, and have different scripts for > every linux distro that someone uses? > Who is going to maintain those scripts and test them regularly? > Sure CI can test them, but that doesn't solve the time issue of > fixing the bugs. > Right now you can test the entire repo with just a 9front box, > do we want to expand that so to test everything you also need > 4 different linux installs? > > This stuff gets ugly, I would prefer to not have it baked in to > every 9front install. > > > > > the same cannot be said about submodules. there is significant cost > > for everybody who has to use repos containing submodules. > > That's why I suggested alternatives, there are multiple ways to deal with it. > I'd rather externalize the mess instead of internalize it in to our repo we > ship to everyone. Dealing with messes like this is the every day experience > of computing outside of Plan 9, I don't want to bring that in to the system. > > I want the 9front repo to be primarily for use by 9front machines. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M4c3fba991b79d150454d21a0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
