8 ms·

I feel like ubiquitous hardware support in every OS is going to be a solved problem soon. We're very close to just being able to set an AI coding agent to brut

• jwatte 8mo ago
  Tell me you've never developed a driver, without telling me you've never developed a driver.
• rvz 8mo ago
  > We're very close to just being about to set an AI coding agent to brute-force a driver for anything. That sounds quite naive and it isn't that simple. Even the author expressed caution and isn't sure about how robust the driver is since he hasn't seen the code himself nor does he know if it works reliably. Even entertaining the idea, someone would have already have replaced those closed source Nvidia drivers that have firmware blobs and other drivers that have firmware blobs to be open replacements. (Yes Nouveau exists, but at the disadvantage of not performing as well as the closed source driver) That would be a task left to the reader.
  • deleted 8mo ago
    [deleted]
  • calmbonsai 8mo ago
    > We're very close to just being about to set an AI coding agent to brute-force a driver for anything. This is false. To "brute force" a driver, you'd need a feedback loop between the hardware's output and the driver's input. While, in theory, this is possible for some analog-digital traducers (e.g WI-FI radio), if the hardware is a human-interface system (joystick, monitor, mouse, speaker, etc.) you literally need a "human in the loop" to provide feedback. Additionally, many edge-cases in driving hardware can irrevocably destroy it and even a domain-specific agent wouldn't have any physics context for the underlying risks.
    • ssl-3 8mo ago
      Strictly speaking, I don't think we need a human to run repetitive tests. We just need the human to help with the physical parts of the testing jig. For instance: A microphone (optionally: a calibrated microphone; extra-optionally: in an isolated anechoic chamber) is a simple way to get feedback back into the machine about the performance of a speaker. (Or, you know: Just use a 50-cent audio transformer and electrically feed the output of the amplifier portion of the [presumably active] speaker back into the machine in acoustic silence.) And I don't have to stray too far into the world of imagination to notice that the hairy, custom Cartesian printer in the corner of the workshop quite clearly resembles a machine that can move a mouse over a surface in rather precise ways. (The worst that can happen is probably not as bad as many of us have seen when using printers in their intended way, since at least there's no heaters and molten plastic required. So what if it disassembles itself? That's nothing new.) Whatever the testing jig consists of, the bot can write the software part of the tests, and the tests can run as repetitiously as they need to.
      • calmbonsai 8mo ago
        To your point, we already have testing jigs for these sorts of systems in the automotive world for steering and suspension. I can't find the video clip atm, but there's a neat (likely leaked) Foxxconn video that shows a really neat testing jig for Apple trackpads.
        • ssl-3 8mo ago
          There's all kinds of automated testing in the world. The fun part is that some of us (actually, in this particular crowd, many of us) already have a lot of what we need to get some automated testing done at home, and we may not even realize it. :)
  • ineedasername 8mo ago
    someone would have already have replaced those closed source Nvidia drivers that have firmware blobs This isn’t quite a fair example, these are so massively complex with code path built explicitly for so many individual applications. Nvidia cards are nearly a complete SoC. Though then again, coding agents 1 year ago of the full autonomous sort were barely months old, and now here we are in one year. So, maybe soon this could be realistic? Hard to say. Even if code agents can do it, it still costs $ via tokens and api calls. But a year ago it would have cost me at least a few dollars and a lot more time to do things I get done now in a prompt and 10 minutes of Opus in a sandbox.
  • pmontra 8mo ago
    I'm not so sure that Nouveau is slower than the proprietary Nvidia driver. I didn't run benchmarks on my personal use case but my subjective experience is that Nouveau might be faster. It's a Debian 11, X11, NVIDIA driver vs Debian 13, X11, Nouveau on the same laptop with a Quadro K1100mq. The desktop of the newer system seems to be faster. Of course it could be the sum of the individual improvements of kernel, GNOME, etc. I only move windows around my desktop, no games, so it's a very limited scenario.
    • WD-42 8mo ago
      Absolutely not. Nouveau might give you a usable desktop but the second you need to do any 3d rendering or decoding it’s atrocious.
    • ranger_danger 8mo ago
      In my experience, the proprietary driver has always blown away nouveau at 3D rendering performance and featureset.
• ahoka 8mo ago
  That pesky GPL does not stop us anymore, cool.
  • petcat 8mo ago
    What would the GPL have to do with this?
    • stanac 8mo ago
      AI written driver could be a rip off Linux driver.
    • tokyobreakfast 8mo ago
      In the mid-2000s there was a bit of drama when Linux wireless driver code ended up in BSD (or maybe the other way around). The Internet was angry that day my friend; a bunch of nerds sperging out over licenses and which license is more "free". Ultimately the code was removed. It sure seems like AI agents can sidestep all that by claiming ignorance on license matters.
    • IshKebab 8mo ago
      If the Linux driver is GPL and he made the new driver using AI to essentially copy it then claim that the result wasn't covered by the GPL... It's an area not settled by law yet. Still not as bad as the guy who paid for a commercial license for some Linux driver, fed it into Claude to get it to update it to the latest Linux, and then released it as GPL! That's definitely not a grey area. https://youtu.be/xRvi3k8XV8E https://youtu.be/xRvi3k8XV8E Absolutely mental behaviour for a business. What were they thinking?
      • heffer 8mo ago
        It's clickbait. The "driver" is actually a rather comprehensive kernel patch that modifies existing GPLv2 kernel code, so by its very nature it is at least GPLv2 (original parts may be dual licensed by the vendor if they want to, but they can't not make it GPLv2). What this person paid $40,000 for is access to development kits for certain hardware, which with chip vendors like that usually also comes with support. The vendor cannot prevent you from exercising your GPLv2 rights after they hand you the code. In fact, if you manufacture and distribute a device that uses these kernel patches it becomes your obligation to enable your customers to exercise their GPLv2 rights. Chip manufacturers know this and (if they are somewhat reputable) usually license their code appropriately.
