https://github.com/GravityLinux/linux https://github.com/niklassheth/mesa-wip

but as a shipped product you are currently right. That'll change when we ship.

We also have vrr!

https://gravitylinux.org

Spoiler: We have Vulkan 1.4 working, all of M4 and most of M5 working, are making significant progress towards full suspend to ram (no version of Asahi supports this) and this will all be shipped to users very soon!

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.

Comments URL: https://news.ycombinator.com/item?id=49791468

Points: 40

# Comments: 17

- boot macos under hypervisor (detailed guide in my part 1) into single user mode

- write your own metal program and run it as early in boot as you can

- trace all relevant graphics regions

- once you see the first kick, intercept that kick, then capture the full uat state

- reboot the device, then copy that whole uat state back into the machine, every bit exactly where it was

- perform the kick, verify the output page changes as expected

- have the LLM build all the objects itself in python

- repeat with different metal programs until we have all the behavior you want

- for a list of all behaviors you want, just look at the m1/m2 kernel driver and make sure everything they do has an analogue in your codebase

- if there's every any problems, there's a very simple debugging loop: 1. MAKE SURE YOU HAVE A REPLAYABLE CAPTURE. if you don't then priority #1 is to get that capture. once you have that capture, it's only a matter of time until it works

https://codyho.dev/blog/hypervisor-macbook-neo/

tl;dr you reboot the device with `macvdmtool`, you install m1n1 as the boot object, you talk to the m1n1 proxy over a python shell. I'm documenting the process as I go also (see: the blog posts, also my github repos) both so others can do it and as record of the clean room nature, but this really is just GPT go brrrrr

This is false. I am a former Apple engineer. I did not conceal it (it's the top item of my resume and my LinkedIn and I made my PR from my public Github with my name attached, as opposed to a pseudonym which is expressly allowed by Asahi policy). I also had no exposure, at all, to any internal information or code about macOS, SPTM, or Apple Silicon during my time there.

I also don't have connections to people involved in Apple Silicon development (and I'd add that this does not mean someone cannot contribute, the question is were they exposed to tainted information, which is absolutely not true in my case). I have many friends who work for Apple (I'm a Stanford alum) but none in Apple Silicon directly.

I disagree with the phrasing of this entire thing, but this statement is demonstrably false.

1. We want to guarantee our work is not a "derivative work" of anything Apple wrote.

2. If we look at any Apple binaries, there's no way prove that our code didn't borrow from Apple.

3. Since we didn't look at any Apple binaries, then there's no way our work can be a derivative work-- we didn't even look at their stuff.

- During my time at Apple I never saw any of the macOS source code, at all, even for userspace components. I had not even heard of things like SPTM.

- I have not worked there since June 2025

I don't believe that there's any risk due to my former Apple employment. As another example, WINE does not ban all former Microsoft employees, they just ban anyone who has ever looked at the Windows source code. If I felt there was even a chance that my employment at Apple may have exposed me to relevant internal secrets, I would refrain from contributing to community projects.