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:	Wed, 30 Apr 2008 18:40:39 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Willy Tarreau <w@....eu>, David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!



On Wed, 30 Apr 2008, Linus Torvalds wrote:
> 
> You (and Andrew) have tried to argue that slowing things down results in 
> better quality,

Sorry, not Andrew. DavidN.

Andrew argued the other way (quality->slower), which I also happen to not 
necessarily believe in, but that's a separate argument.

Nobody should ever argue against raising quality.

The question could be about "at what cost"? (although I think that's not 
necessarily a good argument, since I personally suspect that good quality 
code comes from _lowering_ costs, not raising them).

But what's really relevant is "how?"

Now, we do know that open-source code tends to be higher quality (along a 
number of metrics) than closed source code, and my argument is that it's 
not because of bike-shedding (aka code review), but simply because the 
code is out there and available and visible.

And as a result of that, my personal belief is that the best way to raise 
quality of code is to distribute it. Yes, as patches for discussion, but 
even more so as a part of a cohesive whole - as _merged_ patches!

The thing is, the quality of individual patches isn't what matters! What 
matters is the quality of the end result. And people are going to be a lot 
more involved in looking at, testing, and working with code that is 
merged, rather than code that isn't.

So _my_ answer to the "how do we raise quality" is actually the exact 
reverse of what you guys seem to be arguing.

IOW, I argue that the high speed of merging very much is a big part of 
what gives us quality in the end. It may result in bugs along the way, but 
it also results in fixes, and lots of people looking at the result (and 
looking at it in *context*, not just as a patch flying around).

And yes, maybe that sounds counter-intuitive. But hey, people thought open 
source was counter-intuitive. I spent years explaining why it should work 
at all!

			Linus
--
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