> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > wrote: > > > > > >> William Brawner <[email protected]> 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 > > >> > >
