Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Linux GPU Driver for the M4 Mac Mini in One Month

codyho.dev

Post reply on HN
Print view View original

151–160 of 293 posts

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#151

Post by voakbasda »

otterley wrote: post #148
rossy wrote: post #130

Earlier quoted context omitted.

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…

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.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#152

Post by 15155 »

bigyabai wrote: post #100
politician wrote: post #96

Earlier quoted context omitted.

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.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#153

Post by otterley »

voakbasda wrote: post #151
otterley wrote: post #148

Earlier quoted context omitted.

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…

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.

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.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#154

Post by bigyabai »

15155 wrote: post #152
bigyabai wrote: post #100

Earlier quoted context omitted.

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.

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.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#155

Post by laidoffamazon »

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.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#156

Post by nicman23 »

ADevWithAnIdea wrote: post #32
SXX wrote: post #31

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.

call it a firmware blob and you are done

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#157

Post by bigyabai »

lostmsu wrote: post #109
bigyabai wrote: post #104

Earlier quoted context omitted.

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.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#158

Post by nicman23 »

viraptor wrote: post #98
kmeisthax wrote: post #21

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 L…

The title is literally "I Came, I Prompted, I Left". I'm not sure how this can be clearer.

Jarvis, please the gpu

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#160

Post by Dylan16807 »

danielheath wrote: post #89
ndriscoll wrote: post #70

Earlier quoted context omitted.

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 t…

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.

Post reply on HN