[flagged]
How many developers does the project have? What is your metric for "biggest?" Just total number of contributions?
> You're complaining that the developers of QEMU themselves
Yep. Do any of them work for any commercial companies? Or are we ignoring that to make an argument of appeals? If they all left would QEMU have zero developers?
> because they think it'll work well for them?
Looking at the set of challenges presented at the bottom of the email and their wiki I'm not sure this idea is well founded. There are more wacky compromises listed than there are good ideas.
If you're just going to push hacks upstream and maintain vendor forks downstream then why wouldn't you just start a new project and bring in whatever bits of C code you need until you can replace them.
I've yet to these efforts actually reduce baggage or show any hope of showing returns on investment inside of a decade of insane effort, which always seems to hamper any further feature or bugfix development, out of fear of interrupting other agonizing "works in progress."
Some of this think this is clearly goofy and can't help but comment on it.
I am happy to learn about other's opinions and especially contrary opinions, otherwise I would not have made a public post. I am myself not 100% sure that the idea will be successful, it would be stupid to think it certainly will; but the good thing is that the existing C code will be unaffected (or improved; for example https://lore.kernel.org/qemu-devel/20241129180326.722436-1-p... was found while looking at the code to write the corresponding Rust bindings).
Sometimes you have to try crazy things. One perhaps controversial changes I headed in QEMU was to introduce the Meson build system. You may wonder what is wrong with me. I am happy to say that since then I have almost never had to ask a question about the build system, which was a very common occurrence before, and it has actually simplified the implementation of features such as custom device configuration, improved module loading, entitlement support for macOS, relocatable installs, autogenerated parsing of the configure command line, improvements to cross-compilation. While slightly reducing the number of lines of code compared to before. So I disagree that exploratory work is "a decade of insane effort".
So I am curious, what are the wacky compromises?
Should call this site "embarrassed hacker propaganda." At least then you'd "have a leg to stand on." What a gross tactic you've relied on here.
I’m perfectly happy with appealing to authority when you respond to Josh Tripplet’s point about the author being a longtime contributor with these weird followup questions about “biggest?” and whatever, which in turn was a followup to the bizarre statement about invading projects ([1] again). Linus Torvalds is fine with the Rust in the Kernel experiment. This author is a longtime Linux contributor. So yes indeed: who are you to question Rust in the Kernel project?
To unpack a bit. Everything can be questioned. But with some sort of temperance and perspective. Talking about pushing “hacks upstream” is over the top and unfounded considering the context (what you call appeal to authority).
It would be appropriate if these were outsider upstarts that didn’t have a history in this project. But it aint.