at some point it's time for one of us to package up our crapola as a linux distribution
On Mon, Jun 2, 2025, 6:40 PM Ron Minnich <[email protected]> wrote: > 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-M6edfda1666582cbbc01c6e11 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
