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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
