NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: QEMU accepting AI code - viable alternatives for NVMM (bhyve/vmm)?



>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


--
Mario.


Home | Main Index | Thread Index | Old Index