On 22.03.2010, at 20:54, Ingo Molnar wrote:

quoted text
> 
> * Alexander Graf <agraf@suse.de> 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.

quoted text
> 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.

quoted text
> 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--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/