I'm a bit confused why another userland needed to be created on top of the NetBSD kernel and libc, given NetBSD's no-LLM-output policy. I'd have thought starting with stock NetBSD then spinning up a new package repository curated down to LLM-free projects might be easier. Either way, happy hacking!
For whatever it's worth, we accept bug reports regardless of who (or what) they come from. The bug is there, it needs to be fixed. Pretending it's not there until a human comes across to point out the same bug is kind of silly. I think recently we've stopped including whatever LLM tool they used to find it in the commit message because we don't care and don't want to keep advertising for them.
I don't think we've accepted any code that is introducing new features or drivers written by LLM (that we knew of).
I'd always been under the impression NetBSD runs on pretty much anything. That's been the community's marketing line for at least two decades, that it'll even run on a toaster (provided your toaster runs ARM)
NetBSD "runs on pretty much anything" in the sense that it's highly portable and if you write the drivers, you can probably get it booting on that random piece of hardware you've got. However, "booting" (or even "usable for headless use cases") is quite far from the requirements most people have for desktop use (working audio, accelerated graphics, performant networking on the built-in network devices), never mind laptop (power management etc). It's this kind of "polish" driver work that NetBSD is lacking.
Yeah, it's easier to do a port with NetBSD than Linux since it's better structured and simpler, but the 10% of supporting peripherals is much harder than the first 90% of architecture. Assuming it even supports your architecture - NetBSD doesn't support modern Power at all.
Which is just bonkers since FreeBSD and OpenBSD (I think) does. When I finally turn my AIX POWER6 into a museum piece and replace it with the POWER9 Raptors, they'll be running FreeBSD, maybe with an AIX VM as a bridge, even though I'd rather run NetBSD since most of my other boxes do.
NetBSD was designed for a world where many CPU architectures were extant, and each one was associated with a relatively small complement of hardware accessories (and therefore drivers). This made a lot of sense in the 1990s and 2000s when minicomputers and workstations still roamed the earth. Now we have two relevant architectures and a neverending stream of hardware devices, and it's a lot harder for a small volunteer project to keep up.
NetBSD supports the CPU is different than it supporting all your hardware like WiFi and such. My understanding is that "it runs on a toaster" is the former and that it has low resource requirements.
gamache | 7 hours ago
I'm a bit confused why another userland needed to be created on top of the NetBSD kernel and libc, given NetBSD's no-LLM-output policy. I'd have thought starting with stock NetBSD then spinning up a new package repository curated down to LLM-free projects might be easier. Either way, happy hacking!
miah | 7 hours ago
Exactly, bringing in GNU tooling is actually more likely to introduce LLM slop into a NetBSD system.
I think there are probably some good ideas in this amalgamation, but I feel like if you want a better NetBSD just install OpenBSD.
lobo | 5 hours ago
OpenBSD has been accepting patches "in collaboration with Claude and Anthropic Research", so make of that what you will https://github.com/openbsd/src/commit/d180e2389c688d3ab745da6f4aab6513618538c0
jcs | 5 hours ago
For whatever it's worth, we accept bug reports regardless of who (or what) they come from. The bug is there, it needs to be fixed. Pretending it's not there until a human comes across to point out the same bug is kind of silly. I think recently we've stopped including whatever LLM tool they used to find it in the commit message because we don't care and don't want to keep advertising for them.
I don't think we've accepted any code that is introducing new features or drivers written by LLM (that we knew of).
calvin | 4 hours ago
For the audience at home: Theo was explicit on his stance with LLM written code.
WilhelmVonWeiner | 8 hours ago
I'd always been under the impression NetBSD runs on pretty much anything. That's been the community's marketing line for at least two decades, that it'll even run on a toaster (provided your toaster runs ARM)
nortti | 7 hours ago
NetBSD "runs on pretty much anything" in the sense that it's highly portable and if you write the drivers, you can probably get it booting on that random piece of hardware you've got. However, "booting" (or even "usable for headless use cases") is quite far from the requirements most people have for desktop use (working audio, accelerated graphics, performant networking on the built-in network devices), never mind laptop (power management etc). It's this kind of "polish" driver work that NetBSD is lacking.
calvin | 6 hours ago
Yeah, it's easier to do a port with NetBSD than Linux since it's better structured and simpler, but the 10% of supporting peripherals is much harder than the first 90% of architecture. Assuming it even supports your architecture - NetBSD doesn't support modern Power at all.
classichasclass | 4 hours ago
Which is just bonkers since FreeBSD and OpenBSD (I think) does. When I finally turn my AIX POWER6 into a museum piece and replace it with the POWER9 Raptors, they'll be running FreeBSD, maybe with an AIX VM as a bridge, even though I'd rather run NetBSD since most of my other boxes do.
calvin | 4 hours ago
OpenBSD only supports Raptor's systems from the looks of it.
I've also had bad luck with FreeBSD on IBM systems; none of my POWER8s want to boot it; I suspect some issue with the bootloader.
gamache | 7 hours ago
NetBSD was designed for a world where many CPU architectures were extant, and each one was associated with a relatively small complement of hardware accessories (and therefore drivers). This made a lot of sense in the 1990s and 2000s when minicomputers and workstations still roamed the earth. Now we have two relevant architectures and a neverending stream of hardware devices, and it's a lot harder for a small volunteer project to keep up.
liberty | 7 hours ago
NetBSD supports the CPU is different than it supporting all your hardware like WiFi and such. My understanding is that "it runs on a toaster" is the former and that it has low resource requirements.
regulator | 8 hours ago
Really interested in this, thanks for sharing.
trousers | 4 hours ago
Seems neat, but I think I’ll stick with chimeralinux (FreeBSD userspace, musl, dinit, linux kernel).
jwright | 7 hours ago
we're a long way from "of course it runs NetBSD" I guess
lproven | 3 hours ago
No, not really. As I understand it, what this tends to mean is things like...
"It might bring up your wifi but it might not so you may need a USB dongle"
"If wifi works it won't be modern multi-hundred-Mb standards".
"Your GPU will work but might be unaccelerated."
"You may not get power management, or only basics so no suspend/resume."
It's still got a remarkable range of architectures, but it lags on drivers and standards.
NetBSD does include things like KDE and GNOME these days, but older versions. Alpine is ahead there.