9 ms·

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 har

• 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.
      • slopinthebag 8mo ago
        If you have to hold the LLM's hand to accomplish a task, using human intelligence to do so, you can't consider the task performed by AI.
        • jacobr1 8mo ago
          I half agree. But two points: 1) if you can formalize your instructions ... then future instances can be fully automated. 2) You are still probably having the AI perform many sub-tasks. AI-skeptics regularly fall into this god-of-the-gaps trap. You aren't wrong that human-augmented AI isn't 100% AI ... but it still is AI-augmentation, and again, that sets the stage for point 1 - to enable later future full automation on long enough timecycles.
          • skydhash 8mo ago
            > if you can formalize your instructions Isn't that...code?
            • deaux 8mo ago
              No. Think of all engineering disciplines that aren't software. Those all depend on human-language formal instructions.
              • okanat 8mo ago
                Formal instructions paired by tables are almost as rigid as code. Btw normal engineering disciplines have a lot of strict math and formulas. Neither electrical nor mechanical engineering runs on purely instructions.
  • jwatte 8mo ago
    Humans do it with access to the register-level data sheets, which are only available under NDA, and usually with access to a logic analyzer for debugging. Usually, the problem with developing a driver isn't "writing the code," it's "finding documentation for what the code should do."
    • okanat 8mo ago
      ... and then figuring out where the hardware company cheapened out and created a whole unfixable mess (extra fun when you first ship your first 10k batch and things start failing after the vendor made a "simple revision"). Then finding a workaround.
  • deadbabe 8mo ago
    Scientific method. There are many small discoveries humans make that involve forming a hypothesis, trying something out, observing the results, and coming to a conclusion that leads to more experimentation until you get to what you actually want. LLMs can’t really do that very well as the novel observations would not be in their training data.
• 05 8mo ago
  - have AI write a windows filter driver to capture all hardware communications - have AI reverse engineer Windows WiFi driver and make a crude prototype - have AI compare registers captured by filter driver with linux driver version and iterate until they match (or at least functional tests pass) not exactly rocket surgery, and windows device drivers generally don't have DRM/obfuscation, so reverse engineering them isn't hard for LLMs.
  • deleted 8mo ago
    [deleted]
  • wingmanjd 8mo ago
    So we send an AI agent to the French cafe instead of us? https://download.samba.org/pub/tridge/misc/french_cafe.txt https://download.samba.org/pub/tridge/misc/french_cafe.txt
    • neocron 8mo ago
      Shouldn't AI be able to take this one step further and just analyze the binary (of the samba server in this case) and create all kinds of interface specs from it?
      • toomuchtodo 8mo ago
        Make the LLM operate the hypervisor VM so it can observe a binary as it executes to write specs for it?
        • manofmanysmiles 8mo ago
          I'm working on this. It's wild.
• Nextgrid 8mo ago
  Trial and error? Just like it does when given an existing GPL’d source and dealing with its hallucinations, the agent could be operated on a black box (or a binary Windows driver and a disassembly)? The GPL code helped here but as long as the agent can run in a loop and test its work against a piece of hardware, I don’t see why it couldn’t do the same without any code given enough time?
  • dotancohen 8mo ago
    Presumably one would like to use the laptop before the million years it would take the million monkeys typing on a million typewriters to produce the Shakespearean WiFi driver. Consider that even with the Linux driver available to study, this project took two months to produce a viable BSD driver.
    • ssl-3 8mo ago
      This process took two months, including re-appraisals of the process itself, and it isn't clear that the calendar on the wall was a motivator. The next implementation doesn't have to happen in a vacuum. Now that it has been done once, a person can learn from it. They can discard the parts that didn't work well straight away, and stick to only the parts of the process that have good merit. We'll collectively improve our methods, as we tend to do, and the time required will get shorter with each iteration.
  • vitorsr 8mo ago
    Seems very promising but then you realize the LLM behind said agent was trained on public but otherwise copyright encumbered proprietary code available as improperly redistributed SDKs and DDKs, as well as source code leaks and friends. In fact most Windows binaries have public debug symbols available which makes SRE not exactly a hurdle and an agent-driven SRE not exactly a tabula rasa reimplementation.
