FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me
vladimir.varank.in
vladimir.varank.in
I can pass a technical interview just fine to prove my abilities. I don't get into pissing contests with others about GH contribs or FOSS project badges.
If someone can't prove their skill at coding beside pointing to their Github, or if they think that code contribs are some kind of badge of honor, I tend to look down on them. Being anti-LLM just to maintain the special green-box-based internet points they've built up in their head to feel better, is worthy of at least 'scare quote' derision imo.
With some effort OP could review it manually and then try to submit it though.
But QEMU uses a mailing list for development, it's tedious to set up and then later keep track of. I now fundamentally refuse to contribute to projects that use mailing lists for development, the effort it takes and the experience is just so horrible.
Especially if it's a small patch that doesn't concern anyone (any big sponsors), you'll probably never get a response. Things get lost easily.
2) I sent the patch to MacPorts which is what I was using and also had failed builds, and the maintainers closed my submission as a dupe (of a ticket which actually didn't have the full patch nor anyone testing it). I offered to do more investigation, no response
3) It's open source, I really don't owe anyone anything, nor they me
Planning markdown files are critical for any large LLM task.
ISC License
Copyright (c) 2010-2022 Broadcom Corporation
Copyright (c) brcmfmac-freebsd contributors
Based on the Linux brcmfmac driver.https://github.com/torvalds/linux/blob/master/drivers/net/wi...
// SPDX-License-Identifier: ISC
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
Billions of dollars of stock market value disappeared because of the concern AI can create core SaaS functionality for corporations instead of them spending millions of dollars in licensing fees to SAP, Microsoft, etc.
This not about tinkering.
SaaS As We Know It Is Dead: How To Survive The SaaS-pocalypse! - https://www.forrester.com/blogs/saas-as-we-know-it-is-dead-h...
Why SaaS Stocks Have Dropped—and What It Signals for Software’s Next Chapter - https://www.bain.com/insights/why-saas-stocks-have-dropped-a...
Jim Cramer says AI fears have made the stock market fragile - https://www.cnbc.com/2026/02/23/jim-cramer-says-ai-fears-hav...
I have a lot of friends in the tech sector, but outside the FANNG/silicone valley/startup bubbles. It's been largely business as normal across the board. Twitter and social media warps our perspective I think.
2. Gemini says covid-19 killed 0.086% of world population (over several years). That's about as mild as it gets. More than sharks, but less than anything that usually kills people, like air polution (estimated about 0.095% yearly), cancer (est 0.12% every damn year) or cardiovascular disease (est 0.25% a year). Peak covid was still killing less than business-as-usual cancer or cardiovascular disease.
As far as pandemics go, the deadliest ones kill double digit percentage of people who contract them. That's two orders of magnitude more than covid. Even the single-digit percentage pandemics must be extremely rough. We were lucky[0].
[0]: Not the ones who died or have lasting consequences, but "we" as humanity, were rather lucky with covid. It could've been something much worse.
In the city in my country reknowned for having a much higher level of hypochrondria before the pandemic, imagine the mental health issues my city is going through now.
Cancer and heart disease together kill the same number of people as the whole covid pandemic every 10-12 days.
That's really the key, right there. The value disappeared because of concern, not of anything real.
When ungodly amounts of money is governed entirely by vibes, it's hardly surprising they lose ungodly amounts of money to vibe-coding.
The downside is the effects of all that money shifting is very real :(
The value also only existed in the first place because of belief, in future work, operations, profits, etc.
Like it or not, confidence in institutions is society. Concern that affects that confidence is as real as any other societal effect.
If the P/E = 1 then there would be no sell-off. Looks at utility stocks with divs, they don't sell off [as sharply] when there is AI news.
Or perpetual work camps for the masses.
Was it when we tamed fire, invented the wheel, writing, or double entry bookkeeping? All of which appear more consequential than current AI.
We’ll always have something to do. And humans like doing things.
Fire can't build a house.
The wheel can't grow crops.
Writing can't set a broken bone.
Double entry bookkeeping can't write a novel.
If you believe that this AI+robotics wave will be able to do anything a human can do with fewer complaints, what would the humans move on to?
David Graeber did a thing on the topic where he called the subset he was interested in "bullshit jobs".
(I don't think technological innovation leads to permanent job loss, but some people will lose)
History doesn't predict the future. I can't tell you about another time when humans ran out of usefull things to do. What I can tell you is that we humans are biological beings we limited cognitive and physical abiloties.
I can also tell you about another biological being whose cognitive and phyisical abilities were surpassed by technology. Horses. What happened to them then wasn't pretty. The hight of their population in US was in 1915.
And sure, humans like doing things and so do horses, but you can't live by doing things that aren't useful to others, at least not in the current system. If technology surpases our abilities, the only useful things left to do for vast majority of humans is the same thing that was left for horses to do. Entertainment in various forms and there won't be enough of those jobs for all of us.
Can you name me another time when big swaths of highly paid population were laid off due to redundancy and how did it go for the population?
Also, another hint: I couldn’t care less what is going to happen to “humanity”. “Humanity” isn’t the one who pays my bills and puts food on my table.
I would be profoundly ashamed to write such words on any public forum, myself.
However, I fear that probably, most people don't think like me, but feel the way you claim to. :-(
Off to bust my virtual knuckles on something.
We'll be right back here in no-time.
The best we could achieve were the projects that got so burned that near shore started to become an alternative, but never again in-house.
As proven by offshoring, it is a race to the bottom, as long as software kind of works.
I did the same with my car, technically I could do maintenance myself and troubleshoot and what not, but I just couldn't be arsed, so I outsource it at a premium price.
They'll just ask their bank to help them fill out a family income form based on last year's earnings. They'll get the numbers back, without thinking about the Python script that used Pandas and some web APIs to generate those numbers. They'll think about it in terms of "that thing that Chat GPT just gave me to compare truck from nearby local dealers", without realizing that it's actually a React app, partially powered by reverse-engineered APIs, partially by data that their agent scraped off Facebook and Craigslist.
To the matter of driving a truck though, if someone needs an app idea, blue collar workers are having to spend an hour after work logging what they did that day. If they could do it in their truck while driving home for the day, you could make a pile of cash selling an app that lets them do that.
Yeah, I've seen perfectly good flexible in house products abandoned because it was just easier to hire people who knew Salesforce or whatever.
But the true AI Believer would object you don't need to hire anymore, you can just get more agents to cold call or whatever :)
My assumption is that eventually the VC-backed gravy train of low-cost good-quality LLM compute is going to dry-up, and I'm going to have to make do with what I got out of them.
The majority of computer users are not on HN.
You profile says "Trying to figure out what I want to do with my life. DM me if you have ideas." - I would recommend exploring connections and opinions outside tech.
Right now, there's only one Google algorithm, one Amazon search and so on. The moment you let agents run wild, each with a different model, prompt and memory, effectively introducing randomness into the process, it becomes much harder to optimize for "metric go up."
Quality go down.
The quality will always be lower for a new product/ production line, because 1) it hasn't had the time to iterate that got the established, big-name producers to where they are, and 2) it democratizes the market to allow for lower-quality version that weren't fiscally feasible under a more complex (and thus expensive) manufacturing/ production base.
But after the market normalizes, it will start to naturally weed out the price-divorced low-quality products, as people will figure out which ones are shitty even for their price, and the good-for-their-price ones will remain.
Eventually you'll end up with a wider range of quality products than you started with, at a wider range (especially at the low end, making products more accessible) than when it started.
High barrier of entry marketplaces only benefit big companies who don't want to actually compete to stay on top.
Tying it back to the discussion here...
Sure, AI will produce a million shitty Google clones, but no one is using them but their makers. Eventually the good ones will start to inch up in users as word gets around, and eventually one might actually make an inroad that Google has to take note of.
Free and open marketplace, crapware. Crapware for long enough, goodware. Goodware so good, it needs hardware, it needs integrations, it solves world hunger, but no one uses anything else anymore.
No, the best are marketplaces that are open but moderated for quality.
There is no such thing 'moderated for quality' when authority is at play, only 'moderated for control'.
Quality-first requires free association, which requires a free market.
how will stock prices rise, outside of the one holder of the AI?
Now, since Claude Code is banning accounts for usage of pi (or rather, how pi is configured to use Claude models), how complicated would it be to wire pi through Anthropic's harness and treat anthropic harness as a dumb shell?
Google does the same, and it seems Google is much more aggressive about it, I've seen way more reports of Google bans than Anthropic.
Just one example here: https://github.com/anomalyco/opencode/issues/6930
Article says,
> Brcmfmac is a Linux driver (ISC licence) for set of FullMAC chips from Broadcom
I don't feel like looking to see where the Linux driver came from, but someone provided a permissively-licensed driver.
It's originally from Broadcom themselves. A lot of Broadcom hardware runs linux natively (i.e. mobile and embedded CPUs), and a ton more of it ships in linux-adjacent devices (routers, android devices, etc)
People should be empowered to share and tinker, without feeling like they need to setup a bug bounty program first. Not every GitHub project is a vendor/customer relationship.
There are people for whom a software that compiles without error is for productive use cases
> Someone might try to use it and get pwned!
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.
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.
For instance: A microphone (optionally: a calibrated microphone; extra-optionally: in an isolated anechoic chamber) is a simple way to get feedback back into the machine about the performance of a speaker. (Or, you know: Just use a 50-cent audio transformer and electrically feed the output of the amplifier portion of the [presumably active] speaker back into the machine in acoustic silence.)
And I don't have to stray too far into the world of imagination to notice that the hairy, custom Cartesian printer in the corner of the workshop quite clearly resembles a machine that can move a mouse over a surface in rather precise ways. (The worst that can happen is probably not as bad as many of us have seen when using printers in their intended way, since at least there's no heaters and molten plastic required. So what if it disassembles itself? That's nothing new.)
Whatever the testing jig consists of, the bot can write the software part of the tests, and the tests can run as repetitiously as they need to.
I can't find the video clip atm, but there's a neat (likely leaked) Foxxconn video that shows a really neat testing jig for Apple trackpads.
The fun part is that some of us (actually, in this particular crowd, many of us) already have a lot of what we need to get some automated testing done at home, and we may not even realize it. :)
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.
It sure seems like AI agents can sidestep all that by claiming ignorance on license matters.
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.
Absolutely mental behaviour for a business. What were they thinking?
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.
It's a bhyve VM running alpine Linux and you pass through your WiFi adaptor and get a bridge out on the freebsd host.
Intelligence.
Probably a mix of critical thinking, thinking from first principles, etc. You know, all things that LLM's are not capable of.
Isn't that...code?
And sure, the human language formal instructions often appear inside tables or diagrams, that doesn't make them anything less so.
This is based on having worked with companies that do projects in the 10 figure range.
Usually, the problem with developing a driver isn't "writing the code," it's "finding documentation for what the code should do."
- 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.
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?
Consider that even with the Linux driver available to study, this project took two months to produce a viable BSD driver.
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.
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.
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.
It also doesn't matter if AI is involved - you save yourself trouble either way.
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.
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.
> I'm going to ahead and say there are copyright law nightmares, right here.
// SPDX-License-Identifier: ISC
/*
* Copyright (c) 2010 Broadcom Corporation
*/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.
Anyway, nobody is going to sue you because you added your name (or "project contributors") to an ISC licensed source file in your own repository. Nobody cares. And there's no damages anyway.
Especially when the line added is:
> Copyright (c) brcmfmac-freebsd contributors
If you're right, that's an empty category. Thus the inclusion has no effect.
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.)
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.
https://www.reddit.com/r/learnmachinelearning/comments/1665d...
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?
Wonder if the courts will move fast enough to generally matter.
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.
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.)
AI is notoriously bad at dealing with bugs that only cause problems every few weeks.
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.
Yeah, but that only works for so long as the AI doesn't brute force a command that hard-bricks the device. Say, it causes a voltage controller to give out way too high voltages by a command, burns e-fuses or erases vital EEPROM data (factory calibration presets come to my mind here).
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?
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.
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 thought of converting an app back into a spec document or list of feature requests seems crazy to me.
For your proposed system to work one must have a deterministic way of sending said spec to a system(Compiler?) and getting the same output everytime.
Input/Output is just one thing, software does a lot of 'side effect' kind of work, and has security implications. You don't leave such things to luck. Things either work or don't.
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.
If you’re worried about them achieving the 98%, worry no more, due to the probabilistic nature it will eventually converge on 9’s. Just keep sending the system through the probabilistic machine until it reaches your desired level of nines
You mean to say if the unit and functional tests cases are given the system must generate code for you? You might want to look at Prolog in that case.
>>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
We have been able to do something like this reliably for like 50 years now.
Like what are we even doing here...
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.
Well, if you lower the competence bar required to do something, then more people of lower competence will do that thing.
It's harder to buy one plane ticket for the lowest cost amongst all the different ways that plane tickets can be bought, and harder yet to do so with a lack of specificity.
So, for instance: Maybe I don't have a firm plan. Maybe I'm very flexible.
Maybe all I want to do is say "Hey, bot. I want to go visit my friend in Florida sometime in the next couple of weeks and spend a few days there as inexpensively as I can. He's in Orlando. I can fly out of Detroit or Cleveland; all the same to me. If I drive to the airport myself, I'll need a place to keep my car at or near the airport. I also want to explore renting a car in Orlando. I pack light; personal bag only. Cattle class is OK, but I prefer a window seat. Present to me a list of the cheapest options, with itinerary."
That's all stuff that a human can sort out, but it takes time to manually fudge around dates and locations and deal with different systems and tabulate the results. And there's nuances that need covered, like parking at DTW is weird: It's all off-site, and it can be cheaper and better to rent a room for one night in a nearby hotel that includes long-term parking than to pay for parking by itself.
So the hypothetical bot does a bunch of API hits, applies its general knowledge of how things flow, and comes back with a list of verified-good options for me to review. And then I get to pick around that list, and ask questions, and mold it to best fit my ideal vision of an inexpensive trip to go spend time with a friend.
In English, and without ever dealing with any travel websites myself.
"Right. So I go to Detroit on Tuesday and check in at the hotel any time after noon, and take the free shuttle to the airport the next morning at around 0400 to the Evans terminal. Also, thanks for pointing out that this airport is like a ghost town until 0600 and I might want to bring a snack. Anyway, I get on the flight, land at Orlando, and they'll have a cheap car waiting for me at Avis. This will all cost me a total of $343, which sounds great. If that's all I need to know right now, then make it so. Pay for it and put it on my calendar."
(And yeah, this is a problem that I actually have from time to time. I'd love to have a bot that could just sort this stuff out with a few paragraphs.)
What you describe will just end up a feature on Expedia. The highly technical builders of stuff that love to tinker vastly overestimate how much BS the general public will put up with
I didn't address that concept at all above, but I think the notion of a million people each independently using the bot to write a million bespoke programs that each do the same things is...kind of a non-starter. It's something that can only happen in some weird reality where software isn't essentially free to copy, and where people are motivated neither by laziness, nor the size of their pocketbook.
If/when someone does put the work into getting it to happen, then I expect to find it on Github for people to lazily copy and use, or for them to make it available as a website or app for anybody to use (with even more laziness) -- and for them to monetize it.
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.
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.
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.
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.
But if the LLM needed to write bespoke code to buy the tickets or whatever, it could just do it without needing to get you involved.
- You have to work; you can't stay online all day waiting for the tickets to go on sale
- You have your agent watch for when the tickets go on sale
- Because the agent has its own wallet, it spends the 6 hours waiting for the tickets to go on sale and buys them for you
- Your agent informs you via SMS, iMessage, email, Telegram or whatever messaging platform of your choice
Yes agentic wallets are a thing now [1].
[1]: https://x.com/CoinbaseDev/status/2023893470725947769?s=20
Or not, because other 7 billion agents were also waiting for it.
Endless queues, scalpers grabbing tickets within a second. Having to wait days/weeks periodically checking to see if a ticket is available.
The only platform I’m aware of that does guarantee a ticket can be purchased if available is Dice once you join a wait list. You get given a reasonable time to purchase it in too.
So I can see why people would prefer to defer this to an agent and not care about the implementation, I personally would. In the past I’ve been able to script notifications for it for myself and can see more people benefiting from it.
We have compilers creating binaries every single day. We don’t say thats wasteful.
Even now, with OpenClaw and all of the spinoffs, it's possible to have n agent do this today.
[1]: https://claude.com/blog/equipping-agents-for-the-real-world-...
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
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.
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.
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.
Nothing to do with AI, or even the capabilities of AI. 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.
So hardware drivers are not a solved problem where you can just ask chatgpt for a driver and it spits one out for you.
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.
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 do it for them? And if it only took minor tweaks to the prompt to have it write drivers for all the myriad combinations of hardware and software? At that point, there might be enough time to write it all.
Just because people exist that can DO all the work doesn't mean we have enough person-hours to do ALL the work.
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.
If your operating system was regenerated every day slightly differently and with certain things working and others not, you’d quickly revert to the lower predictable abstraction.
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.
Programming is different in that you don't usually have senior engineers rewrite code written by junior engineers. On the other hand, look at how the Linux kernel is developed. You have Linus at the top, then subsystem maintainers vetting patches. The companies submitting patches presumably have layers of reviewers as well. Why couldn't you automate the lower layers of that process? Instead of having 5 junior people, maybe you have 2 somewhat more senior people leveraging AI.
This is probably not sustainable unless the AI can eventually do the work the more senior people are doing. But that probably doesn't matter in the short term for the market.
But the whole goal of software engineering is not about getting the recipe to the machine. That’s quite easy. It’s about writing the correct recipe so that the output is what’s expected. It’s also about communicating the recipe to fellow developers (sharing knowledge).
But we are not developing recipe that much today. Instead we’ve built enough abstractions that we’re developing recipes of recipes. There’s a lot of indirection between what our recipe says and the final product. While we can be more creative, the failure mode has also increased. But the cost of physically writing a recipe has gone down a lot.
So what matters today is having a good understanding of the tower of abstractions, at least the part that is useful for a project. But you have to be on hand with it to discern the links between each layer and each concept. Because each little one matters. Or you delegate and choose to trust someone else.
Trusting AI is trusting that it can maintain such consistent models so that it produces the expected output. And we all know that they don’t.
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.
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, from someone who spent ~zero effort learning the hardware or driver programming themselves.
It's not production ready, but neither is the first working version of anything. Do you see any reason that 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.
Read what I wrote.
I'm saying is if you bet AGAINST [LLM] scaling laws--meaning you bet that the output would peter out naturally somehow--you've lost 100% so far.
100%
Tomorrow could be your lucky day.
Or not.
I guess we'll see :)
What I’m saying is that we act as though claims about these scaling laws have never been tested. People feel free to just assert that any minute now the train will stop. They have been saying that since the Stochastic parrots.
It has not come true yet.
Tomorrow could be it. Maybe the day after. But it would then be the first victory.
I think of it as just another leap in human-computer interface for programming, and a welcome one at that.
We don’t need anything close to AGI to render the job “software engineer” as we know it today completely obsolete. Ever hear of a lorimer?
The other possibility is, as you say, progress slows down before its better than humans. But then how is it replacing them? How does a worse horse replace horses?
Progress in LLMs will not slow down before they are better at programming than humans. Not “better than humans.” Better at programming. Just like computers are better than humans at a whole bunch of other things.
Computers have gotten steadily better at adding and multiplying and yet there is no AGI or expectation thereof as a result.
All the current AI success is due to computers getting better at adding and multiplying. That's genuinely the core of how they work. The people who believe AGI is imminent believe the opposite of that last claim.
That is a position to take.
I do agree that exponential progress to AGI is speculation.
Puts all criticism in a new perspective.
If Windows XP were fully supported today I still wouldn't use it, personally, despite having respect for it in its era. The core technology of how, eg OS sandboxing, security, memory, driver etc stacks are implemented have vastly improved in newer OSes.
The original "worst" quote is implying SOTA either stays the same (we keep using the same model) or gets better.
People have been predicting that progress will halt for many years now, just like the many years of Moore's law. By all indications AI labs are not running short of ideas yet (even judging purely by externally-visible papers being published and model releases this week).
We're not even throwing all of what is possible on current hardware technology at the issue (see the recent demonstration chips fabbed specifically for LLMs, rather than general purpose, doing 14k tokens/s). It's true that we may hit a fundamental limit with current architectures, but there's no indication that current architectures are at a limit yet.
After we landed on the moon people were hyped for casual space living within 50 years.
The reality is it often takes much much longer as invention isn't isolated to itself. It requires integration into the real world and all the complexities it meets.
Even moreso, we may have ai models that can do anything perfectly but it will require so much compute that only the richest of the rich are able to use it and it effectively won't exist for most people.
I do. When someone thinks they are building next generation super software for 20$ a month using AI, they conveniently forget someone else is paying the remaining 19,980$ for them for compute power and electricity.
That approach could work, though it'll require a lot of brute-forcing from the AI and loading a lot of broken kernels to see if they work. Plus, if audio drivers are involved, you'd probably blow out the speakers at least once during testing.
Still, if you throw enough money at Claude, I think this approach is feasible to get things booting at the very least. The question then becomes how one would reverse-engineer the slop so human hands can patch things to work well afterwards, which may take as much time as having humans write the code/investigate hardware traces in the first place.
> Given that literally no one is enforcing this
Presumably Apple's lawyers would enforce it.
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?
Now one side is collecting the necessary tokens to get the AI to output data from the training set in the second run.
cool result from this otherwise defunct hardware!
How is this not copyright laundering?
> Brcmfmac is a Linux driver (ISC licence) for set of FullMAC chips from Broadcom
Text boxes are now drawn with nested DIV hells created by polyfills and layers of React crepe cake and not a simple drawRect call to draw the text box
Windows and Linux have been moving drivers towards userland to deal with kernel instability and security risks but with modern virtualisation capabilities, I think going one step further only makes sense. Windows itself is already using something called "virtualisation based security" to leverage VMs to secure the kernel and this is just the logical next step.
Qubes does this stuff too, though it works with fully-featured Linux kernels rather than minimal driver interfaces, for exactly the same reasons. A hacked wifi driver may be able to inspect and redirect traffic, but it can't do much more than that, which combined with a strong VPN can protect from quite complicated attack scenarios that normal people have no other recourse against.
https://unix.stackexchange.com/questions/536436/linux-modify... suggests there may be risks involved using efivar to configure Apple hardware, as there probably isn't any kind of testing or validation present on the variables you set, but if you know what you're doing you should have similar control as you'd have on native macOS I believe.
I have exact MacBook and chipset that op is claiming to support.
The driver doesn't even compile without modifications.
It attach to the device, but you can't scan, associate or do anything.
Basically the whole driver is stubbed.
This is atrocious C code.
pcie.c
/*
* BAR0 register access
*/
uint32_t
brcmf_reg_read(struct brcmf_softc *sc, uint32_t off)
{
return (bus_space_read_4(sc->reg_bst, sc->reg_bsh, off));
}
All throughout this codebase variables are declared and not initialized. Magic numbers are everywhere AND constants are defined everywhere. Constants are a mix of hex and int for what seem to be completely arbitrary reasons. Error handling is completely inconsistent, sometimes a function will return 5 places, sometimes a function will set an error code and jump to a label, and sometimes do both in the same function depending on which branch it hits.
All of this is the kind of code smell I would ask someone to justify and most likely rework.
Or I'm just a dumbass, I suppose I'll find out shortly.
Some application code bases I've worked in would have asserts in every function since they get removed in release builds but I don't know that debug builds are even a thing in kernel devices.
I think that is the crux of the problem. How do you know code smell if you don't write it, and you don't read it? I'm pretty confident the spdx header isn't correct even.
**Decision**: Use C for kernel interactions, Zig for pure logic only.
Using an entire additional programming language for 229 lines of code is definitely an interesting choice.
https://grafana.com/blog/generative-ai-at-grafana-labs-whats...
Don't use it and don't use Grafana.