Linux

Yeah, I personally prefer the bug-free old version:

On a more serious note, we're still in a period where people are figuring out what AI can/cannot be used for and what the best practices are. Ironically, since it's better at reverse engineering and bug hunting than developing when compared to a human, it is more useful for hacker and open-source projects than enterprise.

On one hand you don't know what the code is doing but on the other hand it's impossible to write so much code by hand and do any amount of testing for projects this big

LLM code is getting less sloppy and you now have the choice between generating open-source projects which you will never read the code of, or using an artisan coded buggy project.

Nobody has the time to test every single communication protocol manually to see when a camera is able to take pictures or a microphone records audio. LLM's can do this driver development and even check when the result looks good. There's soooo much tedious labour which can already be automated.

OP managed to revive an abandoned phone with working drivers thanks to LLM development. That's a massive win.

Nura will not accept generated patches, by the way.

If you click OP's github link and scroll down you'll find this section which acknowledges that: https://github.com/sv1sjp/mi-max2-oxygen-msm8953-nura-drivers#about-ai-assistance-and-contributing-upstream

The drivers, patches, scripts and write-ups here were produced in collaboration with an AI assistant and tested on a real Mi Max 2 (oxygen).

The Nura project does not accept LLM-generated contributions. One of its maintainers explains the reasons in this post: the social and environmental cost of these models, and the risk that people use them to produce private knowledge instead of joining and strengthening the community whose work the models learned from. We respect that decision. So:

• This repository is not a contribution to Nura or pmaports, and its code should not be submitted there as it is.
• It is public documentation, not private notes. The reusable part is the knowledge: how the hardware is wired, register addresses and meanings, root causes, what was tried and ruled out, and how to test safely. These are facts anyone can check on their own device. It can save time for anyone who wants to understand what works and what does not, and then write their own code to submit upstream.
• If you want to get this into Nura or upstream, learn from it, verify it on your hardware and write your own implementation, following the rules of the project you contribute to (Nura, the Linux kernel and libcamera each have their own contribution policies).
• Please engage with the community. The Nura wiki, the msm8953-mainline project and the people credited below did the groundwork this builds on.

@OP (@sv1sjp@lemmy.world) what isn't clear to me is why you don't try to upstream the kernel parts, since Linux is accepting LLM-assisted contributions (as is Nura actually, just only indirectly after their upstreams like Linux accept them).

upstream linux does accept AI "assisted" patches. if this gets properly mainlined, why wouldn't it run Nura?