• WD-42 8mo ago
  He also mentioned it took 2 months. I’m actually wondering how long it would take to do the Linux to BSD port by eyeball, or at least ai assisted. Probably not that much longer? I guess it depends on wall time vs real time.
  • lstodd 8mo ago
    I estimate two weeks from having never seen kernel source to something reasonably stable based on experience with block devices/raid controllers. But I knew a bit of C (had patches merged into SVN, Exim4, etc).
    • skydhash 8mo ago
      And the BSDs code are fairly simple as things go. Lots of specific domain knowledge sure, but you can find books and article fairly easily. The code itself is straightforward.
  • lich_king 8mo ago
    Most hardware drivers are simpler than people expect. The hardware is usually designed to do the sensible thing in a straightforward way, and you're just translating what the OS wants into a bunch of bits you need to write to the right hardware register. On the flip side, the perceived barrier is high. Most folks don't have an intuitive sense of how the kernel or "bare metal" environment differs from userland. How do you allocate memory? Can you just printf() a debug message? How to debug if it freezes or crashes? All of these questions have pretty straightforward answers, but it means you need to set aside time to learn. So, I wouldn't downplay the value of AI for the same reason I wouldn't downplay it with normal coding. It doesn't need to do anything clever to be useful. That said, for the same reasonss, it's harder to set up a good agent loop here, and the quality standard you're aiming for must be much higher than with a web app, because the failure mode isn't a JavaScript error, but possibly a hard hang.
    • fragmede 8mo ago
      Harder, but not impossible. You 3d print a jig for a solenoid and a relay so you can warm/cold reboot the laptop, get a pizerow setup and configured to be a keyboard you can control over SSH, a webcam watching the screen, a hardwired Ethernet port, a second computer to manipulate the Device Under Test (aka the MacBook/laptop with a missing whatever driver). Even though waiting on Claude Code doesn't hit flow state if you've only got one project going, setting things up so it can run with it is still fun, for specific and rather nerdy definitions of fun.
• cryptonector 8mo ago
  GPL is not a patent. It covers the work and _derivatives_; it does not cover ideas or general knowledge. The chip in question has docs. I fully expect that Claude wrote code that does not resemble that of the driver in the Linux tree. TFA is taking on some liability if it turns out that the code Claude wrote does largely resemble GPL'ed code, but if TFA is not comfortable with the code written by Claude not resembling existing GPL'ed code then they can just post their prompts and everyone who needs this driver can go through the process of getting Claude to code it. In court TFA would be a defendant, so TFA needs to be sure enough that the code in question does not resemble GPL'ed code. Here in the court of public opinion I'd say that claims of GPL violation need to be backed up by a serious similarity analysis. Prompts cannot possibly be considered derivatives of the GPL'ed code that Claude might mimic.
  • shakna 8mo ago
    From the file headers: SPDX-License-Identifier: ISC Copyright (c) 2010-2022 Broadcom Corporation Copyright (c) brcmfmac-freebsd contributors Based on the Linux brcmfmac driver. I'm going to ahead and say there are copyright law nightmares, right here.
    • throwaway2037 8mo ago
      That headers looks pretty reasonable to me. I don't see anything misleading or ambiguous about it. Whenever I am heavily modifying some licensed code, I always make sure to include a similar header. > I'm going to ahead and say there are copyright law nightmares, right here. I am confused. My first thought was maybe the original Linux driver was GPL'd, but it is not. It is ISC'd. Look here: https://github.com/torvalds/linux/blob/master/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c https://github.com/torvalds/linux/blob/master/drivers/net/wi... // SPDX-License-Identifier: ISC /* * Copyright (c) 2010 Broadcom Corporation */
      • shakna 8mo ago
        It adds a contributor. To add a contributor, you need "significant" _human_ input. The output of models has so far not been deemed copyrightable. As it acknowledges the original source, it needs to show the human effort that allows it to be bound to the new contributors.
• dev_l1x_be 8mo ago
  Combine AI + genetic algo? https://www.reddit.com/r/learnmachinelearning/comments/1665dvv/teaching_an_ai_to_play_mario_a_learning_journey/ https://www.reddit.com/r/learnmachinelearning/comments/1665d...
• toast0 8mo ago
  Repurposing NDIS drivers is a time honored tradition. No source, but oh well.
• ranger_danger 8mo ago
  It could be given reference material like documentation/datasheets and/or just be prompted as to how it should work.
• josephg 8mo ago
  The Linux driver in this case is ISC licensed. There’s no legal or ethical problem in porting it. This is open source working as intended. I feel like the jury is still out on whether this is acceptable for GPL code. Suppose you get agent 1 to make a clear and detailed specification from reading copyrighted code (or from reverse engineering). Then get agent 2 to implement a new driver using the specification. Is there anything wrong with that?
  • Barbing 8mo ago
    >anything wrong with that? Wonder if the courts will move fast enough to generally matter.
    • josephg 8mo ago
      As I understand it, reverse engineering for the purpose of interoperability is allowed under the law. The only thing subject to copyright is your code. So long as a separate implementation (made by an AI model or made by hand) doesn't use any of your actual code, you have no claim over it. Only the code is yours. AI models make the process of reversing and reimplementing drivers much cheaper. I don't understand the problem with that - it sounds like a glorious future to me. Making drivers cheaper and easier to write should mean more operating systems, with more higher quality drivers. I can't wait for asahi linux to support Apple's newer hardware. I'm also looking forward to better linux and freebsd drivers. And more hobbyist operating systems able to fully take advantage of modern computing hardware. I don't see any downside.
      • skydhash 8mo ago
        Drivers are usually easy to implement. What’s usually lacking is the specifications of the hardware. A lot of devices are similar enough that you can reuse a lot of existing code, but you do want to know which registers to read or fill.
• Gud 8mo ago
  Why is this “ripping off”? It’s an ISC Licensed piece of code.