Hacker News new | ask | show | jobs
by bri3d 53 days ago
> 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.

1 comments

Well, after a while, the effort of maintaining and improving M-series kernel support should be directly be done by kernel maintainers, not within a fork with periodic merges (maybe some Asahi folks should become kernel maintainers).

Doing so would enabled mainstream distributions to provide maintainable M-series builds, with all that entails in terms of stability, enabling choice, maintenance or security fixes.

The whole fork + dedicated distribution made sense at the start of the project since it provided a playground for quickly iterating and experimenting (which is a no-no to do directly in the mainline kernel or in a major distribution).

But Asahi is still the only Linux on Silicon option after all these years, which is a bit worrisome. Asahi should have been a cool but temporary initiative.

At some point, the project will lose momentum and for its accomplishments to last, it should be merged into the general effort, i.e. drivers maintained directly in the Linux kernel, and the userland stuff made to be easily packaged and shipped by mainstream distributions.

This is... literally exactly what they are doing?

Of all of the reverse engineering related Linux efforts (and most corporate Linux efforts), Asahi have been the most methodical and relentless about upstreaming changes into the kernel and all of their upstream intermediaries (freedesktop/Mesa etc.), specifically so it's maintained, even at the detriment of the project velocity and contributor health.

Asahi is explicitly not supposed to be a fork + dedicated distribution long term and over time, the delta between Fedora Asahi Remix and Fedora has grown smaller and smaller.

> Asahi is still the only Linux on Silicon option

What do you mean? There are non-Fedora Remix distributions which incorporate the "edge" Asahi changes, like https://ubuntuasahi.org . And again, as more and more gets mainlined, it becomes increasingly plausible that many distributions will be able to support Apple Silicon "out of the box" without much special consideration.

I would have been happy if all that happened like 3 years ago.

Now, it's 5 years in, the Asahi effort is losing momentum. Core developers are going on to do other things, significant chunks (3922 commits) are still not merged upstream and no major distribution has an official build.

Sorry, but in my opinion, the project is at risk of becoming a dead and unmaintained branch.

Don't get me wrong, the Asahi team did an incredible job on this bloody difficult endeavor, but now is time to properly merge it and not let it go to waste.

It is a dying quail effort doomed from the start if those three ex Apple engineers could get a license from Arm to design chips it is still baffling why no one else across the whole wide world didn’t follow in their footsteps. There is a Linux market.

I’m just shocked that it has not happened. With all the money flying around for AI data-centers you would think that this would be a more worthwhile effort?

Where is the European effort in this area? I would think it would be a natural for something to come out of the EU in this area.

I feel like more money would not have helped that much. Maybe it would have enabled a few of the devs to work on it full time, but I doubt it would have brought more people into the project.

I would indeed love the EU to step in but not in the way you are probably thinking.

I would rather see such effort being made unnecessary through a law forcing the manufacturers to provide enough information/specification or even code for alternative/after-market OSes to be viable on the devices they produced.

And also, if possible, mandate a degree of standardization (looking at you Android phones and ARM SBCs) enabling commonality of efforts when supporting a device class.