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.)
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?
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.
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.
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.
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
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?
> 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?
>Look I'm not an anti-AI supporter, but you can't put your head in the sand about the environmental and social destruction it causes. Even if you use it to do good it's still incredibly harmful.
We aren't putting our heads in the sand, we're objecting to increasingly frantic pushes on a global scale to force this shit on us all. We're doing harm reduction on every front we can from personal lives to software.
* 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.
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/.
$ 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).
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.
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?
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.
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.
Or, maybe, it was even more UNIX-y than I had thought. :-)(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)
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.