> I didn’t write any piece of code there. There are several known issues, which I will task the agent to resolve, eventually. Meanwhile, I strongly advise against using it for anything beyond a studying exercise.
Months of effort and three separate tries to get something kind of working but which is buggy and untested and not recommended for anyone to use, but unfortunately some folks will just read the headline and proclaim that AI has solved programming. "Ubiquitous hardware support in every OS is going to be a solved problem"! Or my favourite: instead of software we will just have the LLM output bespoke code for every single computer interaction.
Actually a great article and well worth reading, just ignore the comments because it's clear a lot of people have just read the headline and are reading their own opinions into it.
The hype people are excited because they're guessing where it's going.
This is notable because it's a milestone that was not previously possible: a driver that works, despite OP needing ~zero of their own driver or hardware knowledge to help. It's not production ready, but neither is the first working version of anything. Do you see any reason progress will stop abruptly here?
> Do you see any reason progress will stop abruptly here?
Yeah, money and energy. And fundamental limitations of LLM's. I mean, I'm obviously guessing as well because I'm not an expert, but it's a view shared by some of the biggest experts in the field ¯\_(ツ)_/¯
I just don't really buy the idea that we're going to have near-infinite linear or exponential progress until we reach AGI. Reality rarely works like that.
The author specifically said that they did not read the code or even test the output very thoroughly. It was intentionally just a naive toy they wanted to play around with.
Nothing to do with AI, or even the capabilities of AI. The person intentionally didn't put in much effort.
> The author specifically said that they did not read the code or even test the output very thoroughly. It was intentionally just a naive toy they wanted to play around with.
Yes and that's what I'm pointing out, they vibe coded it and the headline is somewhat misleading, although it's not the authors fault if you don't go read the article before commenting.
But it does have to do with AI (obviously), and specifically the capabilities of AI. If you need to be knowledgable about how wifi drivers work and put in effort to get a decent result, that obviously speaks volumes about the capabilities of the vibe coding approach.
I strongly suspect that somebody with domain knowledge around Wi-Fi drivers and OS kernel drivers could prompt the llm to spit out a lot more robust code than this guy was able to. That's not a knock on him, he was just trying to see what he could do. It's impressive what he actually accomplished given how little effort he put forth and how little knowledge he had about the subject.
Someone with domain knowledge could also just write the code instead of trying to get the stochastic prediction machine to generate it. I thought the whole point was to allow people without said expertise to generate it. After all, that seems to be the promise.
It will be like that at some point soon, just not now. Are you trying to make the point that because this technology is not yet perfect the fact that it can already do so much is unimpressive?
> The person intentionally didn't put in much effort.
Aren't you just describing every vibe code ever?
To think about it, that is probably my main issue with AI art/books etc. They never put in any effort. In fact, even the competition is about putting least effort.
> instead of software we will just have the LLM output bespoke code for every single computer interaction.
That's sort of the idea behind GPU upscaling: You increase gaming performance and visual sharpness by rendering games at lower resolutions and use algorithms to upscale to the monitor's native resolution. Somehow cheaper than actually rendering at high resolution: Let the GPU hallucinate the difference at a lower cost.
> 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.
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 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.
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).
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
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.
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.
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?
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.
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.
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 something worthy of intense scrutiny, or if it should instead be accepted as progress.
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.
> 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.)
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.
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.
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.
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.
> 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)
> 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.
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.
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.
I really wanted to believe the original comment as it is indeed not something I wouldn't see against - however there is truth that hardware can be capricious and one could definitely burn something flipping the wrong bit - here comes the fantastic world of Megaman ; where he's analyzing the bits of the unknown driver - one mistake could burn his owner the machine - he didn't receive the latest analysis tool ; hm...maybe some other ai knows about this on the darkclanet ?
Sorry I drifted, claude is probably done generating stuff
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.
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.
Unlikely. The future will be some people will do this, but honestly I think it will largely be people who were already tinkering with building things, whether full on software development or not
My mom and dad, my brother who drives a dump truck in a limestone quarry, my sister-in-law, none of them work in tech or consider themselves technical in any way. They are never, ever going to write their own software and will continue to just download apps from the app store or sign up for websites that accomplish the tasks they want
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.
Had an experience like this recently. QEMU stopped compiling for old versions of MacOS (pre-13) w/M1 arch, due to it requiring newer SDKs which don't support older MacOS versions. I put Sonnet 4.6 on the case, and it wrote a small patch, compiled and installed it in a matter of minutes, without giving it any instructions other than to look at errors and apply a fix. I definitely would have just given up without the AI.
Software is still eating the world, now even faster. I wonder how soon we will adapt to this new situation where software is vibe coded for anything and make use of this software without caution as expressed in the article.
For most people the main difference will be: Will it run and solve my problem? Soon we will see malware being put into vibe coded software - who will wants to check every commit for write-only software?
I think in the future (in 10 years?) we are going to see a lot of disposable/throwaway software. I don’t know, imagine this: I need to buy tickets for a concert. I ask my AI agent that I want tickets. The agent creates code on the fly and uses it to purchase my tickets. The code could be simple curl command, or a full app with nice ui/ux. As a user I don’t need to see the code.
If I want to buy more tickets the same day, the ai agent will likely reuse the same code. But if i buy tickets again in one year, the agent will likely rebuild the code to adjust to the new API version the ticket company now offers.
Seems wasteful but it’s more dynamic. Vendors only need to provide raw APIs and your agent can create the ui experience you want. In that regard nobody but the company that owns your agent can inject malware into the software you use. Some software will last more than others (e.g., the music player your agent provided won’t probably be rebuilt unless you want a new look and feel or extra functionality). I think we’ll adopt the “cattle, not pets” approach to software too.
I know people have done truly amazing things with AI lately, but I feel this in my bones. Almost every demo I see is like, uh, I don't need these extremely simple things in my life automated. I can just go to Delta and buy a plane ticket. I actually want to write my own email to my mom or wife. Of course a demo is just a demo, but also come on
I think it's a fallacy that if you make creating anything easier, more useful things will be created. In reality, you just end up with more useless things being created. Like with art, when it gets easier to create you don't end up with more good art. And with software - it's not like the quality of software has gone up as it's gotten easier to build, it's gotten much worse.
A related fallacy is that great things are easier to build when you can rapidly create stuff. That isn't really how great ideas are generated, it's not a slot machine where if you pull the lever 1000 times you generate a good idea and thus a successful piece of software can be made. This seems like a distinctly Silicon Valley, SFBA type mentality. Steve Jobs didn't invent the iPhone by creating 1000 different throwaway products to test the market. Etc etc.
Why would I do that if the gateway to the internet becomes these LLM interfaces? How is it not easier to ask or type 'buy me tickets for Les Mis'? In the ideal world it will just figure it out, or I frustratingly have to interact with a slightly different website to purchase tickets for each separate event I want to see.
One of the benefits that I see is as much as I love tech and writing software, I really really do not want to interface with a vast majority of the internet that has been designed to show the maximum amount of ads in the given ad space.
The internet sucks now, anything that gets me away from having ads shoved in my face constantly and surrounded by uncertainty that you could always be talking to a bot.
I'm sympathetic to this view too, but I don't think the solution is to have LLM's generate bespoke code to do it. We absolutely should be using them for more natural language interfaces tho.
Yeah, that can also work. But I don’t see the future of software is to keep building multimillion line of code systems in a semi manual way (with or without llms). I think we will reach a phase in which we’ll have to treat code as disposable. I don’t think we are there yet, though.
We probably need higher levels of abstraction, built upon more composable building blocks and more interplay between various systems. To me that requires less disposable code though.
seriously. I don't even wanna compile code when binaries are available in a repository. the thought of everybody preferring vibe-coding something on their own over using something that's battle-tested and available to the collective is just crazy to me.
My point is: such apps wouldn’t need to exist if agents can provide in the future the same functionality for a fraction of the cost. Sure if ticketmaster is here to stay forever and keep their app up to date, we can keep using it. But what about new products? Would companies decide to build a single fixed app that all the users have to use, instead of, well, not building it? Sure the functionality would still need to be provided by the company (e.g., like offered in the form of an api), so they keep getting profit.
It’s like we usually say: companies should focus on their core value. And typically the ui/ux is not the core value of companies.
So we burn the planet up to deploy individually craft UIs on demand? I mean, I've read your comment three times, and I just don't see it. If we end up in that future, we're doomed.
> And typically the ui/ux is not the core value of companies
Huh? The user experience is basically ALL of the core product of a company.
If it's so easy for an AI to create ticket purchasing software that people can generate it themselves, then it's also true that the company can also use AI to generate that software for users who then don't need to generate it themselves. Obviously I think neither of these things are true or likely to happen.
> Huh? The user experience is basically ALL of the core product of a company.
Thats the case now, but I think it’s because there’s no other way around it nowadays. But if agents in the future provide a better or more natural ui/ux for many use cases, then companies core value will shift more into their inner core (which in software translates typically to the domain model)
> If it's so easy for an AI to create ticket purchasing software that people can generate it themselves, then it's also true that the company can also use AI to generate that software for users who then don't need to generate it themselves.
I think the generation of software per se will be transparent to the user. Users won’t think in terms of software created but wishes their agents make true.
Aren’t we kinda realising that disposable/throwaway stuff is, like, bad? Why do we have to go down this wasteful and hyper-consumptive route AGAIN. Can we try and see the patterns here and move forwards?
Agree in general. I don’t see how making an agent create software is more wasteful than making dozens of engineers create the same thing. The latter seems more wasteful.
We have compilers creating binaries every single day. We don’t say thats wasteful.
Well ticketmaster (for example) is used by millions of people. It seems to me like spinning up millions of LLMs to produce a million different apps is way more wasteful than having a dozen developers produce one efficient app that everyone can use?
This is also where I think we end up. If the behavior of the system is specified well enough, then the code itself is cheap and throwaway. Why have a static system that is brittle to external changes when you can just reconstruct the system on the fly?
Might be quite awhile before you can do this with large systems but we already see this on smaller contextual scales such as Claude Code itself
The specification for most systems _is the code_. English cannot describe business rules as succinctly as code, and most business rules end up being implied from a spec rather than directly specified, at least in my experience.
The thought of converting an app back into a spec document or list of feature requests seems crazy to me.
> If the behavior of the system is specified well enough
Then it becomes code: a precise symbolic representation of a process that can be unambiguously interpreted by a computer. If there is ambiguity, then that will be unsuitable for many systems.
eventually people will figure out what is safe to let AI build-and-run without supervision, and what level of problem do you need to actually understand what's under the hood, audit what it does, how to maintain it, etc
I need a way to inventory my vintage video games and my wife's large board game collection. I have some strong opinions, and it's very low risk so I'll probably let Claude build the whole thing, and I'll just run it
Would I do that with something that was keeping track of my finances, ensuring I paid things on time, or ensuring the safety of my house, or driving my car for me? Probably not. For those categories of software since I'm not an expert in those fields, but also it's important that they work and I trust them, I'll prefer software written and maintained by vendors with expertise and a track record in those fields
It used an existing implementation, in theory this was mostly a porting task.
GPL-wise, I don't know how much is inspiration vs "based on" would this be, it'd be interesting to compare.
This looks like my Company peers, as long as there is any existing implementation they are pretty confident they can deliver, poor suckers that do the "no one has done it before" first pass don't get any recognition.
AI wouldn't work here. The OP task was converting one open source driver in to another one for FreeBSD. Since Mac doesn't have open source drivers to start with, a person still has to do the ground research. At least until you can somehow give the AI the ability to fully interact with the computer at the lowest levels and observe hardware connected to it.
We don't use AI to help write code due to copyright concerns, it's against our policy. We obviously need to be very careful with what we're doing, and we can't be sure it hasn't seen Apple docs or RE'ed Apple binaries etc (which we have very careful clean-room policies on) in its training data. It also can't be guaranteed that the generated code is GPL+MIT compatible (as it may draw inspiration from other GPL only drivers in the same subsystems) but we wish to use GPL+MIT to enable BSD to take inspiration from the drivers.
Given that literally no one is enforcing this it seems like a moral rather than a business decision here no? Isn’t the risk here that your competitors, who have no such moral qualms, are just going to commit all sorts of blatant copyright infringement but it really doesn’t matter because no one is enforcing it?
I don't see open source as having "competitors". If someone wants to make a fork and use AI to write code (which I also think wouldn't be very useful, as there's no public documentation and everything needs to traced and RE-ed), they are welcome to. We're interested in upstreaming though, which means we need to make sure the origin of code and licence is all compatible and acceptable for mainline, and don't want to infringe on Apple's copyright (which they may enforce on a fork with less strict rules than ours).
Your LICENSE file reminds me that the copyright status of LLM-generated code remains absolutely uncharted waters and it's not clear that you can in fact legally license this under ISC
> The person intentionally didn't put in much effort.
And it's incredible that they got a somewhat working wifi driver given just how little effort they put in.
I have no doubt that a motivated person with domain knowledge trying to make a robust community driver for unsupported hardware could absolutely accomplish this in a fraction of the time and would be good quality.
AI didn't write a driver for him. He ported the Linux driver to FreeBSD with some assistance from an LLM.
What's more interesting to me is the licensing situation when this is done. Does the use of an LLM complicate it? Or is it just a derivative work which can be published under the ISC license [1] as well?
An impressively softwarey alternative to simply pulling out the wifi module and replacing it with an AliExpress Apple wifi module adapter board and a compact M.2 WiFi module with a supported chipset :)
the spec-first approach is actually the historical clean-room technique, same way Phoenix BIOS was legally written without copyright exposure in the 80s -- one team writes spec from observation, completely separate team codes from spec only, no shared authors. here it's AI doing both passes but in different sessions with no shared context, which approximates the same separation. probably good enough legally but definitely interesting that the same old trick applies.
You haven't addressed the parent's concern at all, which is that what the LLM was trained on, not what was fed into its context window. The Linux driver is almost certainly in the LLM's training data.
Also, the "spec" that the LLM wrote to simulate the "clean-room" technique is full of C code from the Linux driver.
The Linux community has been doing this since forever.
Old hardware is fully supported on Linux, unless of course, you are a macOS fanboy because Apple will do everything to preventing you from owning your hardware, including locking hardware ID via firmware.
I don’t think Apple is any different than any other vendor who doesn’t bother releasing Linux drivers? support for most devices depends on the community creating them no?
If you’re a macOS fanboy presumably you don’t care about Linux support.
>I don’t think Apple is any different than any other vendor
Read my previous comment again!!
If you buy a genuine display and install it, it won't work because Apple locks the hardware ID via firmware.
It must be installed by Apple only.
No other vendor does that, the Linux community always found its way to get a non-supported hardware working.
Windows until recently with the AI slope, was the only major OS used everywhere so why many vendors only have Windows driver, I understand theirs "Why bother?"
Apple may not design for repairability, but what you are saying is not true. I have personally purchased and installed genuine replacement displays on MacBooks with no involvement from Apple.
Apple publishes repair guides for this (e.g., https://support.apple.com/en-us/120768) as does iFixit. Genuine parts are available for purchase and tools are available to rent by individuals (see https://support.apple.com/self-service-repair, which specifically mentions display replacement). Skill and patience are required; replacement by Apple is not.
> I didn’t write any piece of code there. There are several known issues, which I will task the agent to resolve, eventually. Meanwhile, I strongly advise against using it for anything beyond a studying exercise.
Months of effort and three separate tries to get something kind of working but which is buggy and untested and not recommended for anyone to use, but unfortunately some folks will just read the headline and proclaim that AI has solved programming. "Ubiquitous hardware support in every OS is going to be a solved problem"! Or my favourite: instead of software we will just have the LLM output bespoke code for every single computer interaction.
Actually a great article and well worth reading, just ignore the comments because it's clear a lot of people have just read the headline and are reading their own opinions into it.
You're validly critiquing where it is now.
The hype people are excited because they're guessing where it's going.
This is notable because it's a milestone that was not previously possible: a driver that works, despite OP needing ~zero of their own driver or hardware knowledge to help. It's not production ready, but neither is the first working version of anything. Do you see any reason progress will stop abruptly here?
Not a huge fan of @sama, but he is quoted as saying: this is the worst these models will every be!
Puts all criticism in a new perspective.
> Do you see any reason progress will stop abruptly here?
Yeah, money and energy. And fundamental limitations of LLM's. I mean, I'm obviously guessing as well because I'm not an expert, but it's a view shared by some of the biggest experts in the field ¯\_(ツ)_/¯
I just don't really buy the idea that we're going to have near-infinite linear or exponential progress until we reach AGI. Reality rarely works like that.
The author specifically said that they did not read the code or even test the output very thoroughly. It was intentionally just a naive toy they wanted to play around with.
Nothing to do with AI, or even the capabilities of AI. The person intentionally didn't put in much effort.
> Nothing to do with AI, or even the capabilities of AI. The person intentionally didn't put in much effort.
The part to do with AI is that it was not able to drive a comprehensive and bug free driver with minimal effort from the human.
That is the point.
> The author specifically said that they did not read the code or even test the output very thoroughly. It was intentionally just a naive toy they wanted to play around with.
Yes and that's what I'm pointing out, they vibe coded it and the headline is somewhat misleading, although it's not the authors fault if you don't go read the article before commenting.
But it does have to do with AI (obviously), and specifically the capabilities of AI. If you need to be knowledgable about how wifi drivers work and put in effort to get a decent result, that obviously speaks volumes about the capabilities of the vibe coding approach.
I strongly suspect that somebody with domain knowledge around Wi-Fi drivers and OS kernel drivers could prompt the llm to spit out a lot more robust code than this guy was able to. That's not a knock on him, he was just trying to see what he could do. It's impressive what he actually accomplished given how little effort he put forth and how little knowledge he had about the subject.
Someone with domain knowledge could also just write the code instead of trying to get the stochastic prediction machine to generate it. I thought the whole point was to allow people without said expertise to generate it. After all, that seems to be the promise.
Clearly there wasn't much appetite for someone to do that.
It will be like that at some point soon, just not now. Are you trying to make the point that because this technology is not yet perfect the fact that it can already do so much is unimpressive?
Will it happen before or after we get fusion energy? I heard that was coming soon too.
@petcat Is your nickname a description or an instruction?
Seems like they did put in quite a bit of effort, but were not knowledgeable enough on wifi drivers to go further.
So hardware drivers are not a solved problem where you can just ask chatgpt for a driver and it spits one out for you.
> The person intentionally didn't put in much effort.
Aren't you just describing every vibe code ever?
To think about it, that is probably my main issue with AI art/books etc. They never put in any effort. In fact, even the competition is about putting least effort.
Programmers have always been in search of an additional layer of abstraction. LLM coding feeds exactly into this impulse.
> instead of software we will just have the LLM output bespoke code for every single computer interaction.
That's sort of the idea behind GPU upscaling: You increase gaming performance and visual sharpness by rendering games at lower resolutions and use algorithms to upscale to the monitor's native resolution. Somehow cheaper than actually rendering at high resolution: Let the GPU hallucinate the difference at a lower cost.
> 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.
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 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.
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).
- 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.
So we send an AI agent to the French cafe instead of us?
https://download.samba.org/pub/tridge/misc/french_cafe.txt
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
> 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.
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.
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.
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.
> But also -- how do humans do it?
Intelligence.
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?
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.
Combine AI + genetic algo?
https://www.reddit.com/r/learnmachinelearning/comments/1665d...
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.
Literally explained in the post, that’s why you read first.
Repurposing NDIS drivers is a time honored tradition. No source, but oh well.
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.
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.
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 something worthy of intense scrutiny, or if it should instead be accepted as progress.
(It is interesting to think about, though.)
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.
> 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.)
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.
Aka, the hard part.
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.
That pesky GPL does not stop us anymore, cool.
What would the GPL have to do with this?
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.
AI written driver could be a rip off Linux driver.
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
Absolutely mental behaviour for a business. What were they thinking?
> 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.
> 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.
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.
Absolutely not. Nouveau might give you a usable desktop but the second you need to do any 3d rendering or decoding it’s atrocious.
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.
I really wanted to believe the original comment as it is indeed not something I wouldn't see against - however there is truth that hardware can be capricious and one could definitely burn something flipping the wrong bit - here comes the fantastic world of Megaman ; where he's analyzing the bits of the unknown driver - one mistake could burn his owner the machine - he didn't receive the latest analysis tool ; hm...maybe some other ai knows about this on the darkclanet ?
Sorry I drifted, claude is probably done generating stuff
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.
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.
The driver used as inspiration is fully opensource
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.
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.
Unlikely. The future will be some people will do this, but honestly I think it will largely be people who were already tinkering with building things, whether full on software development or not
My mom and dad, my brother who drives a dump truck in a limestone quarry, my sister-in-law, none of them work in tech or consider themselves technical in any way. They are never, ever going to write their own software and will continue to just download apps from the app store or sign up for websites that accomplish the tasks they want
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.
What ever happened to that?
Had an experience like this recently. QEMU stopped compiling for old versions of MacOS (pre-13) w/M1 arch, due to it requiring newer SDKs which don't support older MacOS versions. I put Sonnet 4.6 on the case, and it wrote a small patch, compiled and installed it in a matter of minutes, without giving it any instructions other than to look at errors and apply a fix. I definitely would have just given up without the AI.
Software is still eating the world, now even faster. I wonder how soon we will adapt to this new situation where software is vibe coded for anything and make use of this software without caution as expressed in the article.
For most people the main difference will be: Will it run and solve my problem? Soon we will see malware being put into vibe coded software - who will wants to check every commit for write-only software?
I think in the future (in 10 years?) we are going to see a lot of disposable/throwaway software. I don’t know, imagine this: I need to buy tickets for a concert. I ask my AI agent that I want tickets. The agent creates code on the fly and uses it to purchase my tickets. The code could be simple curl command, or a full app with nice ui/ux. As a user I don’t need to see the code.
If I want to buy more tickets the same day, the ai agent will likely reuse the same code. But if i buy tickets again in one year, the agent will likely rebuild the code to adjust to the new API version the ticket company now offers. Seems wasteful but it’s more dynamic. Vendors only need to provide raw APIs and your agent can create the ui experience you want. In that regard nobody but the company that owns your agent can inject malware into the software you use. Some software will last more than others (e.g., the music player your agent provided won’t probably be rebuilt unless you want a new look and feel or extra functionality). I think we’ll adopt the “cattle, not pets” approach to software too.
Or, and hear me out here, you go to the existing site or app which sells concert tickets, press the purchase button, and then you have your tickets.
Like what are we even doing here...
I know people have done truly amazing things with AI lately, but I feel this in my bones. Almost every demo I see is like, uh, I don't need these extremely simple things in my life automated. I can just go to Delta and buy a plane ticket. I actually want to write my own email to my mom or wife. Of course a demo is just a demo, but also come on
I think it's a fallacy that if you make creating anything easier, more useful things will be created. In reality, you just end up with more useless things being created. Like with art, when it gets easier to create you don't end up with more good art. And with software - it's not like the quality of software has gone up as it's gotten easier to build, it's gotten much worse.
A related fallacy is that great things are easier to build when you can rapidly create stuff. That isn't really how great ideas are generated, it's not a slot machine where if you pull the lever 1000 times you generate a good idea and thus a successful piece of software can be made. This seems like a distinctly Silicon Valley, SFBA type mentality. Steve Jobs didn't invent the iPhone by creating 1000 different throwaway products to test the market. Etc etc.
Why would I do that if the gateway to the internet becomes these LLM interfaces? How is it not easier to ask or type 'buy me tickets for Les Mis'? In the ideal world it will just figure it out, or I frustratingly have to interact with a slightly different website to purchase tickets for each separate event I want to see.
One of the benefits that I see is as much as I love tech and writing software, I really really do not want to interface with a vast majority of the internet that has been designed to show the maximum amount of ads in the given ad space.
The internet sucks now, anything that gets me away from having ads shoved in my face constantly and surrounded by uncertainty that you could always be talking to a bot.
I'm sympathetic to this view too, but I don't think the solution is to have LLM's generate bespoke code to do it. We absolutely should be using them for more natural language interfaces tho.
Yeah, that can also work. But I don’t see the future of software is to keep building multimillion line of code systems in a semi manual way (with or without llms). I think we will reach a phase in which we’ll have to treat code as disposable. I don’t think we are there yet, though.
We probably need higher levels of abstraction, built upon more composable building blocks and more interplay between various systems. To me that requires less disposable code though.
seriously. I don't even wanna compile code when binaries are available in a repository. the thought of everybody preferring vibe-coding something on their own over using something that's battle-tested and available to the collective is just crazy to me.
My point is: such apps wouldn’t need to exist if agents can provide in the future the same functionality for a fraction of the cost. Sure if ticketmaster is here to stay forever and keep their app up to date, we can keep using it. But what about new products? Would companies decide to build a single fixed app that all the users have to use, instead of, well, not building it? Sure the functionality would still need to be provided by the company (e.g., like offered in the form of an api), so they keep getting profit.
It’s like we usually say: companies should focus on their core value. And typically the ui/ux is not the core value of companies.
So we burn the planet up to deploy individually craft UIs on demand? I mean, I've read your comment three times, and I just don't see it. If we end up in that future, we're doomed.
> And typically the ui/ux is not the core value of companies
Huh? The user experience is basically ALL of the core product of a company.
If it's so easy for an AI to create ticket purchasing software that people can generate it themselves, then it's also true that the company can also use AI to generate that software for users who then don't need to generate it themselves. Obviously I think neither of these things are true or likely to happen.
> Huh? The user experience is basically ALL of the core product of a company.
Thats the case now, but I think it’s because there’s no other way around it nowadays. But if agents in the future provide a better or more natural ui/ux for many use cases, then companies core value will shift more into their inner core (which in software translates typically to the domain model)
> If it's so easy for an AI to create ticket purchasing software that people can generate it themselves, then it's also true that the company can also use AI to generate that software for users who then don't need to generate it themselves.
I think the generation of software per se will be transparent to the user. Users won’t think in terms of software created but wishes their agents make true.
Aren’t we kinda realising that disposable/throwaway stuff is, like, bad? Why do we have to go down this wasteful and hyper-consumptive route AGAIN. Can we try and see the patterns here and move forwards?
Agree in general. I don’t see how making an agent create software is more wasteful than making dozens of engineers create the same thing. The latter seems more wasteful.
We have compilers creating binaries every single day. We don’t say thats wasteful.
Well ticketmaster (for example) is used by millions of people. It seems to me like spinning up millions of LLMs to produce a million different apps is way more wasteful than having a dozen developers produce one efficient app that everyone can use?
This is also where I think we end up. If the behavior of the system is specified well enough, then the code itself is cheap and throwaway. Why have a static system that is brittle to external changes when you can just reconstruct the system on the fly?
Might be quite awhile before you can do this with large systems but we already see this on smaller contextual scales such as Claude Code itself
The specification for most systems _is the code_. English cannot describe business rules as succinctly as code, and most business rules end up being implied from a spec rather than directly specified, at least in my experience.
The thought of converting an app back into a spec document or list of feature requests seems crazy to me.
> If the behavior of the system is specified well enough
Then it becomes code: a precise symbolic representation of a process that can be unambiguously interpreted by a computer. If there is ambiguity, then that will be unsuitable for many systems.
eventually people will figure out what is safe to let AI build-and-run without supervision, and what level of problem do you need to actually understand what's under the hood, audit what it does, how to maintain it, etc
I need a way to inventory my vintage video games and my wife's large board game collection. I have some strong opinions, and it's very low risk so I'll probably let Claude build the whole thing, and I'll just run it
Would I do that with something that was keeping track of my finances, ensuring I paid things on time, or ensuring the safety of my house, or driving my car for me? Probably not. For those categories of software since I'm not an expert in those fields, but also it's important that they work and I trust them, I'll prefer software written and maintained by vendors with expertise and a track record in those fields
It used an existing implementation, in theory this was mostly a porting task.
GPL-wise, I don't know how much is inspiration vs "based on" would this be, it'd be interesting to compare.
This looks like my Company peers, as long as there is any existing implementation they are pretty confident they can deliver, poor suckers that do the "no one has done it before" first pass don't get any recognition.
It'd be nice to have drivers for newer Mac's for a better Asahi Linux experience. Good use of AI imo.
AI wouldn't work here. The OP task was converting one open source driver in to another one for FreeBSD. Since Mac doesn't have open source drivers to start with, a person still has to do the ground research. At least until you can somehow give the AI the ability to fully interact with the computer at the lowest levels and observe hardware connected to it.
We don't use AI to help write code due to copyright concerns, it's against our policy. We obviously need to be very careful with what we're doing, and we can't be sure it hasn't seen Apple docs or RE'ed Apple binaries etc (which we have very careful clean-room policies on) in its training data. It also can't be guaranteed that the generated code is GPL+MIT compatible (as it may draw inspiration from other GPL only drivers in the same subsystems) but we wish to use GPL+MIT to enable BSD to take inspiration from the drivers.
Given that literally no one is enforcing this it seems like a moral rather than a business decision here no? Isn’t the risk here that your competitors, who have no such moral qualms, are just going to commit all sorts of blatant copyright infringement but it really doesn’t matter because no one is enforcing it?
I don't see open source as having "competitors". If someone wants to make a fork and use AI to write code (which I also think wouldn't be very useful, as there's no public documentation and everything needs to traced and RE-ed), they are welcome to. We're interested in upstreaming though, which means we need to make sure the origin of code and licence is all compatible and acceptable for mainline, and don't want to infringe on Apple's copyright (which they may enforce on a fork with less strict rules than ours).
Who is a competitor for Asahi? What would that even entail?
> Given that literally no one is enforcing this
Presumably Apple's lawyers would enforce it.
This is like complaining Delorean didn't make spare parts for your homemade time machine.
Your LICENSE file reminds me that the copyright status of LLM-generated code remains absolutely uncharted waters and it's not clear that you can in fact legally license this under ISC
Even bigger accomplishment is ai finally figured out how to configure my samba share for guest access! Lol
Do postfix/dovecot next. It still struggles with that.
Omg!!. Similarly, Do you know a way to interface with BIOS so that it can change the parameters?
We'll reverse engineer our way out of planned obsolescence
very neat, setting codex on the task of building a mac-compatible app for my Pharos Microsoft GPS-360 Receiver... we'll see how it goes!
> The person intentionally didn't put in much effort.
And it's incredible that they got a somewhat working wifi driver given just how little effort they put in.
I have no doubt that a motivated person with domain knowledge trying to make a robust community driver for unsupported hardware could absolutely accomplish this in a fraction of the time and would be good quality.
This used to be more common right? Back in the winmodem days?
AI didn't write a driver for him. He ported the Linux driver to FreeBSD with some assistance from an LLM.
What's more interesting to me is the licensing situation when this is done. Does the use of an LLM complicate it? Or is it just a derivative work which can be published under the ISC license [1] as well?
[1] : https://en.wikipedia.org/wiki/ISC_license
An impressively softwarey alternative to simply pulling out the wifi module and replacing it with an AliExpress Apple wifi module adapter board and a compact M.2 WiFi module with a supported chipset :)
That AI was trained on the GPLv2 Linux source code, which does have a driver for your Wi-Fi.
How is this not copyright laundering?
the spec-first approach is actually the historical clean-room technique, same way Phoenix BIOS was legally written without copyright exposure in the 80s -- one team writes spec from observation, completely separate team codes from spec only, no shared authors. here it's AI doing both passes but in different sessions with no shared context, which approximates the same separation. probably good enough legally but definitely interesting that the same old trick applies.
You haven't addressed the parent's concern at all, which is that what the LLM was trained on, not what was fed into its context window. The Linux driver is almost certainly in the LLM's training data.
Also, the "spec" that the LLM wrote to simulate the "clean-room" technique is full of C code from the Linux driver.
We'll know once these 51 cases have worked their way through the courts: https://chatgptiseatingtheworld.com/2025/10/08/status-of-all...
Prove the new code is similar to the corresponding driver in Linux. If you can then you can get the authors of the latter to file suit against TFA.
A very, very good point
This is really neat, I'm glad it worked.
This is atrocious C code.
Looks fairly idiomatic. What specifically do you dislike about it?
Got a sample you think is particularly bad?
Plus zig!
https://github.com/narqo/freebsd-brcmfmac/blob/be9b49c1bf942...This is exciting! This sounds like a great application because it’s mostly tedious work to adjust an existing driver to another device.
The Linux community has been doing this since forever. Old hardware is fully supported on Linux, unless of course, you are a macOS fanboy because Apple will do everything to preventing you from owning your hardware, including locking hardware ID via firmware.
This isn't a news to be in here.
AIs being able to do this has not been around "since forever" though.
what a salty comment
I don’t think Apple is any different than any other vendor who doesn’t bother releasing Linux drivers? support for most devices depends on the community creating them no?
If you’re a macOS fanboy presumably you don’t care about Linux support.
>I don’t think Apple is any different than any other vendor
Read my previous comment again!! If you buy a genuine display and install it, it won't work because Apple locks the hardware ID via firmware. It must be installed by Apple only.
No other vendor does that, the Linux community always found its way to get a non-supported hardware working.
Windows until recently with the AI slope, was the only major OS used everywhere so why many vendors only have Windows driver, I understand theirs "Why bother?"
Apple may not design for repairability, but what you are saying is not true. I have personally purchased and installed genuine replacement displays on MacBooks with no involvement from Apple.
Apple publishes repair guides for this (e.g., https://support.apple.com/en-us/120768) as does iFixit. Genuine parts are available for purchase and tools are available to rent by individuals (see https://support.apple.com/self-service-repair, which specifically mentions display replacement). Skill and patience are required; replacement by Apple is not.
> any different than any other vendor who doesn’t bother releasing Linux drivers
Which has dwindled in number so much as to practically not be problem anymore. There is even a Linux-only or Linux-first attitude with some vendors.
Buying Apple to run Linux borders on stupidity nowadays because of the vast better options fit for purpose.
Like buying a gasoline vehicle then complaining it can't run on diesel. It wasn't designed to.
THANK YOU!!!!!!
Most vendors are different from Apple in that they don't have their own OS and software ecosystem that is in direct competition with Linux.