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

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

> 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 am interested in and looking forward to it.

On Tue, Jun 2, 2026 at 5:32 PM Vitaly Shevtsov <shev.vt1984%gmail.com@localhost> wrote:
>
> > 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
> > >>
> >