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

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

[David du Colombier]

This is neat and it should be part of 9legacy soon.

-- 
David du Colombier

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-Mb6862345645e2ae2dd2d03bf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Jacob Moody]

On 6/2/25 02:04, anto@xplshn.com.ar wrote:
> It would be great to have that in the 9front git mirror (https://github.com/9front/9front <https://github.com/9front/9front>)

The 9front git mirror is just that, a mirror of git.9front.org.
I updated stuff to have github actions for syncing largely because
the 9front github org already existed, and github is currently the easiest
way to get free on demand windows and mac hosts to build your stuff.
Since the repos existed I figured they might as well be up to date.

The important thing to consider here is that the main 9front repo is
what we use for updating the install, our sysupdate script is a small
wrapper around git/pull. I would like to avoid adding extra things in
the repo in order to accommodate things like this, they don't really
have a place in the 9front source tree.
I would encourage someone to do this work for 9front as a separate repo;
git submodules or some scripts or whatever floats your boat for referencing
both repositories. I considered doing this myself for the 9front-in-a-box
repo, but my plate is full for the near future.

9front has a strong desire to dog food our own code. I think this is a pretty
important distinction between our project and many other hobbyist operating systems.
We were lucky to inherit a lot of this from Plan 9, but further improvements have
been done to continue this desire. We've lost count of the nasty bugs we found
by actually putting the system to use. Many of purposed improvements to the system
come out of desires that people have when just using the system day-to-day.
There is a certain zen of Plan 9 that you don't fully grasp until you immerse
yourself in the entire picture, editors and window managers included.

While I understand the desire to make things easier for people to bring their
own set of presumed tools with them to work on 9front, I think there is an
established history of Plan 9 rejecting that. Asking people to take off their
coat and stay a while.

Just my two cents on the matter, I put in some thought in about this after Russ
did this work for 9legacy.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M44cf468951c3d9b07f30e4ca
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

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".

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).

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 same cannot be said about submodules. there is significant cost
for everybody who has to use repos containing submodules.

On Mon, Jun 2, 2025 at 11:33 AM Jacob Moody <moody@posixcafe.org> wrote:
>
> On 6/2/25 02:04, anto@xplshn.com.ar wrote:
> > It would be great to have that in the 9front git mirror (https://github.com/9front/9front <https://github.com/9front/9front>)
> 
> The 9front git mirror is just that, a mirror of git.9front.org.
> I updated stuff to have github actions for syncing largely because
> the 9front github org already existed, and github is currently the easiest
> way to get free on demand windows and mac hosts to build your stuff.
> Since the repos existed I figured they might as well be up to date.
> 
> The important thing to consider here is that the main 9front repo is
> what we use for updating the install, our sysupdate script is a small
> wrapper around git/pull. I would like to avoid adding extra things in
> the repo in order to accommodate things like this, they don't really
> have a place in the 9front source tree.
> I would encourage someone to do this work for 9front as a separate repo;
> git submodules or some scripts or whatever floats your boat for referencing
> both repositories. I considered doing this myself for the 9front-in-a-box
> repo, but my plate is full for the near future.
> 
> 9front has a strong desire to dog food our own code. I think this is a pretty
> important distinction between our project and many other hobbyist operating systems.
> We were lucky to inherit a lot of this from Plan 9, but further improvements have
> been done to continue this desire. We've lost count of the nasty bugs we found
> by actually putting the system to use. Many of purposed improvements to the system
> come out of desires that people have when just using the system day-to-day.
> There is a certain zen of Plan 9 that you don't fully grasp until you immerse
> yourself in the entire picture, editors and window managers included.
> 
> While I understand the desire to make things easier for people to bring their
> own set of presumed tools with them to work on 9front, I think there is an
> established history of Plan 9 rejecting that. Asking people to take off their
> coat and stay a while.
> 
> Just my two cents on the matter, I put in some thought in about this after Russ
> did this work for 9legacy.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M6eef868c093815645e40002a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Eli Cohen]

[-- 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 --]

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

[ron minnich]

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

