On 6/3/25 05:42, hiro wrote: >> 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.
This is not the same thing, we do not have a /ape. So do we put a .md file in the root of every 9front install and then add /sys/src/unix? Sorry I disagree, that sucks. >> 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. Ape is different then this, ape is a unix interface written for plan 9, _that can be tested on plan 9_, you don't need a different system to test it. > > i'm not gonna pretend this leads to great quality, but low-tier help > for alien interop. is better than none. No it's not, I'd rather ship nothing then ship unmaintained and buggy scripts. Will you be the one to sit around irc all day and take user complaints that their super elite tricked out linux doesn't work with these scripts? >> 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. Ape is maintained, we build it and its associated tools as part of the nightly builds. Ape is not the same thing as some alien linux scripts, writing tests and validation for ape is just like any other plan 9 code. Ape has also been in our sights for a long time for removal, people don't like that it has parallels that bitrot more easily. There has been a desire to remove this exact problem that you would like to excuse. > > imo test-driven development is extremely overrated, and mostly > implemented only superficially. This is not test-driven development this is a method of verifying that the code we put in the repo works. I understand that it seems you don't quite find that valuable, but "I dont care for testing" is not a compelling argument for putting _more_ potentially unmaintained code in our repo. Folks currently writing 9front code find tests useful, its going to be hard to change their mind with just like your opinion man. >> 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. I know you've been away from this for a while, but our current "ci" of the nightly box has already spotted quite a lot of screwups and little bugs. It's useful, most people who are writing code for the system find it useful. It already exists. It's not complicated, its a bunch of small rc scripts. If we were to add this other stuff, it would get quite complicated. I'd rather have everything in the repo testable by a 9front machine then just add stuff and say "well testing is too complicated, too bad, maybe it breaks, you get what you get" I hold our repository to a higher standard then that. >> 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? Ape? Absolutely, we already do with compiling it and the other utilities that use it, I'd love to see more ape tests if we plan on keeping it around, but at this point that is not entirely clear. We don't ship equis with the system so I'm not sure why you mentioned that. vt and ssh tests? Again, absolutely. We ship them, they can be tested from 9front. I'd love to see 9front grow an in-tree ssh server and us doing some testing of back and forth conversations. > all this just dips in way too > deep in the magma lakes of alien computing interoperability hell. We need to draw the line somewhere, I tend to draw it "what we ship should work" That so far has an already established path for verification and testing. My point is that the path for testing code and scripts that don't in anyway run on 9front is a much different challenge. > some of this is surprisingly well maintained lately, but full > end-to-end tests would require too much complexity, and even more > alien hell. Yes because we don't shift out things from under people and what we choose to hang our hat off of (ssh) does not drastically change year over year because openbsd largely does a good job as its shepherd. For linux scripts, do we assume X11 or wayland? Do we assume red-haty or ubuntu-y? Do we assume systemd and pulse audio or s6 and pipewire? Do we support everything and have a matrix of configuration knobs for every possible elite linux setup? I work on 9front so I don't have to deal with that mess and maintaining stuff like that. Every handful of years linux changes expectations out from under you. Putting alien scripts directly in to our repo ties us much closer to this treadmill then I would like. >> 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. I want our users to expect better of things we ship in the repository, not less. If it's easy to ignore then its also going to be easy to miss from an outsider looking in. Either you wind up with an annoying /README.md on every 9front root filesystem or you'll have /sys/src/unix and no one will know it's there. Putting a markdown file in the root of everyone's install is a much worse solution then having some linux users deal with submodules or whatever. If linux users think that's a mess that's on them to fix, not on us to clutter our repo for their convenience. >> 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. Where did you get that number? I'd be curious to see the information that lead you to that conclusion. This is something we're actively working on improving, we have plans to replace ghostscript, we've continued to make progress towards removing ape reliance over the years. I would rather that continue to shrink instead of grow. > > 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? We don't ship the FQA as /fqa in the install. > > 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. Different solutions to different problems, we're going to commit changes to htmlroff to make things more copy-pastable. I agree that testing all the fqa examples is not easy, but because its in its own repo it is much easier to draw that line. >> 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. The line is fairly clear right now. The only thing we ship in 9front that is for non-9front's is the unix build for rc. Of which cinap also maintains a separate repo for. I'm sorry, but this conversation has not convinced me that this is the right way forward. If there were concrete patches and promises of "yes I will personally be there to keep up with the linux treadmill and debug linux user issues" to ensure that stuff keeps working and we don't end up with this vestigial tail of good intentions, I would perhaps be more open to the conversation. I don't think baking in scripts to 9front even prevents you from this issue of having to worry about external git repos. We use u-boot for booting arm64 qemu, right now that requires you to build that from source. Does 9front vendor u-boot (please no), do we use submodules (can't), ship scripts that clone it and deal with it ourselves (still sucks). Do we vendor drawterm as well? Do we vendor everything that drawterm needs that might not be packaged on elite hacker linux? I am saying no here because I can foresee the mess of doing this, but these kind of specific details come out in the process of doing this work. I could be wrong here, but it would take patches and not words to change my mind. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M9830f2885ef7cf1e05baf490 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
