Hacker News Reader

Comment by jasoneckert | Hacker News Reader

While I don't feel I have enough information to comment about the likelihood that Apple would try to stop the Asahi project, those who are knowledgable are of the opinion that they would not.

However, as a Mac Studio M1 owner that has used Asahi as a daily driver for software development since the first release (originally Arch, later Fedora), I can confidently say that I could care less. By running the software I want to run far faster than macOS could on the same hardware, Asahi has saved me countless hours and made me far more productive. And I'm incredibly grateful for this tangible benefit, regardless of what happens in the future.

View on HN

You claim that your apps are faster on Linux on an M1 than macOS on the M1; can you add more detail? Which apps, and did you run benchmarks? I find it hard to believe that Apple hasn't optimized apps to be faster on their own OS and hardware.

In short, all apps run faster - I have some more detail in this blog post (which also includes a link to my original blog post with additional performance details): https://jasoneckert.github.io/myblog/fedora-asahi-remix/

I suspect this is primarily due to Linux being a more performance-optimized OS compared to macOS, which seems to have introduced a great deal of bloat over the years.

They won't stop Asahi with a frontal assault, they'll stop it by churning out new chips every year until the work to support them all is unsustainable.

Not sure why you are being down-voted. We're already seeing this with the team saying they won't work on M3 yet because they aren't even close to done with M2...

actually they're saying they're close to getting M3 support and the big thing that has prevented work on it as the lack of a M3 Mac Minis.

How is that apple's fault, nor any form of "deliberate attack"? Like, come on, neither of the parties are malicious, especially not for the sake of it.

I didn’t say it was anyone’s fault. It’s the reality of a closed system.

Why don't new Intel or AMD chips require painstaking reverse engineering with each release?

Historically they do, and currently they don't because their biggest market is server machines where Linux is the de facto choice. It's a life or death question for them to properly support the Linux kernel.

In one search I'm able to pull up Pentium documentation from 1995 as well as recent documentation from 2023. Show me the equivalent Apple Silicon docs that a compiler engineer could use.

Reply on news.ycombinator.com