I disagree with this also, but the latter was so obviously wrong that I figured I should leave a reply. We are separate projects and what Asahi does is their business, our interactions will be in upstream projects and follow upstream guidelines.

Asahi’s approach avoids any use of AI coding agents, etc at all (even for debugging, testing, and so forth). The amount of work/effort the Asahi team did for M1/M2/M3 is near superhuman, and M4 is gonna take all that effort again, since Apple likes to change things, a lot, and doesn’t really document their hardware device interfaces in detail.

Gravity approaches this with an attitude that using an LLM is indeed allowed (per upstream Linux contribute requirements), particularly for analysis, debugging and testing. The goal is to get M4 support contributed back to to the upstream kernel. (And eventually M5, M6, A18…)

Ideally, the documentation about hardware interfaces from this project could be used for other people who want to write kernel drivers for Linux or even for other operating systems. It’s mostly a matter of documenting what the device interface actually is.

None of this would be possible without Asahi’s foundational work and techniques to make clean room reverse engineering possible. Despite differences on opinions about AI, I can’t stress the quality of their work or the effort they’ve put in enough.

Asahi does not use Arch.

It formally made Fedora its official partner three years ago as I reported at the time:

https://www.theregister.com/software/2023/08/07/asahi-linux-...

It does also support 10 other distros, listed here:

https://leo3418.github.io/asahi-wiki-build/swalternative-dis...

(Deepin is there twice.)

Note, Arch is not on that list.

Asahi is available in a variety of distros, too.