Interesting to watch the rapid fragmentation of FOSS into “hard” anti-AI, AI-neutral-to-discouraged, AI-supplemented, and AI-driven camps, akin to the early GPL vs BSD wars. Suddenly I don’t see as many complaints about licensing, and some of the die-hard GPL stans are silently dropping that position as Linux adopts AI-supplemented development.
On one hand it’s unfortunate, because it hypothetically dilutes developer efforts, but on the other hand the most extreme groups already had incompatible personalities and weren’t working well together. This self-sorting may actually result in a better cadence and less energy wasted on arguing.
The downside is that a lot of loud and annoying people seem to be converging on BSD land. I am AI-nonaligned (I just care about Quality) but I’m very much in favor of OpenBSD’s heads-down focused dev culture. I hope that doesn’t change.
It’s possible that they have different interpretations of how generated code affects licensing, but I think in general everyone is now abandoning old positions on licensing. It’s an exciting time for those of us who dislike copyright, something is bound to shift soon.
Whatever its stance towards the GPL, Linux has become the default home of GPL land with the exception of the few dedicated souls still working on Hurd. (I hope they keep making steady progress.)
I expect the overall copyright regime to be weakened over time due to the effects of AI. It’s clear that the intent is to replace copyright gatekeeping with model/compute gatekeeping. This is a battle between two groups I greatly dislike, and I don’t really side with either, but there may be a small benefit for the average person who just wants to “download a car”.
> Linux, for one, for what I can tell never cared too much about the GPL.
The reason that Linux actually succeeded where BSD didn't is because of the GPL. MIT licensed stuff(if it's any good) just ends up being incorporated into someone else's commercial product, with no contributions.
That's just obviously not true. Check out the commit history on FreeBSD and look at all the contributions from Netflix. Off the top of my head they contributed kTLS and asynchronous sendfile which made it such that a single syscall could send the full contents of a file over a socket even with TLS.
Grepping through the git logs for the "Sponsored by" lines shows these top results:
15925 The FreeBSD Foundation
3738 Netflix
2084 EMC / Isilon Storage Division
1922 Rubicon Communications, LLC ("Netgate")
1733 Dell EMC Isilon
1550 Chelsio Communications
1446 DARPA, AFRL
1421 Mellanox Technologies
1262 Klara, Inc.
784 Arm Ltd
729 iXsystems, Inc.
707 Solarflare Communications, Inc.
552 Netflix, Inc.
477 Beckhoff Automation GmbH & Co. KG
473 Microsoft
421 Juniper Networks, Inc.
411 DARPA, NAI Labs
386 Stormshield
385 Microsoft OSTC
384 DARPA
375 NetApp, Inc.
358 Innovate UK
355 DARPA, Network Associates Laboratories
317 Yandex LLC
299 NVIDIA Networking
One company that isn't in that list but shows up as an author is Datto which gave us native encryption on ZFS (shout out to Tom for writing that!)
Linux success has nothing to do with GPL and everything to do with a lawsuit and timing. Linus himself said if it wasn't for the lawsuit Linux probably would not exist.
It's more akin to copy-pasting from stack-overflow versus people writing code, or code written by engineers vs code written by outsourced "code monkey" farms/contractors/consultants?
It's not about freedom, which is what GPL vs BSD is fundamentally about.
These types of projects tend to have a flash of appeal, especially to people used to Linux, because it lessens one degree of unfamiliarity, but they don't seem to stick around for to me obvious reasons.
It's hard to get involved with something like a BSD project because you have to learn a lot and put in enough effort to get committer rights. And then if you want to move the needle you have to do even more work and build consensus without getting overly emotional when people disagree with you. But it is the path I would recommend to have a lasting impact, and I am speaking from experience as a FreeBSD and NetBSD src committer.
Also, pkgsrc is one of the strong points of NetBSD, coupled with pbulk and pkgin. Wrapping that all up in an opinionated installation (like Omarchy recently did to Arch) would be a more survivable effort. But as my friend Larry McVoy would say, it means you don't always get to drive the big red fire truck by yourself.
Look, I'm not an AI supporter, but you can't put your head in the sand about things it does well. Even if you don't use it to produce production code, using it for research, prototyping, etc is still incredibly useful.
> AlpineBSD is not a fork of Alpine Linux, its package collection is original (though many packages are ultimately based on aports).
> Alpine Linux uses the OpenRC init system. Currently, AlpineBSD uses s6 and we intend to add OpenRC as an alternative.
I'm not sure where exactly the line should be, but that feels like it's not an Alpine* then. Like, if you're starting your package collection separately and use a different service manager, you're further from Alpine Linux than Adélie Linux is.
(To be clear, I'm a big fan of making a new OS from a *BSD core and a new userspace. I'm just quibbling about naming semantics)
I don't like it when unrelated projects squat on the name of some existing project. Trademark isn't just a commercially useful thing, it helps users understand what they're getting and who they're getting it from.
It's shitty for a new project to ride on the coattails of a trusted project with years of reputation. It misleads and confuses folks.
Take inspiration anywhere you like, borrow the code all you like, but don't steal the damned name.
Regardless of how you feel about using LLMs or using products that are developed with LLMs, it is a good idea to have an ecosystem of open source projects with differing levels of LLM involvement, including pristine software written entirely by humans.
The pragmatic argument for hard no-LLM projects: if models are to be useful, they need good input. Hand-written software that has been carefully audited is free from the kinds of feedback errors that will eventually weaken LLM code generation. Otherwise, a bad pattern gets copied. In the next generation, this bad pattern is seen a bit more often as stochastic models converge on it and more open source code adopts it. This is reinforced in the next generation and it becomes a common pattern. Then, in the next generation, this pattern is seen all over. This could be inert "non-coding" DNA like weird naming conventions or pointless comments. Or, it could be just bad edge cases that become commonly exploitable.
I can respect this. Looks like AI auditing code is fine and I can't imagine why auditing would ever be a con. As for the lack of reasons given I guess they leave that for the users which seems completely fine to me. If you are chimping out over not getting a justification then you should probably do some soul-searching.
After reading the web page, I am left with some questions unanswered,
* Is it a goal for AlpineBSD to run on native hardware, or is it intended for containers (a major use-case for Alpine itself)?
* For users who want to avoid AI-generated code, why run this rather than netbsd itself?
If the team want to attract interest, they should give more context.
The mission is unclear. The team could address this by stating goals and milestones on the front page.
There is a link to a tool s6 on the page. The description of that tool opens with a circular definition. It would be clearer if it stated why it exists in the opening paragraph. Near the bottom it talks about "One of the design goals of s6-frontend". It would be better to state all of the design goals.
> NOTICE: The NetBSD kernel has spotty hardware support, much less so than Linux. You cannot necessarily expect AlpineBSD to work on any random computer you have lying around.
Huh. I feel like the author has their BSDs mixed up! NetBSD's main claim to fame is that it runs on practically everything, even lots of platforms no longer supported by mainstream Linux distributions. The page links to the laptop wiki, which is about AMD64 laptops and their finicky peripherals and driver support. A better place to start for hardware support is https://wiki.netbsd.org/ports/.
The impression I get is that NetBSD has just enough code to get it up and running on a machine but there is not enough development and testing to get it to run well on a machine.
That was true 20 years ago, but not really today. Today's hardware is much more complicated and I wouldn't expect NetBSD to work well on anything but the most basic hardware.
Neat project. One thing I don't see covered: is everything going to be statically linked like it is on Alpine Linux? Is statically linking libc advisable on a NetBSD kernel? I know (unlike Linux) the FreeBSD kernel ABI can change every major release, but I'm not familiar with NetBSD's approach.
Alpine Linux is not statically linked. It provides a musl environment which makes it easy to statically link your own builds, but software shipped as part of the distro is usually dynamically linked.
Woah, TIL! My Alpine Linux world view has just been shattered. Static linking was frankly *the* selling point of Alpine Linux for me and it turns out I was just plain wrong.
Alpine selling point was that it's small, which was selling people only for people that either don't understand docker layers or can't make Dockerfile correctly.
Alpine’s connection to static linking is mainly that it provides a convenient musl build environment. A fully static binary can run in `FROM scratch`.
> A fully static binary can run in `FROM scratch`.
Not just `FROM scratch` but also in other contexts. For example:
I wrote my own password manager which lives on a USB drive. Since I compiled a static binary, I can execute it on any Linux machine.
Running static binaries in FreeBSD's Linuxulator is easier. The Linuxulator is a separate set of syscalls that get used when you attempt to run a Linux binary, so a static binary will "just work" for the most part (unless the program needs special filesystems like /proc or /sys). A dynamically linked binary means I need to make sure I have any necessary Linux libraries in the proper location and the Linuxulator's `ld` working properly. Updates to these libraries can then make something that used to work, suddenly stop working. Certainly not an insurmountable task, but there's so many fewer places where things can break when you're just running a static binary.
Well, `FROM scratch` implies that if there is something that works with linux syscalls (i.e. Linuxulator) then it generally runs. Unless, like you said, it needs special filesystems.
I don't think NetBSD has ever had a reputation for what they mean by "spotty hardware support" here, which is apparently uh... power management on laptops. Their links take you here: https://wiki.netbsd.org/laptops/
One thing I'm cautiously watching is NixBSD. With nix you can trivially compile all your software from source and modify it (both of which I do on the Linux-based NixOS). So I think that would cover the main selling point of Gentoo, though naturally it adds the Nix layer that you may either love or hate. The only reason I haven't dived into it yet is my FreeBSD machines are all foundational parts of my infrastructure so I don't want to take a gamble on such a young project. So for now I just load it up into a virtual machine and poke at it longingly from time to time.
Ok so it's "AI free". But why? It doesn't justify the decision but just assumes you will understand the reasoning. I have to say: I don't. For example they are pinning binutils, gcc, and gdb to the last version they know does not have LLM generated code. I assume this means they will not be able to accept any upstream patches, but instead have to take over maintenance of those packages themselves for the forseeable future, effectively meaning development on those will stop for the purposes of AlpineBSD. Seems stupid, to me.
>A small amount of essential software is pinned to the last version which is not tainted. We pin software as a last resort, preferring to find alternatives or move the package into the tainted repository. The current list of pinned software in “base” and “main” is:
while sitting on a cab a few weeks ago, i was watching other large trucks passing through, and i was wondering about what it would be like if these trucks were entirely made by bots, would travelling on roads feel less safer?
when you know that the existing old stuff is made by humans and most humans who are good at their work genuinely put in effort and care in their craft, can we say the same about work generated by clankers?
Really got me wondering, still split on if all this AI hype will be a net good in the long run.
Sure you're more productive and end up spitting out more code, as long as its non critical SaaS stuff, who cares if things go wrong right?
for crucial, mission critical stuff, relying only on AI autonomously, especially when they are still prone to make errors, seems like a very dystopian reality.
Just today claude code hallucinated the first name of a person because in the username the first name was one letter.
You complain an the shit future we're building. Someone says fuck you to your dystopia and starts explicitly weeding it out, and you call it backwards.
As far as I can tell, either LLMs naturally fail to be viable, we collectively decide to put a stop to it, or we end up in one of several dystopias.
My bet is that we end up building an awful outcome for nearly humans, which means that trying to put a stop to it is a duty, even if it's likely to fail. I feel the same about climate change -- it's likely that we're going to fail to keep much of earth habitable, but it's not morally acceptable to stop trying.
I'm a hardcore LLM booster but I agree that there's a place for LLM-free projects. In fact human generated code is still superior to even frontier LLM generated code, as long as you're willing take a massive productivity penalty.
I don't think they do. They just care about owning shiny things.
If you care about software (or math, or art, or literature, or any other aspect of human creativity), AI is at best like hiring someone to solve jigsaw puzzles for you.
On one hand it’s unfortunate, because it hypothetically dilutes developer efforts, but on the other hand the most extreme groups already had incompatible personalities and weren’t working well together. This self-sorting may actually result in a better cadence and less energy wasted on arguing.
The downside is that a lot of loud and annoying people seem to be converging on BSD land. I am AI-nonaligned (I just care about Quality) but I’m very much in favor of OpenBSD’s heads-down focused dev culture. I hope that doesn’t change.
Linux, for one, for what I can tell never cared too much about the GPL.
Whatever its stance towards the GPL, Linux has become the default home of GPL land with the exception of the few dedicated souls still working on Hurd. (I hope they keep making steady progress.)
Or to be forced to change license to large portions of your project?
With Linux I meant the Linux kernel
I expect the overall copyright regime to be weakened over time due to the effects of AI. It’s clear that the intent is to replace copyright gatekeeping with model/compute gatekeeping. This is a battle between two groups I greatly dislike, and I don’t really side with either, but there may be a small benefit for the average person who just wants to “download a car”.
Why are proprietary software developers entirely unbothered by this?
The reason that Linux actually succeeded where BSD didn't is because of the GPL. MIT licensed stuff(if it's any good) just ends up being incorporated into someone else's commercial product, with no contributions.
That's just obviously not true. Check out the commit history on FreeBSD and look at all the contributions from Netflix. Off the top of my head they contributed kTLS and asynchronous sendfile which made it such that a single syscall could send the full contents of a file over a socket even with TLS.
Grepping through the git logs for the "Sponsored by" lines shows these top results:
One company that isn't in that list but shows up as an author is Datto which gave us native encryption on ZFS (shout out to Tom for writing that!)It's more akin to copy-pasting from stack-overflow versus people writing code, or code written by engineers vs code written by outsourced "code monkey" farms/contractors/consultants?
It's not about freedom, which is what GPL vs BSD is fundamentally about.
It's hard to get involved with something like a BSD project because you have to learn a lot and put in enough effort to get committer rights. And then if you want to move the needle you have to do even more work and build consensus without getting overly emotional when people disagree with you. But it is the path I would recommend to have a lasting impact, and I am speaking from experience as a FreeBSD and NetBSD src committer.
Also, pkgsrc is one of the strong points of NetBSD, coupled with pbulk and pkgin. Wrapping that all up in an opinionated installation (like Omarchy recently did to Arch) would be a more survivable effort. But as my friend Larry McVoy would say, it means you don't always get to drive the big red fire truck by yourself.
I want software that is brilliant and well audited, no matter who or what produced it.
No AI guarantees nothing, especially if it's a C codebase like netbsd, why not also join the rust tribe then?
It becomes tribalism when there is an enemy. Us and them, mac vs pc, AI vs Humans, the left vs the right.
Can the AI people even devise an original argument by themselves or do they always just plagiarize and flip them?
Can AI people even think any longer? You can peck on the downvote button like a hen, that's it.
> Alpine Linux uses the OpenRC init system. Currently, AlpineBSD uses s6 and we intend to add OpenRC as an alternative.
I'm not sure where exactly the line should be, but that feels like it's not an Alpine* then. Like, if you're starting your package collection separately and use a different service manager, you're further from Alpine Linux than Adélie Linux is.
(To be clear, I'm a big fan of making a new OS from a *BSD core and a new userspace. I'm just quibbling about naming semantics)
It's shitty for a new project to ride on the coattails of a trusted project with years of reputation. It misleads and confuses folks.
Take inspiration anywhere you like, borrow the code all you like, but don't steal the damned name.
The pragmatic argument for hard no-LLM projects: if models are to be useful, they need good input. Hand-written software that has been carefully audited is free from the kinds of feedback errors that will eventually weaken LLM code generation. Otherwise, a bad pattern gets copied. In the next generation, this bad pattern is seen a bit more often as stochastic models converge on it and more open source code adopts it. This is reinforced in the next generation and it becomes a common pattern. Then, in the next generation, this pattern is seen all over. This could be inert "non-coding" DNA like weird naming conventions or pointless comments. Or, it could be just bad edge cases that become commonly exploitable.
* Is it a goal for AlpineBSD to run on native hardware, or is it intended for containers (a major use-case for Alpine itself)?
* For users who want to avoid AI-generated code, why run this rather than netbsd itself?
If the team want to attract interest, they should give more context.
The mission is unclear. The team could address this by stating goals and milestones on the front page.
There is a link to a tool s6 on the page. The description of that tool opens with a circular definition. It would be clearer if it stated why it exists in the opening paragraph. Near the bottom it talks about "One of the design goals of s6-frontend". It would be better to state all of the design goals.
> For users who want to avoid AI-generated code, why run this rather than netbsd itself?
Alpine userland is nice.
NetBSD userland is not?
To start a community.
Huh. I feel like the author has their BSDs mixed up! NetBSD's main claim to fame is that it runs on practically everything, even lots of platforms no longer supported by mainstream Linux distributions. The page links to the laptop wiki, which is about AMD64 laptops and their finicky peripherals and driver support. A better place to start for hardware support is https://wiki.netbsd.org/ports/.
Alpine’s connection to static linking is mainly that it provides a convenient musl build environment. A fully static binary can run in `FROM scratch`.
Not just `FROM scratch` but also in other contexts. For example:
I wrote my own password manager which lives on a USB drive. Since I compiled a static binary, I can execute it on any Linux machine.
Running static binaries in FreeBSD's Linuxulator is easier. The Linuxulator is a separate set of syscalls that get used when you attempt to run a Linux binary, so a static binary will "just work" for the most part (unless the program needs special filesystems like /proc or /sys). A dynamically linked binary means I need to make sure I have any necessary Linux libraries in the proper location and the Linuxulator's `ld` working properly. Updates to these libraries can then make something that used to work, suddenly stop working. Certainly not an insurmountable task, but there's so many fewer places where things can break when you're just running a static binary.
Oh, how the mighty have fallen. Still remember the times when the meme was that the NetBSD was running on absolutely anything.
https://github.com/nix-community/nixbsd
>binutils gcc gdb libffi perl xorriso
Good luck replacing those ...
You complain an the shit future we're building. Someone says fuck you to your dystopia and starts explicitly weeding it out, and you call it backwards.
I just feel like eliminating LLM output is (1) not feasible (2) not the right solution to the problem.
My bet is that we end up building an awful outcome for nearly humans, which means that trying to put a stop to it is a duty, even if it's likely to fail. I feel the same about climate change -- it's likely that we're going to fail to keep much of earth habitable, but it's not morally acceptable to stop trying.
Why do vihecoders still care of other people's software?
If you care about software (or math, or art, or literature, or any other aspect of human creativity), AI is at best like hiring someone to solve jigsaw puzzles for you.