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]
Date:	Thu, 18 Mar 2010 12:19:55 -1000
From:	Zachary Amsden <zamsden@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Avi Kivity <avi@...hat.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, 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>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project

On 03/18/2010 11:15 AM, Ingo Molnar wrote:
> * Zachary Amsden<zamsden@...hat.com>  wrote:
>
>    
>> On 03/18/2010 12:50 AM, Ingo Molnar wrote:
>>      
>>> * Avi Kivity<avi@...hat.com>   wrote:
>>>
>>>        
>>>>> The moment any change (be it as trivial as fixing a GUI detail or as
>>>>> complex as a new feature) involves two or more packages, development speed
>>>>> slows down to a crawl - while the complexity of the change might be very
>>>>> low!
>>>>>            
>>>> Why is that?
>>>>          
>>> It's very simple: because the contribution latencies and overhead compound,
>>> almost inevitably.
>>>
>>> If you ever tried to implement a combo GCC+glibc+kernel feature you'll know
>>> ...
>>>
>>> Even with the best-run projects in existence it takes forever and is very
>>> painful - and here i talk about first hand experience over many years.
>>>        
>> Ingo, what you miss is that this is not a bad thing.  Fact of the
>> matter is, it's not just painful, it downright sucks.
>>      
> Our experience is the opposite, and we tried both variants and report about
> our experience with both models honestly.
>
> You only have experience about one variant - the one you advocate.
>
> See the assymetry?
>
>    
>> This is actually a Good Thing (tm).  It means you have to get your
>> feature and its interfaces well defined and able to version forwards
>> and backwards independently from each other.  And that introduces
>> some complexity and time and testing, but in the end it's what you
>> want.  You don't introduce a requirement to have the feature, but
>> take advantage of it if it is there.
>>
>> It may take everyone else a couple years to upgrade the compilers,
>> tools, libraries and kernel, and by that time any bugs introduced by
>> interacting with this feature will have been ironed out and their
>> patterns well known.
>>      
> Sorry, but this is pain not true. The 2.4->2.6 kernel cycle debacle has taught
> us that waiting long to 'iron out' the details has the following effects:
>
>   - developer pain
>   - user pain
>   - distro pain
>   - disconnect
>   - loss of developers, testers and users
>   - grave bugs discovered months (years ...) down the line
>   - untested features
>   - developer exhaustion
>
> It didnt work, trust me - and i've been around long enough to have suffered
> through the whole 2.5.x misery. Some of our worst ABIs come from that cycle as
> well.
>    

You're talking about a single project and comparing it to my argument 
about multiple independent projects.  In that case, I see no point in 
the discussion.  If you want to win the argument by strawman, you are 
welcome to do so.

> Sorry, but i really think you are really trying to rationalize a disadvantage
> here ...
>    

This could very well be true, but until someone comes forward with 
compelling numbers (as in, developers committed to working on the 
project, number of patches and total amount of code contribution), there 
is no point in having an argument, there really isn't anything to 
discuss other than opinion.  My opinion is you need a really strong 
justification to have a successful fork and I don't see that justification.

Zach
--
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/

Powered by blists - more mailing lists