AlpineBSD
77 points by FedericoSchonborn
77 points by FedericoSchonborn
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!
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.
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
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 mentioning the LLM tool they used 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).
For the audience at home: Theo was explicit on his stance with LLM written code.
At present, the software community and the legal community are unwilling to accept that the product of a (commercial, hah) AI system produces is Copyrightable by the person who merely directed the AI.
Having a definition of "legal community" and "programming community" would make this easier to read because right now it seems at odds with reality.
If there was a case of licensing risk, why would the industry at large lean so heavily on LLMs? Sounds like a huge risk. Why would Linus admit openly using claude code for this or that? Are they all wrong and naive? It's hard to imagine that's the case.
FWIW, I think openBSD is probably the OS I'm least concerned with slop. I trust you guys even more than Linux to hold the line when it comes to quality.
Xenocara sadly pulled some LLM authored code from upstream: https://github.com/openbsd/xenocara/blob/master/xserver/ChangeLog
Edit: seems like most are patches for vulnerabilities, but I seem to remember there were some font related things that could be considered a new feature?
The answer is buried behind the lede a bit (in that you'll only find it by looking at who's the user behind the source code), but it's a project from Drew.
Drew uses Alpine as his daily driver and for all his servers, and has also been vocally critical of Linus accepting LLM contributions into the kernel.
This probably is his way of resolving that criticism; moving over to BSD as it categorically hasn't accepted LLM code in its kernel, while still getting to keep the specific userland he prefers. At a glance, it's a neat idea although I'm also curious to see how it'll confront reality if he opts to move Sourcehut to AlpineBSD as well. (This isn't sarcasm, I'm genuinely curious; Linux distros and BSD have very different philosophies on how a system is assembled, and the nature of Linux has always lend itself to being more "choose the parts you want", with distros acting mostly as curators, compared to BSD shipping much more "complete" elements in terms of userland.)
The NetBSD kernel has spotty hardware support
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.
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.
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.
Small hopefully interesting side note. This was also why NetBSD was always leading edge in the early days of Xen virtualization before CPUs provided functionality.
While Linux eventually caught up and then quickly became the most popular choice with KVM I don't think the timeline would have been the same without NetBSD.
The only later thing I know where the design probably helped us the rump kernel.
The BSDs somehow always end up being the case study to pick up for Linux. I mean in a way the OS and open source community was too. But that's a different topic.
Just wanted to point out that side effects don't just just hold benefits for physical but also virtual hardware.
Seems neat, but I think I’ll stick with chimeralinux (FreeBSD userspace, musl, dinit, linux kernel).
I'm surprised nobody has mentioned it here, but there is already another Linux distrobution attempting to rebase onto a BSD kernel. Hyperbola Linux has a roadmap for HyperbolaBSD available. Progress is slow. Exciting nonetheless.
The idea of running a slop-free operating system wasn’t on my agenda, but sounds like a fun hobby project to run on a laptop that isn’t my daily driver. (I use Linux.)
I think my top candidates right now are OpenBSD and 9 Front. Both adhere to the Suckless philosophy in my unofficial opinion.
NOTICE: The NetBSD kernel has spotty hardware support, much less so than Linux.
we're a long way from "of course it runs NetBSD" I guess
we're a long way from "of course it runs NetBSD" I guess
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.