Live data from Hacker News

FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

vladimir.varank.in

201–210 of 397 posts

Re: FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

#201
post #17

Earlier quoted context omitted.

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?

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

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.

Re: FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

#202
post #44

Earlier quoted context omitted.

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.

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…

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.

Re: FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

#204
post #14
post #2

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 brute-force a driver for anything. The hardware designer would have to go well out of their way to obfuscate the interface if they really wanted to forbid it, instead of just not bothering to support an OS like BSD or Linux.

That pesky GPL does not stop us anymore, cool.

I do not know why people do not just add GPL license to their generated code.

Re: FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

#205

Earlier quoted context omitted.

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…

> if you can formalize your instructions Isn't that...code?

No. Think of all engineering disciplines that aren't software. Those all depend on human-language formal instructions.

Re: FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

#206

I know this is me coming from my spoiled perspective of Linux and macOS, but the advice of running a VM that manages the WiFi hardware and passing it back to the OS seems insane to me

If an OS is designed to do this from the ground up, it can be incredibly efficient. (See: SeL4). Each process on linux is essentially its own isolated virtual machine already. Linux processes just have all sorts of ambient authority - for example, to access the filesystem and network on behalf of the user which started the process. Restricting what a process can do (sandboxing it) shouldn't have any bearing on performance.

Re: FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

#207
post #53

> Instead of continuing with the code, I spawned a fresh Pi session, and asked the agent to write a detailed specification of how the brcmfmac driver works Planning markdown files are critical for any large LLM task.

The line between AI-assisted clean-room reverse-engineeing and open-source-license-laundering is a thin one, and I think the one described in the article crosses over to laundering. In classic clean-room design, one team documents the interfaces - not the code.

In this case though, the new driver has the same license as the project it was based on and explicitly credits the original project

  ISC License
  
  Copyright (c) 2010-2022 Broadcom Corporation
  Copyright (c) brcmfmac-freebsd contributors
  
  Based on the Linux brcmfmac driver.

Re: FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

#208
post #32

Earlier quoted context omitted.

What would the GPL have to do with this?

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…

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.

Post reply on HN