Messages in this thread | | | Date | Mon, 22 Mar 2010 22:35:27 +0200 | From | Avi Kivity <> | Subject | Re: [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.
| |