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

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

> 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!

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

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.

> > 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? :-)

I guess you are talking to the wrong person as i actually have implemented ls 
functionality in the kernel, using async IO concepts and extreme threading ;-) 
It was a bit crazy, but was also the fastest FTP server ever running on this 
planet.

	Ingo