On 22.03.2010, at 20:54, Ingo Molnar wrote: > > * Alexander Graf <[email protected]> wrote: > >> Yes. I think the point was that every layer in between brings potential >> slowdown and loss of features. > > Exactly. The more 'fragmented' a project is into sub-projects, without a > single, unified, functional reference implementation in the center of it, the > longer it takes to fix 'unsexy' problems like trivial usability bugs.
I agree to that part. As previously stated there are few people working on qemu that would go and implement higher level things though. So some solution is needed there. > Furthermore, another negative effect is that many times features are > implemented not in their technically best way, but in a way to keep them > local > to the project that originates them. This is done to keep deployment > latencies > and general contribution overhead down to a minimum. The moment you have to > work with yet another project, the overhead adds up. I disagree there. Keeping things local and self-contained has been the UNIX secret. It works really well as long as the boundaries are well defined. The problem we're facing is that we're simply lacking an active GUI / desktop user development community. We have desktop users, but nobody feels like tackling the issue of doing a great GUI project while talking to qemu-devel about his needs. > So developers rather go for the quicker (yet inferior) hack within the > sub-project they have best access to. Well - not necessarily hacks. It's more about project boundaries. Nothing is bad about that. You wouldn't want "ls" implemented in the Linux kernel either, right? :-) Alex-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