• diath 8mo ago
  The primary reason why it worked is because Claude could rip off the Linux driver. Without any prior work to rely on, how will the AI figure out proprietary hardware?
  • rustyhancock 8mo ago
    I haven't read the article but my first question was, install wifibox? It's a bhyve VM running alpine Linux and you pass through your WiFi adaptor and get a bridge out on the freebsd host.
    • deleted 8mo ago
      [deleted]
    • WD-42 8mo ago
      Literally explained in the post, that’s why you read first.
  • bootwoot 8mo ago
    True. But also -- how do humans do it? There are docs and there's other similar driver code. I wouldn't be surprised if Claude could build new driver code sight-unseen, given the appropriate resources
    • chrisjj 8mo ago
      > But also -- how do humans do it? Intelligence.
    • slopinthebag 8mo ago
      > But also -- how do humans do it? Probably a mix of critical thinking, thinking from first principles, etc. You know, all things that LLM's are not capable of.
      • jacobr1 8mo ago
        Except it often is the case that when you break down what humans are doing, there are actual concrete tasks. If you can convert the tacit knowledge to decision trees and background references, you likely can get the AI to perform most non-creative tasks.
• Gigachad 8mo ago
  Maybe one day, but it doesn't look like we are very close yet. From the OP article, they handed it the working linux driver and asked it to just make this FreeBSD compatible, but it could not. Looks like it took OP a significant amount of work over 2 months to get something that seems to work. What is interesting is it seems like the work resembles regular management, asking for a written specification, proof reading, etc.
  • lazide 8mo ago
    Aka, the hard part.
  • plagiarist 8mo ago
    To make these things work you do need to write a spec and figure out what unit tests will prove it actually did what you want. Even then it will take a bunch of shortcuts so it's best if you're a domain expert anyway.
  • ssl-3 8mo ago
    > What is interesting is it seems like the work resembles regular management, asking for a written specification, proof reading, etc. That's how I've been using the bot for years. Organize tasks, mediate between them, look for obvious-to-me problems and traps as things progress, and provide corrections where that seems useful. It differs from regular management, I think, in that the sunk costs are never very significant. Find a design issue that requires throwing out big chunks of work? No problem: Just change that part of the spec and run through the process for that and the stuff beneath it again. These parts cost approximately nothing to produce the first time through, and they'll still cost approximately nothing to produce the second time. I'm not building a physical structure here, nor am I paying salaries or waiting days or weeks to refactor: If the foundation is wrong, then just nuke it and start over fresh. Clean slates are cheap. (I don't know if that's the right way to do it, or the wrong way. But it works -- for me, at least, with the things I want to get done with a computer.)
• estimator7292 8mo ago
  Drivers can be anywhere from so trivial you can throw it together by hand in an afternoon to so complex that it requires an entire engineering team six months of concentrated effort.
  • deleted 8mo ago
    [deleted]
• octoberfranklin 8mo ago
  Hardware driver bugs frequently manifest as concurrency flakiness or heisenbugs. AI is notoriously bad at dealing with bugs that only cause problems every few weeks.
  • deleted 8mo ago
    [deleted]
  • jomohke 8mo ago
    I've thought for a while now that we'll end up moving to stricter languages that have safer concurrency, etc, partly for this reason. The most prominent resistance against such languages was the learning curve, but humans like OP aren't looking at the code now.
  • hahn-kev 8mo ago
    So are people
  • bluGill 8mo ago
    I've found ai really good at the rare problems. The code hangs 1 out of 200 times - it spends half an hour and finds a race condition and a proposed fix - something complex that is really difficult for humans to figure out. Now grated the above problem took a dozen rounds over a couple days to completly solve (and it happend more often than every two weeks), but it was able to find an answer given symptoms.
• skydhash 8mo ago
  The driver used as inspiration is fully opensource https://github.com/torvalds/linux/tree/v6.18/drivers/net/wireless/broadcom/brcm80211/brcmfmac https://github.com/torvalds/linux/tree/v6.18/drivers/net/wir... I don't know why it has not been brought in the BSDs (maybe license), but they do are a bit more careful with what they include in the OS.
• mschuster91 8mo ago
  > We're very close to just being able to set an AI coding agent to brute-force a driver for anything. Yeah, but that only works for so long as the AI doesn't brute force a command that hard-bricks the device. Say, it causes a voltage controller to give out way too high voltages by a command, burns e-fuses or erases vital EEPROM data (factory calibration presets come to my mind here).
• wangzhongwang 8mo ago
  I think we're closer than most people realize, but the hard part isn't generating the code — it's testing it. Drivers need to handle edge cases that only show up under specific hardware conditions, timing issues, power states, etc. An AI can write a first draft pretty fast, but validating it still requires actual hardware in the loop. The FreeBSD case worked because brcmfmac is well-documented and the author could test on real hardware. For more obscure chipsets with no public datasheets, we're still stuck.