> 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.
> 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.
The friend I am referring to I met at Stanford around April of 2026 in a dorm event. We've spoken in person exactly once (I use "friend" loosely to describe anyone I've spoken to who I'm not on bad terms with) and at no point did we discuss anything detailed about Apple Silicon. For further context, I left Apple in June of 2025.
Spend enough time in tech and you'll know lots of people who know both technical and business secrets and are under various levels of NDAs. The message you link to explicitly mentions only public info was exchanged. Just talking to someone is not an indication of infringement in any way.
I think this comment is missing the forest for the trees. Obviously, ephemeral interaction is going to happen.
The author’s blogpost is sloppy and has some signs of being AI written. This kind of bleeds into the main point I’m going to make.
Asahi Linux folks are clearly more conservative and erring on the side of caution, so, this means that the glibness with which the author is treating any of this is probably sufficient cause to refuse his entries. It is unclear if LLMs should be considered a toxic waste dump in terms of trying to maintain a clean room. We have not established a standard. It is clear the author doesn’t think this is a big deal, so that’s one conflict. The other conflict is that it is not clear what their exact interactions with Apple Silicon folks is and their glibness of it doesn’t clarify anything.
If you take a group that is trying to be very careful about the potential legal landmines a still nascent technology has and you get someone that espouses a general glibness about those concerns wanting to merge code…why on earth would you expect that group to accept them as a contributor?
This is not to say this isn’t really cool and a neat use of LLMs, but it is totally understandable why Asahi Linux won’t accept the fruits of this kind of development. If it turns out that Apple can identify its non-OSS code in this, it’ll be a mess.
> <StanfordAppliedCyber[m]> one of my friends is a very senior engineer who lead a lot of the sptm work and controls a lot of boot, may talk to him about it (obviously he hasn't told me anything that isn't public)
You are accusing someone by twisting their own words about their own self disclosed identity against them from a throwaway account created 5 hours ago.
And they say irony is dead.
I say this from an anonymous account but at least it isn't a throwaway. And at least I have the good taste to feel a little shame for my hypocrisy.
But there are plenty of successful projects which would probably have been taken down if it wasn't for clean room RE. I mean just look at the clean room IBM BIOS clones from "IBM compatibles" in the early days of the personal computer.
there isn't ?? I sorta thought we figured all this out decades ago when SMB and DeCSS were being reversed? I think dosemu or something as well ?
I seem to recall DeCSS being the 'hot button' as it was RE'd in a 'non clean' way, the code released, and then a 'clean room' RE could be made from the 'public' info ??
edit: actually, at the time I think there was German law allowing RE for 'interoperablity' or some such. But that was a long time ago so my memory might be off.
Nintendo doesn't care. There's been proprietary Nintendo SDK code in libogc (open source library for making GameCube homebrew) for years. And more recently the various decompilation process have made recreations of linked code from the SDK that compile match byte for byte. In practice the legal risk of being sued into oblivion for this is not there. If anything there would be a DMCA takedown / cease and desist.
Would you 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?
"We don't want to take on the risk of working with a former Apple employee, who could potentially leak trade secrets and expose us to unwanted liability" is a very different statement than asserting that they were banned for deception. The post you're replying to is responding to accusations against their character and behaviour. Clearing those up is an entirely different matter than saying anything about whether former employees should be allowed to contribute to the project.
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.
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.
> 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.
Do you have many examples of this actually happening that you could share?
I really don't see how this issue is going to be feasible for courtrooms to deal with in a world where big tech are bragging about large percentages of all their code being produced by LLMs.
In the 90s aircraft manufacturers basically stopped whole segments of the market (anything smaller than a piston twin) due to litigation. I wouldn't be horribly surprised to find we spend the next 10 years fighting about this stuff in court.
I'm fully aware of lots of times powerful companies have used the courts to protect their business. My point is basically all of the powerful companies are elbow deep in LLMs to the extent of some sort of mutually assured destruction if they were to start court cases like this.
LLMs have been firing out a lot of code for a year or 2 now at least, so I would have thought we'd start seeing some court cases by now?
It's purely conjecture at this point but my gut feeling is most companies are in high spirits about the costs they can save and the benefits it can bring to their own business. I don't think enough time has passed to see really high profile losers. What happens when Infosys starts losing money or Free CAD becomes the next SolidWorks due to LLM driven improvements?
Why wouldn't it be feasible for Apple, with an unlimited war chest, to go after Asahi?
I am not saying they will, but it is certainly possible for them.
Because if it's feasible for any company with a war chest to start a court case about a competitor maybe having a matching line of code to theirs via an LLM, then basically every single company with a warchest would be at war with eachother, because they're all using LLMs.
Business and code production would grind to a halt whilst basically every big tech company shares it's entire codebase with every other tech company for discovery. It's basically MAD.
And if it was feasible, given we've had a couple of years of all the big tech companies heavily using LLMs, there should be some notable court cases by now, surely?
Agree. Especially since even a tainted GPU driver (tainted as in, used former Apple Engineer knowledge) is usefull as we just throw another LLM onto it and tell it "rewrite in rust" and get an untainted version of it (at least that is the current judicial state, and the bigtech argues in this direction).
It's not ironic, it's the flipside of exactly the same reason. Bigcorps can steal with impunity because they have unlimited money to pay expensive lawyers. FOSS projects do not, so they cannot.
No judge I’ve ever met gave a damn how much a party spent on legal resources. With rare exceptions, they care a great deal about achieving justice, and often bend over backwards to help indigent parties avoid prejudicing themselves. Keep in mind that there are no indigent parties in this debate; both major IP rights holders and the frontier AI companies are well capitalized.
(I worked in a federal district court for a while.)
Which of these parties doesn’t have lawyers? (I’m talking about bigcorps stealing from bigcorps here.)
In a case where both parties have lawyers, having more and more expensive lawyers is not necessarily predictive of a case’s outcome. There are diminishing returns.
What having more resources tends to do is force the poorer party to settle quicker. But that’s not necessarily a loss. Judges still have to approve settlements in the interest of justice.
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.
none of this is incorrect, however, how freaking sad is it that in order to get any OS that's not locked down and owned by Apple on the hardware we buy and supposedly own, someone (together with whole open source organizations) has to risk utter financial ruin.
I hate the new system of no ownership and closed everything.
Apple is a huge company with strong silo culture. I only interviewed with them, but it feels to me like different orgs are run almost like entirely different companies. If his work didn't concern Mac, it's quite unlikely he'd have any special insider knowledge about it.
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.
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.
The NDA doesn't apply to people who haven't signed it, but copyright law does. If you know the material you're receiving is under copyright (eg proprietary source code), and you publish work based on that copyright material, the fact that it's now widely available is not an effective defense against claims of copyright violation.
Person B in this scenario hasn't violated the NDA, but they could be sued for copyright infringement.
The point of a clean-room implementation is that the only thing passing from A to B is a detailed specification written from scratch, because functional details cannot be copyrighted.
Which I think you know, so I don't understand your argument.
You said in another comment "However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer."
It being proprietary and/or secret information doesn't affect the copyright of the clean-room output. If there's trade secret implications those are worth discussing, but as a separate issue.
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
The argument is not esoteric. An Apple employee working on a reverse engineered GPU driver might (intentionally or not) incorporate internal knowledge that they are contractually obligated to keep secret or write an implementation that is too close to proprietary code they had access to, to the point that it could be argued that it is a derived work.
This sort of thing has always been a concern for projects that re-implement some existing piece of software, e.g. there were concerns early on during development of the GNU project about people contributing after having been exposed to Unix source code. Similarly, it is an ongoing concern for the Wine project[1], as well as ReactOS. The later even had a code freeze and internal audit in 2006, after allegations came forward that code had been derived from disassembled Windows binaries[2].
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.
Apple offer LLMs, so they are already on board with the LLM arguments.
I have many frustrations with LLMs, mainly around the type of user whos brain shuts down, but Apple would be walking a very fine line if they offer a service that they also will sue you for using.
Perhaps they should have used the Foundation Models to build their code. Really put Apple in a difficult position.
Dear fellow humans from "Hacker News". Hacking a driver that in itself documentation to black box Apple hardware is not any different from hacking $10 4G LTE modem.
Fact that a person who was not previously driver developer can achieve this in a few weeks is pure wonder. No matter what tools are used.
Leave legal questions to Linux Foundation laywers or whoever is responsible to accept or not accept the patches.
If Apple actually wanted to prevent any of this from happening they can just lock bootloader. They not just gonna do it now because someone used fancy text generator to make working GPU driver.
Attacking a person who spent their personal time and money on making walled garden black box hardware more usable, more privacy friendly and further away from landfill is a crime against the future of humanity.
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 can’t help wondering if the whole process will be automated being an LLM.
Apple releases the M15, and using everything leaned while building drivers for the M4 - M14, the LLM just does the whole job and we have the drivers a day later.
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.
Even though the kernel module is open-source (sort of, development still happens behind closed doors), it's still an out-of-tree module, rather than being built into the kernel, which would give you as smooth an experience as with AMD or Intel, who's GPUs literally do just work on any distro with no fuss.
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.
You can make the Linux installation on Apple Sillicon Macs pretty painless nowadays. One terminal command on macOS, reboot to Linux, run one script - voila.
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.
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.
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.
The detractors around here would like to cede the absolute maximum possible territory that can be ceded to the copyright bully types, to avoid even the slightest possibility of trouble. "Did you even once enter Caffe Macs and eat a croissant? Stay 100 feet away from every FOSS project for life. Otherwise the beast might threaten us with a lawsuit."
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.
If you're going to make some kind of argument about the benefits of copyright for preserving software jobs, keep in mind this is a driver for hardware apple sells. Everyone would be better off if drivers were mandatory open source.
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.
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.
Apparently. But Apple should be ashamed of themselves for that fact. What are they so afraid of? That Mac OS is so inferior to Linux that if they publish specs so that a driver can be made, that everyone will wipe Mac OS off their disks like it's Windows ME??
Once again, modern Apple is allergic to competing on their product's merits, clinging to force as though it's the only way anyone will choose them. Which is insane to me given how loyal their following is. I'm typing this shit on Mac OS right now.
Apple comes off like the most insecure corporate culture in history.
What is the state of Nvidia and AMD GPU drivers on Linux? Maybe these techniques can finally give us reasonably good open source drivers which can be supported for a long time.
AFAIK Nvidia drivers are proprietary and AMD has a tendency to drop support quickly
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.
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
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.
Great job for bringing up new apple's silicon chip , m4 a18 to linux . I hope the project keep alive and maintained , and if you can't mainline it , remmber many other project do out-of-tree version well maintained [1] [2] [3] [4] [5] [6] [7] .
A brief look shows that these projects are LLM-backed. Will be interesting to see how this works for Omarchy in light of legality concerns expressed here in this thread.
This is extremely impressive work; kudos. I was thinking about this with regard to Asahi's anti-LLM policy just last week - they're going to get completely outmoded by LLM-harnessed reverse engineering, if only for personal use and not upstreaming.
I'm surprised you worked with Niklas on this. I'd have assumed you'd think he was competent, given he went to Binghamton and not Stanford.
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.
It's okay to have policies against shitty code, blatant copyright violations or being an ass.
It's not okay to ban tool use when a person is honest about it. The only thing you can achieve with a ban is that people will learn to lie about it and conceal it better.
It's not my policy, and I don't personally agree with many/most of them.
But they do objectively exist in many desktop Linux projects. If you are the sort of person that sees software as "dead in the water" from AI prohibition, desktop Linux will feel like a mausoleum compared to macOS or Windows.
Contributor policies that ban LLM use wholesale. Not contributor policies in general.
So many people are clinging to practices that are rapidly becoming antiquated. Even Linus had to put his foot down and had to stop the ideologues from attempting to stop AI use in the linux kernel.
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.
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
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.
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.
> 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.
Ah, don't worry about those guys. This is very cool! I love the technical write up -- so interesting: )
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
The friend I am referring to I met at Stanford around April of 2026 in a dorm event. We've spoken in person exactly once (I use "friend" loosely to describe anyone I've spoken to who I'm not on bad terms with) and at no point did we discuss anything detailed about Apple Silicon. For further context, I left Apple in June of 2025.
Isn't that chat log from 2024?
If you read the page it says 2026-06-04.
Ah. I read the post, but only saw "2024-07-16 04:52 ChanServ changed [...]"
On mobile I didn't see the full URL, and zoomed before I saw the calendar. My bad.
am i crazy or is the date stamp not literally in the link?
Spend enough time in tech and you'll know lots of people who know both technical and business secrets and are under various levels of NDAs. The message you link to explicitly mentions only public info was exchanged. Just talking to someone is not an indication of infringement in any way.
I think this comment is missing the forest for the trees. Obviously, ephemeral interaction is going to happen.
The author’s blogpost is sloppy and has some signs of being AI written. This kind of bleeds into the main point I’m going to make.
Asahi Linux folks are clearly more conservative and erring on the side of caution, so, this means that the glibness with which the author is treating any of this is probably sufficient cause to refuse his entries. It is unclear if LLMs should be considered a toxic waste dump in terms of trying to maintain a clean room. We have not established a standard. It is clear the author doesn’t think this is a big deal, so that’s one conflict. The other conflict is that it is not clear what their exact interactions with Apple Silicon folks is and their glibness of it doesn’t clarify anything.
If you take a group that is trying to be very careful about the potential legal landmines a still nascent technology has and you get someone that espouses a general glibness about those concerns wanting to merge code…why on earth would you expect that group to accept them as a contributor?
This is not to say this isn’t really cool and a neat use of LLMs, but it is totally understandable why Asahi Linux won’t accept the fruits of this kind of development. If it turns out that Apple can identify its non-OSS code in this, it’ll be a mess.
> <StanfordAppliedCyber[m]> one of my friends is a very senior engineer who lead a lot of the sptm work and controls a lot of boot, may talk to him about it (obviously he hasn't told me anything that isn't public)
For the lazy.
You are accusing someone by twisting their own words about their own self disclosed identity against them from a throwaway account created 5 hours ago.
And they say irony is dead.
I say this from an anonymous account but at least it isn't a throwaway. And at least I have the good taste to feel a little shame for my hypocrisy.
Do you work for Apple?
Probably not. Clean room RE is serious business, projects like Dolphin have to carefully vet contributors to remain legal.
Everyone says this, and then exactly zero cases are cited in support of or against this creative legal theory known as "clean room RE."
No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.
When you say "case" does that mean you're rejecting the evidence of Phoenix technologies not getting sued along with all the other BIOS clones?
But there are plenty of successful projects which would probably have been taken down if it wasn't for clean room RE. I mean just look at the clean room IBM BIOS clones from "IBM compatibles" in the early days of the personal computer.
there isn't ?? I sorta thought we figured all this out decades ago when SMB and DeCSS were being reversed? I think dosemu or something as well ?
I seem to recall DeCSS being the 'hot button' as it was RE'd in a 'non clean' way, the code released, and then a 'clean room' RE could be made from the 'public' info ??
edit: actually, at the time I think there was German law allowing RE for 'interoperablity' or some such. But that was a long time ago so my memory might be off.
Who volunteers to be the shmuck that fights Nintendo's lawyers in court? Who's funding the defense against Apple?
It's safest to err on the side of plausible deniability, any proximity to OEM software increases liability if things go wrong.
Nintendo doesn't care. There's been proprietary Nintendo SDK code in libogc (open source library for making GameCube homebrew) for years. And more recently the various decompilation process have made recreations of linked code from the SDK that compile match byte for byte. In practice the legal risk of being sued into oblivion for this is not there. If anything there would be a DMCA takedown / cease and desist.
Would you 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?
Everything that you say can be true, and yet Asahi project may want to avoid needing to prove what you say in a courtroom.
"We don't want to take on the risk of working with a former Apple employee, who could potentially leak trade secrets and expose us to unwanted liability" is a very different statement than asserting that they were banned for deception. The post you're replying to is responding to accusations against their character and behaviour. Clearing those up is an entirely different matter than saying anything about whether former employees should be allowed to contribute to the project.
FFS Linux kernel have tons of patches with "Asahi Lina" specified as "author" even though commiters are real people:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Just call yourself "Idea Llmina" or whatever and let someone else commit it.
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.
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.
> 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.
Do you have many examples of this actually happening that you could share?
I really don't see how this issue is going to be feasible for courtrooms to deal with in a world where big tech are bragging about large percentages of all their code being produced by LLMs.
In the 90s aircraft manufacturers basically stopped whole segments of the market (anything smaller than a piston twin) due to litigation. I wouldn't be horribly surprised to find we spend the next 10 years fighting about this stuff in court.
I'm fully aware of lots of times powerful companies have used the courts to protect their business. My point is basically all of the powerful companies are elbow deep in LLMs to the extent of some sort of mutually assured destruction if they were to start court cases like this.
LLMs have been firing out a lot of code for a year or 2 now at least, so I would have thought we'd start seeing some court cases by now?
It's purely conjecture at this point but my gut feeling is most companies are in high spirits about the costs they can save and the benefits it can bring to their own business. I don't think enough time has passed to see really high profile losers. What happens when Infosys starts losing money or Free CAD becomes the next SolidWorks due to LLM driven improvements?
Why wouldn't it be feasible for Apple, with an unlimited war chest, to go after Asahi? I am not saying they will, but it is certainly possible for them.
Because if it's feasible for any company with a war chest to start a court case about a competitor maybe having a matching line of code to theirs via an LLM, then basically every single company with a warchest would be at war with eachother, because they're all using LLMs.
Business and code production would grind to a halt whilst basically every big tech company shares it's entire codebase with every other tech company for discovery. It's basically MAD.
And if it was feasible, given we've had a couple of years of all the big tech companies heavily using LLMs, there should be some notable court cases by now, surely?
Heh, sounds like it'd be along the same lines as the SCO Unix kerfuffle back in the day.
Agree. Especially since even a tainted GPU driver (tainted as in, used former Apple Engineer knowledge) is usefull as we just throw another LLM onto it and tell it "rewrite in rust" and get an untainted version of it (at least that is the current judicial state, and the bigtech argues in this direction).
It's not ironic, it's the flipside of exactly the same reason. Bigcorps can steal with impunity because they have unlimited money to pay expensive lawyers. FOSS projects do not, so they cannot.
No judge I’ve ever met gave a damn how much a party spent on legal resources. With rare exceptions, they care a great deal about achieving justice, and often bend over backwards to help indigent parties avoid prejudicing themselves. Keep in mind that there are no indigent parties in this debate; both major IP rights holders and the frontier AI companies are well capitalized.
(I worked in a federal district court for a while.)
The problem is that money buys lawyers, and you need those to get justice. If the other side spends more, you are likely to lose.
Not everywhere is the US.
Which of these parties doesn’t have lawyers? (I’m talking about bigcorps stealing from bigcorps here.)
In a case where both parties have lawyers, having more and more expensive lawyers is not necessarily predictive of a case’s outcome. There are diminishing returns.
What having more resources tends to do is force the poorer party to settle quicker. But that’s not necessarily a loss. Judges still have to approve settlements in the interest of justice.
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.
none of this is incorrect, however, how freaking sad is it that in order to get any OS that's not locked down and owned by Apple on the hardware we buy and supposedly own, someone (together with whole open source organizations) has to risk utter financial ruin.
I hate the new system of no ownership and closed everything.
Excited to see what you contribute to open source against one of the richest and most litigious companies in the world.
Nothing. I hope those companies go bankrupt, I'm not underwriting their failure to support their customers with my time and effort.
Cool. Excited to see you on the pitch next time you comment on a football game.
It may not just be about IP but also code quality. As an example, TFA calls the user mode portion "slop" in need of cleanup.
Apple is a huge company with strong silo culture. I only interviewed with them, but it feels to me like different orgs are run almost like entirely different companies. If his work didn't concern Mac, it's quite unlikely he'd have any special insider knowledge about it.
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.
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.
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.
> NDAs apply to all of humanity
The NDA doesn't apply to people who haven't signed it, but copyright law does. If you know the material you're receiving is under copyright (eg proprietary source code), and you publish work based on that copyright material, the fact that it's now widely available is not an effective defense against claims of copyright violation.
Person B in this scenario hasn't violated the NDA, but they could be sued for copyright infringement.
The point of a clean-room implementation is that the only thing passing from A to B is a detailed specification written from scratch, because functional details cannot be copyrighted.
Which I think you know, so I don't understand your argument.
You said in another comment "However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer."
It being proprietary and/or secret information doesn't affect the copyright of the clean-room output. If there's trade secret implications those are worth discussing, but as a separate issue.
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
> what if person a and person b are unrelated and person b found it on their own
That's what's referred to as a "clean room implementation" further up the thread.
However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer.
Legally speaking, a clean room implementation has much better defenses from claims of copyright violation.
I mean person b found the work of person a on their own
That’s the most abstract and esoteric argument I’ve ever heard I think
The argument is not esoteric. An Apple employee working on a reverse engineered GPU driver might (intentionally or not) incorporate internal knowledge that they are contractually obligated to keep secret or write an implementation that is too close to proprietary code they had access to, to the point that it could be argued that it is a derived work.
This sort of thing has always been a concern for projects that re-implement some existing piece of software, e.g. there were concerns early on during development of the GNU project about people contributing after having been exposed to Unix source code. Similarly, it is an ongoing concern for the Wine project[1], as well as ReactOS. The later even had a code freeze and internal audit in 2006, after allegations came forward that code had been derived from disassembled Windows binaries[2].
[1] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
[2] https://en.wikipedia.org/wiki/ReactOS#Internal_audit
Wasn’t that exactly the legal standard Compaq had to prove when they did a clean room implementation of the IBM BIOS?
Why would anyone care about either of these things in a negative sense?
Isn’t that just saying “he uses modern tools and has subject matter expertise”?
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.
Asahi state as one of its goals upstreaming Apple Silicon support into Linux Kernel and kernel does not have similar anti-llm policies.
Imagine what happen if OP submit patches upstream skipping Asahi and they gonna be accepted.
Imagine how crazy it is to be throwing shade at someone for having ethics and holding themselves to a higher than required standard.
Apple offer LLMs, so they are already on board with the LLM arguments.
I have many frustrations with LLMs, mainly around the type of user whos brain shuts down, but Apple would be walking a very fine line if they offer a service that they also will sue you for using.
Perhaps they should have used the Foundation Models to build their code. Really put Apple in a difficult position.
I’m making nothing of this, thanks.
The LLM use wasnt the part that bothered me so much, but having had an Apple contract is bad.
Dear fellow humans from "Hacker News". Hacking a driver that in itself documentation to black box Apple hardware is not any different from hacking $10 4G LTE modem.
Fact that a person who was not previously driver developer can achieve this in a few weeks is pure wonder. No matter what tools are used.
Leave legal questions to Linux Foundation laywers or whoever is responsible to accept or not accept the patches.
If Apple actually wanted to prevent any of this from happening they can just lock bootloader. They not just gonna do it now because someone used fancy text generator to make working GPU driver.
Attacking a person who spent their personal time and money on making walled garden black box hardware more usable, more privacy friendly and further away from landfill is a crime against the future of humanity.
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.
Yeah I think it's a shame how much time and effort gets put into understanding things simply because other people want to keep them proprietary.
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 can’t help wondering if the whole process will be automated being an LLM.
Apple releases the M15, and using everything leaned while building drivers for the M4 - M14, the LLM just does the whole job and we have the drivers a day later.
I’m sure it’s really easy when you can get help from the people who made the chip or write the Apple drivers.
Did you read the article? They didn’t get help from the people who made the chip or wrote the Apple drivers.
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
Nvidia's kernel module is open source these days, it's the usermode stack that's still closed.
Even though the kernel module is open-source (sort of, development still happens behind closed doors), it's still an out-of-tree module, rather than being built into the kernel, which would give you as smooth an experience as with AMD or Intel, who's GPUs literally do just work on any distro with no fuss.
Can't wait for someone to point an LLM at that and "open it up" ;-)
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.
You can make the Linux installation on Apple Sillicon Macs pretty painless nowadays. One terminal command on macOS, reboot to Linux, run one script - voila.
Yeah, but it's unlikely such installers will be officially supported by the distributions, which was my point regarding upstreaming.
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.
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...
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?
Some arguments in the Apple vs OpenAI case look like they could lead to a decision on whether an LLM can wash away copyright or not.
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.
Linking to another HN comment: https://news.ycombinator.com/item?id=49719480
Resume says : "Machine Learning Engineer".
Exactly how does that equate to knowing details of Apple's GPU implementation? Apple is a massive company.
The detractors around here would like to cede the absolute maximum possible territory that can be ceded to the copyright bully types, to avoid even the slightest possibility of trouble. "Did you even once enter Caffe Macs and eat a croissant? Stay 100 feet away from every FOSS project for life. Otherwise the beast might threaten us with a lawsuit."
> 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?
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.
I don't give a flying fuck.
Ignoring the idiocy of Imaginary Property is how China is winning.
It's time we caught up and then leap ahead. Everything is a derivative work.
So, what do you do for a living?
If you're going to make some kind of argument about the benefits of copyright for preserving software jobs, keep in mind this is a driver for hardware apple sells. Everyone would be better off if drivers were mandatory open source.
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.
> important pieces of Linux kernel that live out of tree; ZFS is a big example.
Including the proprietary GPU drivers. If this MacBook driver end up out of tree, so be it.
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.
That’s fine. Linux upstream won’t take his code but you can for your own purposes.
There is no reason Linux the Kernel upstream wont take his code. Asahi is not Linux upstream.
Nobody does. We're only about to start settling it in courts, likely the supreme ones.
I meant I can understand the fact that a legal minefield exists.
I didn't mean that I understand the actual intricacies of the legal situation.
Sorry for my confusing wording.
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.
> and this creates a major conflict.
Apparently. But Apple should be ashamed of themselves for that fact. What are they so afraid of? That Mac OS is so inferior to Linux that if they publish specs so that a driver can be made, that everyone will wipe Mac OS off their disks like it's Windows ME??
Once again, modern Apple is allergic to competing on their product's merits, clinging to force as though it's the only way anyone will choose them. Which is insane to me given how loyal their following is. I'm typing this shit on Mac OS right now.
Apple comes off like the most insecure corporate culture in history.
> There's also ongoing issues around Codex for this sort of thing, given Apple is suing OpenAI over stolen trade secrets
these two things have absolutely nothing to do with each other whatsoever
> There is no way Linux will take that code, since people from Apple also contribute to Linux and this creates a major conflict.
I guess author can cleanup the code and try upstream it themself. Then let's see what Linus thinks of it.
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!
What is the state of Nvidia and AMD GPU drivers on Linux? Maybe these techniques can finally give us reasonably good open source drivers which can be supported for a long time.
AFAIK Nvidia drivers are proprietary and AMD has a tendency to drop support quickly
AMD driver support is great due to community effort, even for 10+ year old cards. Nvidia also now has (partly?) open drivers.
amen to that. amdgpu is a shitshow for years. im sure the firmware plays its part in the shitshow, but amdgpu does as well.
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
> but this really is just GPT go brrrrr
I guess its a good reason to try it with M6 mac mini or Vision Pro then (yeah I know AVP has locked bootloader). Thanks.
call it a firmware blob and you are done
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.
Great job for bringing up new apple's silicon chip , m4 a18 to linux . I hope the project keep alive and maintained , and if you can't mainline it , remmber many other project do out-of-tree version well maintained [1] [2] [3] [4] [5] [6] [7] .
[1]: https://github.com/Rust-for-Linux/linux Rust for Linux
[2]: https://android.googlesource.com/kernel/common/ Android OS linux kernel
[3]: https://github.com/openzfs/zfs OpenZFS kernel module
[4]: https://github.com/awemorris/linux-pc98 Linux pc98 / 32 bit x86
[5]: https://github.com/OpenDingux/linux Linux on retro gaming device
[6]: https://github.com/AsahiLinux/linux Linux on older apple silicon M1/M2/M3 chip
[7]: https://github.com/microsoft/wsl2-linux-kernel Linux on Windows
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 of this was public knowledge, and there is nothing damning about knowing someone who worked on something.
And if I'm connected on Linkedin with half of silicon valley, and know a lot of people from different companies I not allowed to contribute anywhere?
Have you consulted this with a lawyer, or is it what you simply think/believe.
I guess it's none of our business.
All the controversy aside, someone can now white box reimplement this if they are concerned
just yeeting a qwen flash (iq3) with radare2 installed is so good to not slog through the regular loop of re
/goal have all this upstreamed to Linux
Fantastic work. I've been following M4 Linux progress almost daily, waiting for when I can use it as a daily driver.
Author, do TouchID next.
Fyi,there's a comment on the Omarchy-M annoucement [0] referencing Touch ID
> Dj is writing the GPU drivers, and got Touch ID working by talking directly to the Secure Enclave
[0] https://omarchy.org/news/2026/09/introducing-omarchy-m/
A brief look shows that these projects are LLM-backed. Will be interesting to see how this works for Omarchy in light of legality concerns expressed here in this thread.
This is a great use case of LLM.
Figuring out how the hardware works and how to interface with it to submit work is a significant step all by itself.
This is extremely impressive work; kudos. I was thinking about this with regard to Asahi's anti-LLM policy just last week - they're going to get completely outmoded by LLM-harnessed reverse engineering, if only for personal use and not upstreaming.
I'm surprised you worked with Niklas on this. I'd have assumed you'd think he was competent, given he went to Binghamton and not Stanford.
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?
That is the debate. And it is hotly contested.
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.
Did Apple share their code with OpenAI ?
Why would it? Unless you think OpenAI is training on Apple’s proprietary code?
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.
Why?
Because the desktop Linux stack is replete with LLM-related contributor policies.
It's okay to have policies against shitty code, blatant copyright violations or being an ass.
It's not okay to ban tool use when a person is honest about it. The only thing you can achieve with a ban is that people will learn to lie about it and conceal it better.
It's not my policy, and I don't personally agree with many/most of them.
But they do objectively exist in many desktop Linux projects. If you are the sort of person that sees software as "dead in the water" from AI prohibition, desktop Linux will feel like a mausoleum compared to macOS or Windows.
Contributor policies that ban LLM use wholesale. Not contributor policies in general.
So many people are clinging to practices that are rapidly becoming antiquated. Even Linus had to put his foot down and had to stop the ideologues from attempting to stop AI use in the linux kernel.
So this is specific _only_ to M4 Mac Mini and Neo? Or will this work on any M4 SoC such as M4 Max?
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.
> 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.
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
proof?
See preview comment
Can't disagree more, but my experiences are my own.
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 title is literally "I Came, I Prompted, I Left". I'm not sure how this can be clearer.
Jarvis, please the gpu
The previous “Part 1” post is very candid about the approach, and the titles of both posts mention prompting.
> when there's even a chance the models have been trained on the thing I ultimately plan to reimplement.
Are you claiming models were trained on proprietary Apple code? How would that even be possible?