That’s not my goal at all sorry for the misunderstanding.



On Mon, Jun 2, 2025 at 19:49 <ori@eigenstate.org> wrote:

> Quoth Ron Minnich <rminnich@p9f.org>:
> >
> > 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.
> >
> 
> I think the point Moody is trying to make is that whatever
> the "easy path onto Plan 9" is, it probably ought to lead
> to using Plan 9, rather than minimizing contact with it.
> 
> If your goal is to minimize contact with Plan 9, there are
> better ways to do it.
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M2338210ad9ae903605ca8420
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

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

[hiro]

> The issue is where to put them, do we have a /README.md?
> Do we have /alien or /unix?

sounds like a good idea. however it would be called, i'd put it next to ape.

> Do we target everything, and have different scripts for
> every linux distro that someone uses?

sounds good.
i would not try to generalize linux/alien/ape stuff too much as there
are too many distros, but whoever has a tested-working thing for
whatever linux toy might help others by example at the very least.
often it's the same for all relevant distros: most should ship pretty
much the same qemu/kvm interface.

i'm not gonna pretend this leads to great quality, but low-tier help
for alien interop. is better than none.

> Who is going to maintain those scripts and test them regularly?

only a linux user can maintain them. maybe documentation should
mention they frequently become unmaintained, out of date, like we are
also used to with ape. it might help to document which linux distro
and version it worked with at some point.

imo test-driven development is extremely overrated, and mostly
implemented only superficially.

> Sure CI can test them, but that doesn't solve the time issue of
> fixing the bugs.

I dont see CI testing them at all. Sounds way too complicated.

> 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?

Should we also test ape/equis/vt/ssh? all this just dips in way too
deep in the magma lakes of alien computing interoperability hell.
some of this is surprisingly well maintained lately, but full
end-to-end tests would require too much complexity, and even more
alien hell.

> This stuff gets ugly, I would prefer to not have it baked in to
> every 9front install.

as long as users don't expect too much of it, as long as it's
separated in another directory, it should be easy to ignore.

> 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.

over 3/4 of plan9 code is just dealing with messy alien stuff like
non-plan9 computing. interoperability is difficult.

we give a lot of space to the kinds of stuff you are criticizing in
the fqa, i suppose in your view this is not a problem because it's a
different repo?

if your priority is make sure that all the stuff is well tested, i
feel that in the fqa it's harder to test bec. copy&pasting into and
out of the fqa is a bit more tedious than running a script that's
already in a folder somewhere. with the fqa you often end up testing
your quoting/unquoting and copy&pasting skills instead of the actual
code.

> I want the 9front repo to be primarily for use by 9front machines.

this sounds like an interesting request, just i don't see us drawing a
very clear line.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-Mee83eead67892d4a3e13297c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Jens Staal]

On Tuesday, 3 June 2025 20.09.21 Central European Summer Time 
ori@eigenstate.org wrote:
> We don't plan to drop APE without finding a way to migrate the things
> people actually use, either by providing better options (eg, npe for
> porting code that doesn't need select()) or by writing native options
> that remove the need for ape utilities (like patch(1)).

What inspired me to start with APExp (I should get started again after several 
months of pause due to busy work etc) was the prospect/hope that the base 
system might drop it. In a way, this could be a good thing because it also 
means that APE can be expanded and get bigger and messier with the explicit 
goal of compiling "any" POSIX-compliant software (not just the software used 
in the base system), and potential licensing or other NIH bikeshedding is less 
of an issue (it is after all voluntary to use it).

The way I see APExp is something akin to Msys2 on Windows.
(I still need to test/make sure that APExp also works on 9legacy etc)

> 
> The objection to APE isn't having a compatibility layer, but that APE
> has a great deal of duplicated system functionality, and is therefore
> a pain in the butt to maintain.

Indeed. I am super excited about the possibility of npe potentially replacing 
APE in the base system and reducing the duplications in it.

> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M04ec7e680b00061bdf6ff409
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M03e8c1f94daa1f6d2f8e02ee
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription