What porting you talking about exactly? Packaging existing binaries? Compiling source code making it more compatible with Wine?
In my experience as game developer and porting C++ code tells such difference usually mean there are something really wrong with syncronization primitives. So 99.99% of the time code does nothing just waiting for something to unlock.
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.
AI reverse engineering can be an amazing jumping off point. It's not production ready and someone still has to go over it with a fine tooth comb before it can be called production ready. It is okay to publish things that aren't production ready and they are much better than nothing at all, and we shouldn't harshly criticise the best thing in a category unless we make something better.
The difference between AI RE and non-AI RE, is being able to see AI_SubmitCommandQueue instead of FUN_92f475a1 when you are reading some other function, and knowing that function probably submits a command queue even if you haven't got to it yet. This makes it way easier to check the function you're currently in - for every function. There's still a good chance it's wrong, also.
At some point you get to AI_SubmitCommandQueue and have to verify it does actually submit a command queue, then you can rename it to just SubmitCommandQueue.
> It is okay to publish things that aren't production ready and they are much better than nothing at all, and we shouldn't harshly criticise the best thing in a category unless we make something better.
So much of this.
Production ready or not we should praise all people who made decision to try, put an effort and find a way to made any device more usable with Linux.
This isnt just another vibe coded rewrite of XYZ library in rust or vibe coded javascript framework. We dont have a queue of people to work on open source GPU drivers or RE in general. Even if its mostly prompting and testing.
I'm just a game developer and linux nerd and for me fact that something like this is now possible is ultimately best news ever. It means I now motivated to try it myself and work on devices I want. Most inspiring and amazing thing ever!
Define "production ready." Can any driver developed without official specifications, corporate approval, or long-term support plan, ever be properly considered production ready?
At this scale, the only question is if it gets merged upstream. Outside of that it's a "nuh uh, you didn't design it my way."
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.
reply