Had a similar thought today - maybe we could finally get Linux drivers for more HW...
Not a successful anecdote, but I have a Windows Hello compatible Kengsington fingerprint reader, and for some time I wanted to write drivers for Linux. Even without using C, it would have been a huge undertaking only to fail in the end; because Claude did much of the research and concluded that the device wouldn't work on Linux (can't remember why but it made sense). Then it suggested what could work.
>Additional Old Linux Drivers Face Removal Due To Noise From AI/LLM Coding Agents
What I read in the link was that it was removed because LLM was making suggestions to improve the code/bring it up to modern standards but since it was rarely used no-one wanted to review it not that it was buggy.
>In recent months we have seen a lot of old kernel code removed stemming from that AI/LLM noise.
This is the opposite of what my parent was hoping to see, extended support for old/obscure hardware because we have LLM.
>This is the opposite of what my parent was hoping to see, extended support for old/obscure hardware because we have LLM.
That would only happen if the linux project was happy to accept LLM-generated fixes without human review - which they aren't. If human review is necessary, then unleashing LLMs to produce fixes and improvements to thousands of linux drivers is a detriment, not a benefit. The amount of code would just be too much, and reviewers would be swamped.
In this case:
LLMs know the USB Spec very well.
LLMs know how to read raw packet dumps.
LLMs know how to convert a packet dump to USB spec
LLMs know how to write code to generate USB packets from the spec.
Basically, If you have a well-documented problem, the LLM is a shortcut to learning it yourself. LLMs fail when you have a novel or poorly documented problem. They also fail when you provide the LLM with terrible context or too much context.
This is a very novel, reasonably-poorly-documented problem, and so far it has batted 1.000.
After 5-6 consecutive approaches fail, I need a reason to think the next one might work out to stay motivated.
Claude will keep burning credits trying new approaches until something sticks. That's a huge advantage in a field where most of the things you try don't go anywhere.
Unless you're on consumption billing.
It also has the benefit that it doesn't usually matter too much if it gets minor details wrong. It's definitely one of the areas - like hacking - where it's a) tedious and b) insensitive to mistakes where AI absolutely shines.
Reverse engineering isn't so much hard as it is exhausting.
LLMs simply don't care about exhaustion.