191–200 of 397 posts
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
The future is that people stop buying software and just build it themselves. The spam filter in thunderbird was broken for me, I built my own in hours and it works way better. Oh that CRM doesn’t have the features you want? Build one that does. It will become very easy to built and deploy solutions to many of your own bespoke problems.
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
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?
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.
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.
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.
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.
Earlier quoted context omitted.
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 resemblin…
Except... In this case, they didn't really work from the chip's published documentation. They instead ultimately used a sorta-kinda open-book clean-room method, wherein they generated documentation using the source code of the GPL'd Linux driver and worked from that. That said: I don't have a dog in this race. I don't really have an opinion of whether this is quite fine or very-much not OK. I don't know if this is so…
I don't work on the Linux kernel, but I do poke around the sources from time to time. I was genuinely surprised to see that some hardware drivers are not GPL'd. That is news to me, but makes commercial sense to when I think deeper about it. When these manufacturers donate a driver to Linux, I don't think GPL is a priority to them. In the case of Broadcom, they probably want their WiFi hardware to more compatible with SBCs to drive sales (of future SBCs that use their WiFi hardware and run Linux). If anything, choosing a more liberal license (ISC) increases the likelihood that their Linux driver will be ported to other operating systems. From Broadcom's commercial view, that is a win to sell more SBCs (free labour from BSDers!).
Also, if the original driver was GPL'd, I am pretty sure it is fair game (from US copyright and software license perspective) to use one LLM to first reverse engineer the GPL'd driver to write a spec. Then use a different LLM to implement a new driver for FreeBSD that is ISC'd. You can certainly do that with human engineers, and I see no reason to believe that US courts would object to separate LLMs being used in the two necessary steps above. Of course, this assumes good faith on the part of the org doing the re-write. (Any commercial org doing this would very carefully document the process, expecting a legal challenge.)
I do think this blog post introduces a genuinely (to me!) novel way to use LLMs. My favourite part of that blog post was talking about all of the attempts that did not work, and new approaches that were required. That sounds pretty similar to my experience as a software engineer. You start with preconceived notions that frequently shattered after you walk down a long and arduous path to discovering your mistakes. Then you stop, re-think things, and move in a new intellectual (design) direction. His final solution of asking LLMs to write a spec, then asking other LLMs to proof-read it is highly ingenious. I am really impressed. Please don't view that "really impressed" as my thinking that the whole world will move to vibe coding; rather I think this is a real achievement that deserves some study by us human engineers.
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.
The future is that people stop buying software and just build it themselves. The spam filter in thunderbird was broken for me, I built my own in hours and it works way better. Oh that CRM doesn’t have the features you want? Build one that does. It will become very easy to built and deploy solutions to many of your own bespoke problems.
This feels like when 3D printers hit the consumer market and everyone declared that buying things was over, everyone will just print them at home. There's tons of benefits to standardised software too. Companies rely on the fact they can hire people who already know photoshop/xero/webpack/etc rather than having to train them from scratch on in house tools.
Earlier quoted context omitted.
> Someone with domain knowledge could also just write the code instead of trying to get the stochastic prediction machine to generate it. Well, people with the domain knowledge exist, yet they have not yet written this driver... why not? Because there is other code those experts want to write, and they don't have time to write it all... but what if they could just give a fairly straightforward prompt and have the LLM…
> Because there is other code those experts want to write, and they don't have time to write it all... but what if they could just give a fairly straightforward prompt and have the LLM do it for them? Then pretty soon they wouldn't be the experts anymore?
There is no reason to believe you can't gain expertise while still using higher and higher level abstractions. Yes, you will lose some of that low level expertise, but you can still be an expert at the problem set itself.