All this work is tainted since the poster is ex-Apple[1]. There is no way Linux will take that code, since people from Apple also contribute to Linux and this creates a major conflict.
There's also ongoing issues around Codex for this sort of thing, given Apple is suing OpenAI over stolen trade secrets[2]. And nobody knows whether training data in other models is similarly tainted.
It's extremely impressive that they were able to make a working driver so quickly. I think this is one of the best use cases for LLMs. You don't need someone to spend years reverse engineering undocumented hardware anymore. It will interesting to see how good the driver the LLMs came up with is, and whether it can be upstreamed into the Linux kernel.
Might be one of the only use cases where LLMs are necessary to succeed. Can't imagine the pain of reverse engineering a technology of this scale and "secrecy".
Traditional hardware RE centers around heroics by a small number of very smart people, see: marcan, Alyssa Rosenzweig, Asahi Lina, etc. What they did is insanely impressive, and given how hard it was with LLMs I'm sure I would not personally be able to do this work without LLMs. That said, I'm looking forward to a world where the staring at hexdumps and traces can be delegated to LLMs and talented humans can spend their time building as opposed to head banging.
The problem I’m finding, at least with today’s models, is that it produces disposable software. It’s not good at making well-architected, durable software. Stuff that could be maintained and bug-fixed.
I mean you can get good stuff out of it if you know what you are doing and guide it, but if you just say “here’s a regression suite. Write an implementation that passes” you will get something that works for a while but ages quickly and will need to be thrown away.
With today’s technology I’d still want a GPU driver developer guiding the LLM rather than some rando who is out of their element. But cutting down the exploration cycle time and giving the developer massive parallelism (have 10x agents exploring different hypotheses or features) is the real win. We don’t need to skip all the way to slop just to squeak out a little more effort savings.
I am not by any means a copyright lawyer, so can anyone enlighten me on if it is a good idea for upstream projects to accept such kind of code from an ex-Apple employee, especially since Apple is currently suing OpenAI.
- 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.
This is super great. The biggest pain point of Asahi Linux is how it doesn't have GPU acceleration on M3 and newer, especially now that M6 is out!
However, Asahi Linux has a strictly no-AI policy [1]. So this great work can't be upstreamed. I expect to see a bunch of AI-assisted forks that get things working smoothly on newer hardware to dominate as most people just care about getting stuff working, while only a handful of purists stick to the non-AI version running on ancient hardware.
:) I think we have a surprise in store here. Asahi don't have a monopoly over Linux for Apple Silicon, and upstream Linux absolutely does *NOT* ban LLMs.
Asahi's long term goal is to get everything possible merged into the (actually) upstream projects anyways so any distro can just work. It'd be nice to see that continue rather than have forks on forks for the sake of singular differences (and it looks like proper upstreaming is what they are going after per the Remaining Work section).
I imagine either they or others can take their discoveries and write a real driver now, though. The hard part was always the reversing the black box system.
Clean room is not 100% legally necessary for RE, but I would never touch an LLM to do RE work when there's even a chance the models have been trained on the thing I ultimately plan to reimplement.
Furthermore, given that Asahi Linux, the biggest game in town when it comes to running Linux on Apple silicon, is trying to be cleanroom, it is incredibly rude of you to not mention LLMs until after showing a page full of LLM-derived firmware ABI. This is a trap for anyone who's trying to be cleanroom.
All this work is tainted since the poster is ex-Apple[1]. There is no way Linux will take that code, since people from Apple also contribute to Linux and this creates a major conflict.
There's also ongoing issues around Codex for this sort of thing, given Apple is suing OpenAI over stolen trade secrets[2]. And nobody knows whether training data in other models is similarly tainted.
[1]: https://codyho.dev/documents/cody_ho_resume.pdf
[2]: https://www.theguardian.com/technology/2026/jul/10/apple-sue...
It's extremely impressive that they were able to make a working driver so quickly. I think this is one of the best use cases for LLMs. You don't need someone to spend years reverse engineering undocumented hardware anymore. It will interesting to see how good the driver the LLMs came up with is, and whether it can be upstreamed into the Linux kernel.
Might be one of the only use cases where LLMs are necessary to succeed. Can't imagine the pain of reverse engineering a technology of this scale and "secrecy".
Traditional hardware RE centers around heroics by a small number of very smart people, see: marcan, Alyssa Rosenzweig, Asahi Lina, etc. What they did is insanely impressive, and given how hard it was with LLMs I'm sure I would not personally be able to do this work without LLMs. That said, I'm looking forward to a world where the staring at hexdumps and traces can be delegated to LLMs and talented humans can spend their time building as opposed to head banging.
The problem I’m finding, at least with today’s models, is that it produces disposable software. It’s not good at making well-architected, durable software. Stuff that could be maintained and bug-fixed.
I mean you can get good stuff out of it if you know what you are doing and guide it, but if you just say “here’s a regression suite. Write an implementation that passes” you will get something that works for a while but ages quickly and will need to be thrown away.
With today’s technology I’d still want a GPU driver developer guiding the LLM rather than some rando who is out of their element. But cutting down the exploration cycle time and giving the developer massive parallelism (have 10x agents exploring different hypotheses or features) is the real win. We don’t need to skip all the way to slop just to squeak out a little more effort savings.
I am not by any means a copyright lawyer, so can anyone enlighten me on if it is a good idea for upstream projects to accept such kind of code from an ex-Apple employee, especially since Apple is currently suing OpenAI.
Great observation, two things:
- 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.
This is super great. The biggest pain point of Asahi Linux is how it doesn't have GPU acceleration on M3 and newer, especially now that M6 is out!
However, Asahi Linux has a strictly no-AI policy [1]. So this great work can't be upstreamed. I expect to see a bunch of AI-assisted forks that get things working smoothly on newer hardware to dominate as most people just care about getting stuff working, while only a handful of purists stick to the non-AI version running on ancient hardware.
[1] https://asahilinux.org/llm-policy/
:) I think we have a surprise in store here. Asahi don't have a monopoly over Linux for Apple Silicon, and upstream Linux absolutely does *NOT* ban LLMs.
Asahi's long term goal is to get everything possible merged into the (actually) upstream projects anyways so any distro can just work. It'd be nice to see that continue rather than have forks on forks for the sake of singular differences (and it looks like proper upstreaming is what they are going after per the Remaining Work section).
I imagine either they or others can take their discoveries and write a real driver now, though. The hard part was always the reversing the black box system.
Maybe I’m getting really old, and I know we live in changing times but the fact this works at all is insane, as in black magic insane.
I assume I’ll get used to it, but my mental model of what’s possible hasn’t been fully rewired yet.
I still can't quite believe it either!
Clean room is not 100% legally necessary for RE, but I would never touch an LLM to do RE work when there's even a chance the models have been trained on the thing I ultimately plan to reimplement.
Furthermore, given that Asahi Linux, the biggest game in town when it comes to running Linux on Apple silicon, is trying to be cleanroom, it is incredibly rude of you to not mention LLMs until after showing a page full of LLM-derived firmware ABI. This is a trap for anyone who's trying to be cleanroom.
[delayed]
/goal have all this upstreamed to Linux
Figuring out how the hardware works and how to interface with it to submit work is a significant step all by itself.
> GPT-6 Astra and GPT-5.6 Sol are absolutely insane
Perhaps before Astra was nerfed. It is now the dumbest model right after Gemini. Sol still holds up.
Can't disagree more, but my experiences are my own.
proof?
See preview comment