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

[Vitaly Shevtsov <shev.vt1984%gmail.com@localhost>]

> that added VMM acceleration support to QEMU on FreeBSD. Now it is fully working on my github.
> At the moment we are working to enable the GPU passthrough,using my GPU [RTX 2080 ti].

But do you understand what exactly Claude did? Do you understand how it works?
And would you mind presenting these changes at, say, GSoC, and being
prepared to answer any questions about the technical solutions in this
fork?

On Tue, Jun 2, 2026 at 5:14 PM William Brawner <me%wbrawner.com@localhost> wrote:
>
> 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
> >>
>