Asahi Linux 7.1 Progress Report
pantalaimon
541 points
201 comments
July 01, 2026
Related Discussions
Found 5 related stories in 356.3ms across 14,015 title embeddings via pgvector HNSW
- Asahi Linux Progress Linux 7.0 elisaado · 605 pts · April 26, 2026 · 93% similar
- Linux 7.0 Released with New Hardware Support, Optimizations and Self-Healing XFS isaacfrond · 24 pts · April 14, 2026 · 54% similar
- Linux Sound Subsystem Also Seeing Many Fixes Driven by AI/LLMs dboon · 30 pts · May 22, 2026 · 53% similar
- Linux 6.6 LTS To Linux 7.1 Bechmarks: Performance Up 13% Threadripper Over 3 yrs Bender · 29 pts · May 18, 2026 · 51% similar
- Linux 7.1 berlianta · 278 pts · June 14, 2026 · 51% similar
Discussion Highlights (13 comments)
CafeRacer
It is exciting that they are working on AVD driver.
Forgeties79
God bless the asahi team
JSR_FDED
I’m in absolute awe that a handful of motivated people can crack these problems
coxmi
I wonder what the dev/CI process looks like on this. Will it ultimately be manually loading a build into specific hardware each time, or is there a level of automation that can be done here?
sneak
It is baffling to me that Apple, ostensibly a hardware company (that happens to be pursuing services revenue the way a crackhead pursues crack), ridiculously flush with cash, doesn’t throw 2 or 3 of their thousands of FTEs on this. The goodwill/brand marketing alone is worth their comp, and it will absolutely move units as well. Linux people LOVE laptops, and Apple makes the best laptops by a parsec. It seems like 10x ROI would be a conservative estimate.
simonmales
Will this forever exist as a Fedora "remix". Or will we find the support in upstream so I can one day run Debian-based distro? I think the last time I used an RPM-based distro was almost 2 decades ago.
Gigachad
Is the github sponsors link a 404 for everyone else?
eqvinox
> The defacto industry standard for audio ICs is I²S, an I²C-based bus optimised for audio data. Nit: I²S has nothing to do with I²C. (Most I²S chips also have an I²C interface since I²S only carries raw audio data, no sideband like volume control or clock configuration. But that's a separate interface and can also be SPI rather than I²C. In fact, SPI is more closely related to I²S than I²C is.)
shvarr
Asahi could be a viable alternative, however, with this amount of funding, small manpower pool pace of development is doomed to be too slow. There's groundwork that's already been done, as mentioned in the article, which brings some dividends, but, ultimately, there is a new mac every year that comes with a new chip, a plethora of microcontrollers and gpu changes, impossible to keep up with, that is why asahi team is focused more on m1 and m2 models. Even so, to this day both of them have issues with idle power management and alt-dp implementation, preventing many to switch, by the time they will have been ironed out the value of machines would be significantly diminished. It is a miracle how much so few can do, but in the end, despite ubiquitous media coverage it looks like team's enthusiasm and passion have dwindled to the point that even m1 air will never be ready.
KolmogorovComp
I wonder how much LLMs have been leveraged to help Asahi lately, there’s extremely powerful for reverse-engineering. Have they written about it?
GeekyBear
It's nice to see M3 support progressing well. They first mentioned that efforts to add M3 support were starting in February: > For quite some time, m1n1 has had basic support for the M3 series machines. What has been missing are Devicetrees for each machine, as well as patches to our Linux kernel drivers to support M3-specific hardware quirks and changes from M2. Our intent was always to get to fleshing this out once our existing patchset became more manageable https://asahilinux.org/2026/02/progress-report-6-19/
noveltyaccount
I really wish Apple would fund a small team to open source some documentation and drivers to help Asahi along. I know they won't, but I can dream. It would be a drop in the bucket for Apple but would cement their hardware as de facto for silicon valley engineers (even more so than today).
zbentley
> The firmware loaded by XNU is not verified by the CM3. It will begin executing from its reset vector when signalled, no matter what is actually there. What if we just… used our own firmware? Without taking away from the unutterably awesome achievement of writing custom firmware against a proprietary moving target, I worry about this one specifically. While Apple will hopefully continue the practice of not going out of their way to break third-party OSes, it doesn’t seem unlikely that they will introduce hardware signing for firmware blobs or the data they supply at runtime when programming the hardware; that’s a reasonable security concern for Apple to address. I hope this gamble pays off though!