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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BA7D48F.8000806@redhat.com>
Date:	Mon, 22 Mar 2010 22:35:27 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Alexander Graf <agraf@...e.de>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Yanmin Zhang <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	LKML Mailing List <linux-kernel@...r.kernel.org>,
	kvm-devel General <kvm@...r.kernel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>,
	Gregory Haskins <ghaskins@...ell.com>
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@...e.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.

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