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

[hiro <23hiro@gmail.com>]

> 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