Re: [9fans] Re: An easy way to run 9legacy

[Eli Cohen <echoline@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]

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 <rminnich@p9f.org> 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 <moody@posixcafe.org> 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

[-- Attachment #2: Type: text/html, Size: 5150 bytes --]