Mario,
I was going to counter various points you made but this topic has already been
derailed and I'd rather not contribute to that. The point is this: NetBSD has a
no AI-code policy I don't personally know if that extends to the packages
in pkgsrc, but either way, that is a discussion for another thread. If you feel
so strongly about NetBSD accepting AI code then please make your case to the
developers and maintainers but do so in a dedicated thread instead of changing
the topic of this one.
Back to the topic at hand now, I'm willing to look at the QEMU code and fork it
at the last known human-only code point as something along the lines of
qemu-classic, and submit a package to pkgsrc if that's something others are
interested in. I do not have the time or really inclination to develop new
features for it but I'm happy to keep an eye on CVEs or other maintenance tasks
as required.
Cheers,
William
On Tue Jun 2, 2026 at 6:44 AM MDT, Mario Marietto wrote:
>>I'm here with you and Arya too. In the most of the cases the open-source
>>software doesn't need to be created in the constant hurry, crunches,
>>squeezing deadlines and race for the bottom^W"new shiny features", like
>>in the commercial software development
>
> It's also interesting to consider the other side of the coin. Yes, rushing
> to develop amazing new features is wrong because you end up offering code
> full of holes, but it's also true that it's not fair to make people wait
> decades to see your amazing features. Technological progress continues even
> if you're a clean code purist. And if you don't chase it (at least a
> little), your system will become increasingly niche. What will happen
> now? Users
> will produce their own amazing features and use and share them even if you
> don't want them to. And they'll say they're features that were added to the
> operating system you, the code purist, work on. And so, little by little,
> increasingly deeper and more important forks will be created, and your
> clean operating system will disappear within 10 years, or even less. What
> can you do? As I repeat, chasing the speed at which AI produces code is a
> losing battle. You could challenge it on quality, but certainly not with
> the time it took you to develop your favorite *BSD. Welcome to the age of
> democratized code, baby. Today we still have more bazaars than cathedrals. And
> all that's left to do is work better and faster.
>
> Mario.
>
> On Tue, Jun 2, 2026 at 11:54 AM Eugene Andrienko <evg.andrienko%gmail.com@localhost>
> wrote:
>
>> William Brawner <me%wbrawner.com@localhost> writes:
>>
>> > I'm with Arya here. I switched from Linux to NetBSD because of the
>> > AI-code ban. Something along the lines of vim-classic[1] (a
>> > maintenance-mode fork without AI code) might be feasible in the short
>> > term.
>>
>> I'm here with you and Arya too. In the most of the cases the open-source
>> software doesn't need to be created in the constant hurry, crunches,
>> squeezing deadlines and race for the bottom^W"new shiny features", like
>> in the commercial software development.
>>
>> So, looks like there are no sane reasons to voluntarily use the same
>> LMMs, which were forcefeeded to workers in the commercial companies, in
>> the open-source community … except maybe the way to tease own ego with
>> the pRoDuCtIvItY. While the users in the same community just want the
>> stable and working thing with ability to look inside, if necessary. Not
>> something like rsync 3.4.3 which started to fail during incremental
>> backups with multiple --compare-dest=arguments, because main developer
>> started to vibecode as mush as possible.
>>
>> --
>> Eugene Andrienko
>>