Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

[Avi Kivity]

On 03/22/2010 10:21 PM, Ingo Molnar wrote:
> * Alexander Graf<agraf@xxxxxxx>  wrote:
>
>    
> > > 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 'UNIX secret' works for text driven pipelined commands where we are
> essentially programming via narrow ASCII input of mathematical logic.
>
> It doesnt work for a GUI that is a 2D/3D environment of millions of pixels,
> shaped by human visual perception of prettiness, familiarity and efficiency.
>    

Modularization is needed when a project exceeds the average developer's 
capacity.  For kvm,  it is logical to separate privileged cpu 
virtualization, from guest virtualization, from host management, from 
cluster management.

> > 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.
> >      
> Have you made thoughts about why that might be so?
>
> I think it's because of what i outlined above - that you are trying to apply
> the "UNIX secret" to GUIs - and that is a mistake.
>
> A good GUI is almost at the _exact opposite spectrum_ of good command-line
> tool: tightly integrated, with 'layering violations' designed into it all over
> the place:
>
>    look i can paste the text from an editor straight into a firefox form. I
>    didnt go through any hiearchy of layers, i just took the shortest path
>    between the apps!
>    

Nope.  You copied text from one application into the clipboard (or 
selection, or PRIMARY, or whatever
) and pasted text from the clipboard to another application.  If firefox 
and your editor had to interact directly, all would be lost.

See - there was a global (for the session) third party, and it wasn't 
the kernel.

> In other words: in a GUI the output controls the design, for command-line
> tools the design controls the output.
>    

Not in GUIs that I've seen the internals of.

> It is no wonder Unix always had its problems with creating good GUIs that are
> efficient to humans. A good GUI works like the human brain, and the human
> brain does not mind 'layering violations' when that gets it a more efficient
> result.
>    

The problem is that only developers are involved, not people who 
understand human-computer interaction (in many cases, not human-human 
interaction either).  Another problem is that a good GUI takes a lot of 
work so you need a lot of committed resources.  A third problem is that 
it isn't a lot of fun, at least not the 20% of the work that take 800% 
of the time.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/