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-Mf9d3be907a7724e6075445ec Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
