AlpineBSD
wiki.alpinebsd.org
wiki.alpinebsd.org
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 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 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?
plagiarism machine can not be trusted.
therefore plagiarism machine must not be allowed to make decisions.
People are tired of exploding costs, loss of privacy, intrusive technology, pervasive advertising, malignant anti-intellectualism, endless rent-seeking products, and fascist leadership. Adding economic crisis from job loss is a fast track to violence.
I use AI and see it's value and even I'm furious about how it's going.
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
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.
As others said, for closed source software it's a lot harder to detect plagiarism.
And it's in general very hard to detect plagiarized code; there's some product that does it, but it of course has only a partial inventory of the existing open-source code.
I think that some big company does use those products, though.
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”.
- For now the laws are in force, and I don't even know of discussions to change them (that EU proposal only wants to allow training on personal data)
- changing intellectual property rights law would typically require changing international treaties
- however much companies are in love with AI now, I'm not sure they'd support abolishing legal protections on which their business relies
The problem with this is that if someone sues you for this they have to somehow prove that you actually infringed. They can't just point to the code and say "See, mah, infringement!" The legal system does recognize that it is very possible for two people, completely independently, to arrive at a nearly identical solution.
I think in most cases twenty lines of identical code are more than enough for that to be the case (at least if it contains a few non-single-letter identifiers).
I don't know if that's in the 0.000000000001 percent of the time, but it can happen.
I'm not sure that that's how legal departments think.
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.
They are not onboard with the innovation that was GPLv3. That innovation was mostly about software patents iirc. But the result was also that big corps liked GPLv3 even less than GPLv2.
On top of that it was going to be very hard (near impossible) to get all devs to agree to a v2->v3 license bump.
My understanding was this was never a problem, almost all of the kernel was licensed as "GPL2 or newer" until GPL3 was released and they removed the "or newer" from new releases
The "version 2 of the License, or (at your option) any later version"
language in the GPL copying file is not - and has never been - part of the
actual License itself. It's part of the _explanatory_ text that talks
about how to apply the license to your program, and it says that _if_ you
want to accept any later versions of the GPL, you can state so in your
source code.
The Linux kernel has never stated that in general. Some authors have
chosen to use the suggested FSF boilerplate (including the "any later
version" language), but the kernel in general never has.
In other words: the _default_ license strategy is always just the
particular version of the GPL that accompanies a project. If you want to
license a program under _any_ later version of the GPL, you have to state
so explicitly. Linux never did.
I think what Linus is against in the GPLv3 is mostly the anti-tivoisation mechanisms. He wants tivoisation as a feature for the Linux kernel.
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
If you're fit to even be in this conversation then you have enough logic to know this, which makes the comment not merely in error but knowingly disingenuous.
What are the equivalent numbers for everything that was ever licenced GPL vs MIT? Neither of us knows but I defy you to even slightly attempt to hint that the world did not benefit from gpl code about a million times more than mit code as a direct result of their fundamental natures.
My post proved that copyfree code bases actually do receive contributions back from the commercial users of their code. Certainly not 100% of users, but the same is true for the GPL. Every company I've worked for after college has used Linux extensively and none of them have contributed back to Linux in either patches or dollars.
Why do you both keep incorrectly referring to the license as "MIT"? The BSDs are under the various BSD licenses, not the MIT license. If you're trying to refer to the whole category then I would suggest using the words "copyleft" for GPL-style licenses and "copyfree" for BSD-style licenses.
> If you're fit to even be in this conversation then you have enough logic to know this, which makes the comment not merely in error but knowingly disingenuous.
I would like to direct you to the HN guidelines since this is a clear violation of them: https://news.ycombinator.com/newsguidelines.html
Numbers prove or disprove it. Which neither of us has. The fact that everything you showed even fits in a little comment like that compared to the scope of all software actually proves what a joke it was to even try to present this as any sort of argument.
"why do you keep saying MIT?" Oh FFS really? MIT, or BSD, is perfectly understandable shorthand for any of the mit/bsd/x11/etc in a general discussion like this. They are all of a class. How do you know? Because no one has attempted to discuss any fine points here that would make any of those any different from any of the others. You have to go out of your way to say they are different, and then cannot say in what way that matters or changes anything. So why do you yet again pretend an insignificant detail in any way affects the thrust of the argument?
Go ahead and substitute "MIT" with "BSD" or any of the specific "various BSD licences". Ok now that you did that, what changed? The argument was valid or invalid before, and the opposite now?
It does when the original claim was an absolute one. That's how logic works.
Yes it does. The assertion was:
> MIT licensed stuff(if it's any good) just ends up being incorporated into someone else's commercial product, with no contributions.
Therefore, any number of contributions disprove the assertion.
Linus doesn't agree. He once said in an interview that making Linux GPL'd was definitely the best thing I ever did, [0] and has said that I love GPLv2. I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back. [1]
[0] https://web.archive.org/web/20070826212454/http:/www.tlug.jp...
[1] https://www.zdnet.com/article/linus-torvaldss-love-hate-rela...
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.....
I'm a GPL person but that's not why Linux won over the BSDs.
Seriously, if you like the GPL, use arguments that are verifiably true. Otherwise you're just another fanboy spouting talking points.
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.
detecting AI written code without a minder chained to your arm watching your every movement is still a topic of research...
...and as someone who has been to the last 10 miscellaneous FSF/GNU celebrations I can tell you that community has just as many license cheaters and scoundrels as the rest of the computing world, they just tend to bias towards the good stuff, similarly to how every microsoft employee isn't required to drink the blood of infants (it just looks good on quarterlies.)
Code generated by a large language model or similar technology, such as GitHub/Microsoft's Copilot, OpenAI's ChatGPT, or Facebook/Meta's Code Llama, is presumed to be tainted code, and must not be committed without prior written approval by core.
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.
Nowadays it runs SunOS 4.1 with a port of KDE 1 on it, and netboots Sprite for fun.
Of course, after porting the Sprite kernel to said laptop, I learned why the Linux kernel is littered with comments like this, and why it was never quite the beautiful, elegant, UNIX :tm: machine I imagined it was.
/*
* Are you now convinced that the Swift is one of the
* biggest VLSI abortions of all time? Bravo Fujitsu!
* Fujitsu, the !#?!%$'d up processor people. I bet if
* you examined the microcode of the Swift you'd find
* XXX's all over the place.
*/
(of course, the laptop itself is lovely -- the plastic shell has a nice rounded edge for your wrists, and the keyboard uses proper mechanical switches that feel much nicer than actual Sun keyboards of that era)
Send an email to the dev list with a patch. Same as Linux, Git itself, and a lot of other projects.
Getting a person's attention who can and will do something is still challenging if you don't know whom, which is the same problem I saw sending patches to Linux mailing lists which went unanswered, and was given no specific feedback or path forward privately contacting the corporate maintainers.
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.
Because to me, it's entirely fair to care about the process when you're the one working with it, but if you've never looked at the code and it works well, it seems odd to care how 10% of it was produced.
I still wouldn't quite use the loaded "tribalism" term here myself though, because there are still a few valid reasons to be skeptical of LLM-generated code, but for many people, their hard anti-LLM stance appears to be more of a shibboleth than a principled stance from my perspective.
To me, it seems odd not to care.
If you don't mind me asking, why do you think that? I'm not trying to start a debate, and I'm sympathetic to many of the reasons why some people are against LLMs (the environment, copyright issues, loss of jobs, not liking chatbots, not trusting the current companies, etc.), but I'm curious why you are against them.
(I don't really understand one being so against LLMs that one tries to avoid software that contains even small amounts of LLM-written code, but I know that a lot of well-informed people feel this way, and it seems far more likely that I'm the one missing something rather than everyone else being wrong.)
Sure, and that's the motte.
This is a direct quote from the linked website:
> Any software whose code, documentation, binaries, or other assets include, in any part, the output of a generative AI tool such as an LLM, is considered “tainted” for our purposes.
... and that's the bailey.
I think saying "all code that was touched by an LLM is tainted" is not pragmatic.
Not caring about ethics is selfish.
I see this much broader: opting out of certain technologies.
As a vegan I opt out of all animal domestication/husbandry and wild catch/hunt.
And I try to stay away from refined sugar and refined starches.
Abortion is also a technology people feel strongly about.
And now we have the use of AI.
Did we also have people that did not want to use an electronic calculator when it just came out? Probably.
No, but it does significantly increase the likelihood that the software will be good. Stuff people wrote with LLMs is on average much worse than stuff people wrote themselves.
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/.
That means available number of architectures. NetBSD still support some pretty esoteric stuff, but though I haven't actually counted I would expect Linux to run on a comparable number of architectures.
Now, the kernel will probably boot successfully on a given machine, but whether hardware (i.e. driver) support will be decent enough for everyday use is a completely different matter! For example, NetBSD "works" on this laptop of mine... except for Ethernet card, Wi-Fi card, touchpad, ACPI suspension, external monitors via the docking station, ... :)
I'm trying (for fun) to bridge some of these gaps, but you can see how this isn't appealing to the average user.
* https://gnats.netbsd.org/60897
I think that it is specifically the interaction between ihidev and ACPI. The hardware devices themselves are PS/2, with a vendor-specific extension to PS/2 activated by a special handshake, plus I2C. (On machines from 2024 that come with 9 USB root hubs; such is the inertia of laptop design.)
* 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?
Honestly, no.
I just reviewed version 11. It's a pain to install, a pain to configure, a pain to add a proper desktop, etc. If you do manage to install a desktop environment, the ones in the NetBSD repos are mostly long out of date.
https://www.theregister.com/os-platforms/2026/08/20/netbsd-1...
The community is great. The mailing list tried very hard to help me to install and run CDE.
After 3 days of trying, I gave up. For reference, this was my 2nd or 3rd try.
No, the NetBSD userland is not good, and the docs are not great either. There are an absolute tonne of implicit assumptions of knowledge that newcomers won't have.
An example:
https://www.netbsd.org/docs/guide/en/chap-upgrading.html
The recommended way is "boot from install medium, install over the top". Note that the handbook does not actually say this, and goes on to detail an alternative method called "sysupgrade" which looks much like the OpenBSD method and resembles conventional Linux system upgrade methods.
So I tried that. It irretrievably destroyed my only bare metal install.
To forestall an inevitable comment: it's a testbed, so no, I did not have any backups. It contains -- well, contained -- no data at all.
Reading that chapter, it turns out that it does. Maybe it should stress the point more, but the actual doco is the likes of these:
* https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/evbarm-aarch64...
* https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/i386/INSTALL.h...
* https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/amd64/INSTALL....
* https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/amiga/INSTALL....
* https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/sparc64/INSTAL...
… and so forth. Plus the manual pages for postinstall(8) and the like.
To start a community.
$ docker run -it --rm alpine
/ # apk add cmd:ldd
/ # ldd $(which ash)
/lib/ld-musl-x86_64.so.1 (0x7f4cb4d1d000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f4cb4d1d000)
/ # apk add cmd:python3
/ # ldd $(which python3)
/lib/ld-musl-x86_64.so.1 (0x7fd630cab000)
libpython3.12.so.1.0 => /usr/lib/libpython3.12.so.1.0 (0x7fd63069a000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fd630cab000)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).
...or people who had a test/deploy/debug cycle on environments that necessarily had no layer cache (ephemeral VMs, one-shot kubernetes clusters, OpenWRT routers that lost the layer cache on reboot). Or people with network-constrained traffic from registries or mirrors thereof.
Or people in environments that took container security findings (perhaps too) seriously and were tired of triaging endless reports for random dependencies in "FROM ubuntu" containers, and wanted a default required-by-policy base image that didn't come with the world.
Or people who needed a relatively full-featured build environment against musl without having to do bizarre incantations in e.g. a Fedora image to switch away from libc while still being able to link against other system libraries.
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.
This is an argument, anyhow, but it's very far from being the only (pragmatic) one.
I don't use them for open source projects I maintain.
Oh, how the mighty have fallen. Still remember the times when the meme was that the NetBSD was running on absolutely anything.
This suggests the commenter once thought that NetBSD was mighty
Perhaps he never had such thoughts
If so, then this comment is disingenuous
There is an obvious difference between "hardware (feature) support" and "runs NetBSD"
For example I don't need X11, ACPI, audio or WiFi to "run NetSBD". I want a server not a "desktop"
AI can fix a lot of issues that lingered due to lack of time & patience for proper testing and experimentation.
For example, I had VM instances crashing because of a commercial vendor's agents (telemetry, auth etc). AI identified why the crash occurred, and rewrote the buggy vendor agent with a lighter and more resilient agent.
I brought the issue up with the vendor, and they were stuck with their approach for legacy reasons. Fine! we can both operate happily now. I don't have to use their software.
>binutils gcc gdb libffi perl xorriso
Good luck replacing those ...
They'll be left behind, but it clearly doesn't matter to them.
Fucking get over yourself.
They are really very insecure people, professionally and socially.
EDIT: It took one second for an AI patrol to downvote this one.
user: 1ajsht
created: 2 minutes ago
karma: 0You 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.
There's no good endpoint for people if AI succeeds, it's that simple. It doesn't matter how many people get to roast marshmallows as the place burns.
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.
Why stop at just one?