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.
I think it's a good thing. In a couple of years we'll have a clear way to measure the true productivity and impact (or lack thereof) of AI on software dev. It's the perfect "natural experiment".
No. If an open source project allows small amounts of LLM slop to please their foundation donors, is all productivity in that project due to LLMs? Of course not.
If 10 of 20 developers work for corporations and have to pretend that their code is AI written to please the corporations, is that AI productivity?
The advertising and social pressure machinery is so AI heavy right now because most techies are cowards and only speak up on issues (including DEI as we see since Trump) if HR tells them to.
Then of course many projects like Linux or git are entrenched. You can't copy Unix and bitkeeper like Linus did and be immediately successful, because the whole culture is against you (unlike in the 1990s, when the culture was anti-Microsoft).
So yeah, if Gen-Alpha declares OpenAI and Anthropic the new Microsoft and builds up a new counter-culture, then in 10 years you might have some clue.
Otherwise, we have to stick to the current situation and observe that no software has gotten better since AI.
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 think what you're finding is that people who don't care about low quality of LLM outputs also don't care about licensing. If you're in the faction that supports all of this, you don't see a lot of people around you still caring about licensing or quality.
I am in neither faction, as I already indicated. I’m not an LLM user except for search engine summaries.
I also already mentioned that some formerly GPL die-hards have been jumping ship from Linux to BSDs simply because of the respective stances on AI. That’s enough for me to say this works both ways.
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?
Because the chance of someone auditing the actual source code is near zero, but for open source software it's near 100% that someone or, worse something aka an AI bot looking for a revenue stream, will have a look at your code. And EVEN IF you get caught stealing by whatever random incident (say, your code repository being 0wned) - it's a matter of a settlement payment. If you are not a company, but an individual person... well, just look at what happened to Aaron Swartz RIP.
And for the WINE/ReactOS/console homebrew folks, it's vital to be able to claim no code contributor ever got exposed, even indirectly, to proprietary code.
On the other hand it could be very expensive if caught. It could be very difficult to remove the code too.
Your point about being caught is valid, but it depends on AIs producing identifiable chunks of code, and that is incompatible with your license. AI training is going to lean towards open source, because its available to train on.
I also think the widespread use of AI will mean accidental copying will become more acceptable. Even as it is, its going to be regarded as an accident.
> 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!)
> The reason that Linux actually succeeded where BSD didn't is because of the GPL.
Linux succeeded where BSD was tied-up in a lawsuit[0] from AT&T and the fear of “picking the wrong horse” w BSD under threat allowed Linux to slide into public consciousness and installs.
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.
Except in this case the monkeys are pretty good at coding as long as you have enough bananas (tokens). They can follow directions pretty accurately and work independently for at least short periods and incrementally test the work even if you’re not present onsite monkey-handling all the time. I don’t understand this hard anti-ai stance from open-source groups except as a submission volume issue. If and when nearly the entire professional industry changes to LLM-based code in most cases, what are they going to do to find those relatively few people who are still willing to write everything manually and spend their spare time maintaining these projects?
Perhaps one day we’ll finally understand the value of simpler software that moves ever-closer to “complete” (simple maintenance only), rather than constantly reinventing Zawinsky’s Law.
It’s ok for software to be replaced when something better comes along for a new generation, but what I wouldn’t give for more well-maintained tools that are feature complete.
What is the modern version of Zawinsky’s Law, anyway? Every program expands until it contains a web browser (Electron), notifications, and a chatbot?
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.
The BSDs do have comparatively miserable contributor experiences, though I understand why. At least from my very, very limited exposure.
Several years ago now, I ran into a problem with playing audio on NetBSD/sparc. I had an RDI PowerLite laptop, which is 80% of a SPARCstation 5 clone stuffed into a laptop chassis. Part of the 20% different was the audio chip, which was the same AMD ISDN chip used in the SPARCstation 1/2, doing mu-law audio.
Whenever I'd play audio, the laptop would instantly reset. Huh. That's weird. I ended up figuring out that someone had recently massively overhauled the audio driver subsystem in the kernel, and basically the relevant audio driver was missing some mutex operation, and an assert() was panic'ing the kernel.
For a non SMP system, the lock wasn't necessary (IIRC) but the new code was being more rigorous and causing a kernel panic.
The patch was pretty easy, just adding a few locks/unlocks. But I could never figure out what I was supposed to do with the patch after.
I'm probably just stupid. I don't want to imply there's no path to do this, I just never figured it out. I didn't try for long either, since getting 8-bit mu law audio working was just something goofy I was doing for fun.
But for comparison, when I found a bug in the signal handler for 32-bit PowerPC, my memory was that it was pretty straightforward to produce a patch: find the relevant maintainer, open a dialogue, and eventually submit a patch: https://marc.info/?l=linuxppc-embedded&m=160963760120837
Neither fix was ultimately very important, and neither would have impacted more than a couple dozen people on the entire planet. But Linux got a patch, while NetBSD didn't...
Just out of curiosity, why the Sparc laptop? While I'd love to find one today to tinker with, I assume anyone who had one back then was mainly working on sun machine's / unix and needed some at home familiarity.
> Wrapping that all up in an opinionated installation (like Omarchy recently did to Arch) would be a more survivable effort.
Well we currently have fallout in FreeBSD land because of Jordan Hubbard slopping together Daemonarchy.
Going about as well as you expect when you even loosely tie yourself to a crazy white nationalist like DHH. Even in what is barely a reference to his slop dotfiles masquerading as a distro.
> 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.
sometimes, it feels like AI people are incapable of understanding that the concerns we have with this can encompass more than purely productivity and convenience :/
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.
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.
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.
> 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.
> which was selling people only for people that either don't understand docker layers or can't make Dockerfile correctly.
I don't think that's fair. Alpine-derived images are generally smaller, all things held equal. Of course if you do everything else right then it will matter less, but a proper multistage Dockerfile should still be smaller than the same thing built out of another distro (most of the time).
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 bad edge cases that become commonly exploitable.
I never got the chance to try it, but yeah. I've looked at the Gentoo/FreeBSD and Gentoo/OpenBSD pages a few times just yearning to try them. Portage and all other Gentoo tools being a fairly kernel agnostic toolkit is just the coolest. Even though OpenBSD and NetBSD are in my favorites with Gentoo and Void Linux, I don't think I could ever primarily use anything else unless it had Portage. This rising BSD popularity is welcome news for anyone leaning more UNIX among Linux users.
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.
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/
>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.
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.
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'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'm of the opinion that improved developer productivity has been a net negative for at least a decade. Regardless of my opinion of LLMs, I don't want it any easier for people to add more antifeatures and pointless changes.
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 now feel like the efforts put into trying to stop it are wasted and the people wasting these efforts are smart enough that they could instead be trying to steer the whole thing in a better direction.
Ignorance won't help us. I agree with the negatives, I just feel like this approach is backwards.
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.
If 10 of 20 developers work for corporations and have to pretend that their code is AI written to please the corporations, is that AI productivity?
The advertising and social pressure machinery is so AI heavy right now because most techies are cowards and only speak up on issues (including DEI as we see since Trump) if HR tells them to.
Then of course many projects like Linux or git are entrenched. You can't copy Unix and bitkeeper like Linus did and be immediately successful, because the whole culture is against you (unlike in the 1990s, when the culture was anti-Microsoft).
So yeah, if Gen-Alpha declares OpenAI and Anthropic the new Microsoft and builds up a new counter-culture, then in 10 years you might have some clue.
Otherwise, we have to stick to the current situation and observe that no software has gotten better since AI.
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.)
I also already mentioned that some formerly GPL die-hards have been jumping ship from Linux to BSDs simply because of the respective stances on AI. That’s enough for me to say this works both ways.
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?
Because the chance of someone auditing the actual source code is near zero, but for open source software it's near 100% that someone or, worse something aka an AI bot looking for a revenue stream, will have a look at your code. And EVEN IF you get caught stealing by whatever random incident (say, your code repository being 0wned) - it's a matter of a settlement payment. If you are not a company, but an individual person... well, just look at what happened to Aaron Swartz RIP.
And for the WINE/ReactOS/console homebrew folks, it's vital to be able to claim no code contributor ever got exposed, even indirectly, to proprietary code.
Your point about being caught is valid, but it depends on AIs producing identifiable chunks of code, and that is incompatible with your license. AI training is going to lean towards open source, because its available to train on.
I also think the widespread use of AI will mean accidental copying will become more acceptable. Even as it is, its going to be regarded as an accident.
Proprietary developers don't care because their code wasn't trained on. Is that a trick question?
They do care now that reverse engineering is possible.
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!)Linux succeeded where BSD was tied-up in a lawsuit[0] from AT&T and the fear of “picking the wrong horse” w BSD under threat allowed Linux to slide into public consciousness and installs.
[0] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
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.
plagiarism machine can not be trusted.
therefore plagiarism machine must not be allowed to make decisions.
It’s ok for software to be replaced when something better comes along for a new generation, but what I wouldn’t give for more well-maintained tools that are feature complete.
What is the modern version of Zawinsky’s Law, anyway? Every program expands until it contains a web browser (Electron), notifications, and a chatbot?
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.
Several years ago now, I ran into a problem with playing audio on NetBSD/sparc. I had an RDI PowerLite laptop, which is 80% of a SPARCstation 5 clone stuffed into a laptop chassis. Part of the 20% different was the audio chip, which was the same AMD ISDN chip used in the SPARCstation 1/2, doing mu-law audio.
Whenever I'd play audio, the laptop would instantly reset. Huh. That's weird. I ended up figuring out that someone had recently massively overhauled the audio driver subsystem in the kernel, and basically the relevant audio driver was missing some mutex operation, and an assert() was panic'ing the kernel.
For a non SMP system, the lock wasn't necessary (IIRC) but the new code was being more rigorous and causing a kernel panic.
The patch was pretty easy, just adding a few locks/unlocks. But I could never figure out what I was supposed to do with the patch after.
I'm probably just stupid. I don't want to imply there's no path to do this, I just never figured it out. I didn't try for long either, since getting 8-bit mu law audio working was just something goofy I was doing for fun.
But for comparison, when I found a bug in the signal handler for 32-bit PowerPC, my memory was that it was pretty straightforward to produce a patch: find the relevant maintainer, open a dialogue, and eventually submit a patch: https://marc.info/?l=linuxppc-embedded&m=160963760120837
Neither fix was ultimately very important, and neither would have impacted more than a couple dozen people on the entire planet. But Linux got a patch, while NetBSD didn't...
Just out of curiosity, why the Sparc laptop? While I'd love to find one today to tinker with, I assume anyone who had one back then was mainly working on sun machine's / unix and needed some at home familiarity.
Well we currently have fallout in FreeBSD land because of Jordan Hubbard slopping together Daemonarchy.
Going about as well as you expect when you even loosely tie yourself to a crazy white nationalist like DHH. Even in what is barely a reference to his slop dotfiles masquerading as a distro.
> 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.
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.
* 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.
I don't think that's fair. Alpine-derived images are generally smaller, all things held equal. Of course if you do everything else right then it will matter less, but a proper multistage Dockerfile should still be smaller than the same thing built out of another distro (most of the time).
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 bad edge cases that become commonly exploitable.
https://github.com/nix-community/nixbsd
Oh, how the mighty have fallen. Still remember the times when the meme was that the NetBSD was running on absolutely anything.
>binutils gcc gdb libffi perl xorriso
Good luck replacing those ...
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.
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.
Ignorance won't help us. I agree with the negatives, I just feel like this approach is backwards.