Claude models were blocked from logging into my own VM with my own credentials I gave it using ssh that I also gave it by its guard rails. I wouldn't doubt other models are nerfed but...you should provide some context around your comment
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.
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).
> upstream projects anyways so any distro can just work
This may never end up working like that, considering how complicated installation is, comparatively speaking, and how macOS is still pretty much required to be installed.
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".
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.
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.
The only cost was a month of llm usage. If the legal questions matter to you, you or someone else should be able to spend some tokens to redo their work in a similar way. I doubt Apple will actually care much about this. But even if they do, the worst they’ll do is get the repo taken down.
It may also be legal to do the following: 1. Have an llm read all the code these people have written and produce extensive documentation. 2. Have another llm consume that documentation and write another working driver. I am not a lawyer but I think this may fall under fair use, because reverse engineering is allowed for interoperability.
There were and are many important pieces of Linux kernel that live out of tree; ZFS is a big example.
The problem with this driver is not licensing or code quality; I assume it's under a threat of receiving C&D letter, or maybe also a legal suit for breaking some NDA.
Now that this work is done and out in the open what in theory would prevent the next generation of LLMs from ingesting it and eventually a non-Apple employee creating yet another driver “from scratch” but with the knowledge of how the hardware works acquired from an LLM or with the help of one?
Basically, aren’t we facing a situation where LLM-assisted knowledge laundering is becoming a thing?
Yes, as well as accountability laundering. Technofascists are loving it.
Nobody has been held accountable for AI selecting a grade school as a bombing target on the first day of America and Israel’s strikes on Iran. 100+ school girls killed, and no accountability.
I’m glad I did my one Linux kernel driver contribution before I worked at Apple. What a surprise to know that I’ll never be able to contribute to it ever again.
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.
> The author was banned from Asahi Linux for hiding his extensive use of LLMs from us in another attempted contribution, and (more importantly) for concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development. Make of this what you will.
I certainly dont care about hiding LLM contributions and all crazy anti-LLM policies, but I really hope author can share process completely so this can be reproduced by someone not working for Apple.
I find it extremely ironic that big corp openly steals IP en masse to build their models but hackers are still concerned about using same models for their reverse engineering work.
I think at this point the hacking community needs to grow some balls.
It's because it doesn't matter how copyrighted material ends up in a project. If an LLM reproduces copyrighted material (which is very hard to verify) then the lawsuit from the copyright owner can still sink even robustly funded projects.
The fact is, open source has much more liability than closed source software does. If copyrighted material ends up inside a private code base it'll be nearly impossible for the owner to discover that and sue.
The tiniest bit of contamination can get a whole project shut down and the creators heavily fined if the lawyers are aggressive enough. It's not worth the risk to a project like Asahi. Generally the law is going to side with whomever has the most lawyers.
If Apple open sourced its drivers this issue wouldn't exist. AI at last gives the "community" a chance to use the hardware they bought the way they want. It's unreasonable to expect anybody to code this kind of stuff "by hand" when automated tools exist.
> concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development
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.
I'm sure Omarchy will appreciate the effort, even if you're snubbed by Asahi -- being able to run Linux flawlessly on Apple Silicon is going to be awesome.
I wouldn't expect "flawless" support for those chips in the next decade, even with AI. The earliest-supported Asahi chips still have missing power management and dark silicon.
The only way to get flawless Linux support is to buy hardware from an OEM that supports Linux well.
Hey, I'm sorry this thread has gone sideways with other throwaway accounts crawling out of the woodwork to push a narrative that you're a tainted bad guy for doing this.
I wanted to ask if you'd consider taking all of your learnings and translate them into a concrete specification and publish it on your website, so that we can all do our own clean-room from-spec-only implementation.
Right now I'm focusing specifically on the M4 Mac Mini and Neo, I just don't own any M4 Pro or Max hardware. My guess is that most of the drivers will just work on the other platforms, but we'll have to test.
65 comments
[ 0.27 ms ] story [ 17.6 ms ] threadPerhaps before Astra was nerfed. It is now the dumbest model right after Gemini. Sol still holds up.
I assume I’ll get used to it, but my mental model of what’s possible hasn’t been fully rewired yet.
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/
This may never end up working like that, considering how complicated installation is, comparatively speaking, and how macOS is still pretty much required to be installed.
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.
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...
I didn't mean that I understand the actual intricacies of the legal situation.
Sorry for my confusing wording.
It may also be legal to do the following: 1. Have an llm read all the code these people have written and produce extensive documentation. 2. Have another llm consume that documentation and write another working driver. I am not a lawyer but I think this may fall under fair use, because reverse engineering is allowed for interoperability.
The problem with this driver is not licensing or code quality; I assume it's under a threat of receiving C&D letter, or maybe also a legal suit for breaking some NDA.
Including the proprietary GPU drivers. If this MacBook driver end up out of tree, so be it.
Basically, aren’t we facing a situation where LLM-assisted knowledge laundering is becoming a thing?
Nobody has been held accountable for AI selecting a grade school as a bombing target on the first day of America and Israel’s strikes on Iran. 100+ school girls killed, and no accountability.
So if I worked as a janitor at Apple, I couldn't contribute anymore?
I guess author can cleanup the code and try upstream it themself. Then let's see what Linus thinks of it.
Exactly how does that equate to knowing details of Apple's GPU implementation? Apple is a massive company.
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.
Are you claiming models were trained on proprietary Apple code? How would that even be possible?
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.
The legal framework around all this is way too immature to make a definitive statement one way or the other. Anyone who says otherwise is speculating.
The only way to clarity will be legislation or court cases, because it really could go either way.
> The author was banned from Asahi Linux for hiding his extensive use of LLMs from us in another attempted contribution, and (more importantly) for concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development. Make of this what you will.
Weird how justified reasonable policies get the "crazy" label.
Imagine what happen if OP submit patches upstream skipping Asahi and they gonna be accepted.
It won’t be clean room like the stuff Alyssa did.
I think at this point the hacking community needs to grow some balls.
The fact is, open source has much more liability than closed source software does. If copyrighted material ends up inside a private code base it'll be nearly impossible for the owner to discover that and sue.
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.
The only way to get flawless Linux support is to buy hardware from an OEM that supports Linux well.
I wanted to ask if you'd consider taking all of your learnings and translate them into a concrete specification and publish it on your website, so that we can all do our own clean-room from-spec-only implementation.
There plenty of us not working at Apple who can reuse the same approach for M5 and next generations of hardware.