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

[William Brawner <me%wbrawner.com@localhost>]

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.

[1]: https://vim-classic.org/


El 1 de junio de 2026 10:17:07 a.m. GMT-06:00, Mario Marietto <marietto2008%gmail.com@localhost> escribió:
>---> Is there any serious momentum behind getting OpenBSD's vmm or
>FreeBSD's bhyve working seamlessly as the frontend for NVMM? I'd much
>rather migrate to a clean, human-maintained codebase than deal with the
>fallout of whatever QEMU is about to merge into their tree.
>
>We (me,a friend of mine and Claude) have recently improved the job of
>Abhinav Chavali :
>
>https://summerofcode.withgoogle.com/archive/2025/projects/lRkVElCJ
>
>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].
>
>I've got so many improvements in 1 week that a full programming team would
>not be able to achieve in years. Maybe not because they have no
>competence,but because *BSDs are OS used by 1% of the people. Programmers
>are few, underpaid and overworked. Times have changed. Today with AI we can
>carry on a lot of long complicated projects in a fraction of time and
>money. No one,nothing can stop this. What can be done,maybe,is the code
>correction by humans. But I don't think it's easy, for the same reasons
>explained above. AI creates a lot of code (and Claude's is of good quality)
>in a short time. Humans can't keep up with it.
>
>Mario.
>
>On Mon, Jun 1, 2026 at 4:56 PM Aryabhata <bsdhexa%gmail.com@localhost> wrote:
>
>> Hey everyone,
>>
>> I'm sure some of you caught the recent news that QEMU is revising its
>> policy to start accepting AI/LLM-generated code. Frankly, the idea of
>> running VMs on a hypervisor padded with unreviewable AI slop is extremely
>> off-putting.
>>
>> Since QEMU is the main userspace consumer for NVMM right now, it feels
>> like we're tethered to an upstream project that's actively lowering its
>> standards. What is everyone else planning to use as a daily driver to avoid
>> this?
>>
>> Is there any serious momentum behind getting OpenBSD's vmm or FreeBSD's
>> bhyve working seamlessly as the frontend for NVMM? I'd much rather migrate
>> to a clean, human-maintained codebase than deal with the fallout of
>> whatever QEMU is about to merge into their tree.
>>
>> Would love to hear what alternatives you guys are looking at.
>>
>> Thanks,
>>
>> Arya
>>
>
>