lkml.org 
[lkml]   [2010]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project
On 03/22/2010 10:21 PM, Ingo Molnar wrote:
> * 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.
>

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.



\
 
 \ /
  Last update: 2010-03-22 21:39    [W:0.594 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site