While I absolutely love the technical write-up from the Asahi team, and being absolutely impressed by their accomplishment, to the risk of being an overly negative contrarian, I remain a bit skeptical.

I'm concerned that after all these years, it's still a separate project and not an effort sustained directly within the kernel mainline and mainstream distributions like Ubuntu, Debian or Fedora.

These kinds of reverse engineering projects are extremely challenging. With skills & field knowledge, it's "easy" to get to "80%" and have something useful for you and the most dedicated users. But reaching the "95%" required for a polished & general public ready experience needs nearly as much effort, often on tedious and time consuming tidbits.

For what it’s worth, Asahi do upstream a lot of changes to do exactly what you’re saying.

That’s a big reason why progress slowed recently because they were focusing on reducing their diff count.

A lot of stuff has landed in the mainline kernel, but Asahi is how they keep experimenting on new functionality.

I think there is also the added challenge that ARM macs are a moving target, and Apple has less than no desire to provide any kind of stability or support for Asahi Linux. Unlike the PC space where laptop manufacturers have to maintain broad compatibility over time, Apple will make future changes that are really awkward for Asahi and will not care one bit because they can do the compat work on their own software.

I'm with you. This entire game has already played out in the iOS jailbreak scene.

There was a nice task on 39c3 https://youtu.be/3OAiOfCcYFM

They do try to upstream and eventually just have Linux natively support Apple Silicon!

> I'm concerned that after all these years, it's still a separate project and not an effort sustained directly within the kernel mainline and mainstream distributions

What does this mean? Hardware support is rarely developed inside these organizations; what makes it seem like these groups would be a good home for this effort?

It makes sense to have a group of experts in a field (Apple hardware/firmware) contribute patches upstream, which is the exact system here. And Asahi have done an above and beyond job also maintaining their installation framework while carefully moving changes upstream as well.

Why would any group want to take on a project which could be instantly killed by an external for profit entity? For now Asahi is left alone by Apple but that could change in a single day and the entire project is dead. It doesn’t seem like a productive way to direct the limited energy that distribution foundations have on hand.

Like they say, "when you're 90% done you just need to take care of the other 90%"

This actually is the case for a few other competing Apple Silicon support projects that came and went prior to Asahi. Assuming you have a way to load code into EL2[0], it's fairly easy to bring up the main CPU and USB, plug in a bunch of external peripherals before boot, and say you got Linux running on Apple chips. Only true in the most literal case.

In contrast, Asahi is specifically doing all the challenging RE work that typically gets passed over in favor of flashy headlines. If anyone can get to 95%, it's them.

[0] Prior to the M1 Mac, Apple did not allow anyone but themselves to load EL2 code. The ability to load other OSes on Apple Silicon Macs is, strangely enough, an allowed use-case. Prior to this we had to rely on once-in-a-decade bootrom security bugs.

What does "mainlined" driver development even look like?