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.

proof?

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.

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.

i install proprietary modules for nvidia all the time, i'm not going to care if i have to do it for something else that i own

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).

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.

I’m sure it’s really easy when you can get help from the people who made the chip or write the Apple drivers.

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.

Have you consulted this with a lawyer, or is it what you simply think/believe.

At least according to your own accounts on the Asahi IRC rooms, you were very aware of SPTM (which is part of the AS platform) and knew the people working on it: https://oftc.catirclogs.org/asahi-dev/2026-06-04#35383763

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...

Very sad. I really want to get Linux on newer Apple chips working flawlessly but I can understand the legal minefield about this particular work.

Nobody does. We're only about to start settling it in courts, likely the supreme ones.

That’s fine. Linux upstream won’t take his code but you can for your own purposes.

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?

All this work is tainted since the poster is ex-Apple[1].

So if I worked as a janitor at Apple, I couldn't contribute anymore?

Resume says : "Machine Learning Engineer".

Exactly how does that equate to knowing details of Apple's GPU implementation? Apple is a massive company.

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.

im pretty literate in intellectual property, but im pretty confused about the no looking at binary code artifacts bit.

TL;DR:

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.

Wouldn't using OpenAI break the cleanroom?

https://www.reddit.com/r/AsahiLinux/comments/1whecn1/comment...

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.

crazy anti-LLM policies

Weird how justified reasonable policies get the "crazy" label.

Even if this is the case, this is still a valuable contribution to learn upon.

It’s taint. Anyone who looks at it can’t work on a real open source driver because they will have had access to information they’re not supposed to.

It won’t be clean room like the stuff Alyssa did.

Can't this be used to make a clean room implementation? Have someone write a spec then someone else who is unrelated, implement it from scratch?

"Person A was under NDA, so we got them to pass their knowledge to person B, then had person B do the work - that's clean-room, right?"

Judges, as far as I know, do not generally take kindly to such arguments.

So what if person a and person b are unrelated and person b found it on their own? There are countries in the global south that never had an industrial revolution and don't speak English and never had factories for export nor made anything in a factory industrially that isn't building material and food and maybe fuel for local consumption so they've never had an IP infringement case

Wouldn't B's publication of the information make it by definition no longer a trade secret? It is now public knowledge, regardless of whether the current or former engineers might be liable for the original leak.

Any other interpretation would mean trade secrets have essentially infinite protection/NDAs apply to all of humanity.

That’s the most abstract and esoteric argument I’ve ever heard I think

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.

Excited to see what you contribute to open source against one of the richest and most litigious companies in the world.

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.

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.

At least according to your own accounts on the Asahi IRC rooms, you were very aware of SPTM (which is part of the AS platform) and knew the people working on it: https://oftc.catirclogs.org/asahi-dev/2026-06-04#35383763

Do you work for Apple?

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.

To the developer: it doesnt matter whatever you can upstream it or not. Just share the code and documentation of how this process can be reproduced.

There plenty of us not working at Apple who can reuse the same approach for M5 and next generations of hardware.

For the kernel driver it's literally just: run the hypervisor, wait for the kick, save the UAT state, replay the whole thing, make sure the output pages change, then just follow the pointer to initdata until you've built the whole tree from scratch. LLM handles the rest.

Thanks for the post and answering here, but for someone to follow in your steps there really need to be more information: how did you handle physical hardware? Did it got stuck / frozen / whatever? How did you managed reset / etc? What is your actual step-by-step process other then just telling codex / claude code "do X"? What else had to be solved along the way?

I just think one good part of Marcan's work is that they streamed a lot of their workflow with all kind of problems occured along the way and you could see how to solve them.

And please so not let anti-llm crowd discourage you. People like me who want to use good hardware and already choose to pay for Apple one just need drivers that work good and feature complete - code purity and "quality" is secondary.

I detail most of the development process in part 1:

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

So this is specific _only_ to M4 Mac Mini and Neo? Or will this work on any M4 SoC such as M4 Max?

Awesome to see that another project has started that does use LLM to build linux on top of apple silicon. Asahi linux was dead in the water for me once they made their extreme anti-LLM stance clear.

If contributor policies are enough to make projects "dead in the water" for you, the rest of Linux' desktop efforts will leave you appalled.