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: <alpine.LFD.1.10.0804301225590.2980@woody.linux-foundation.org>
Date:	Wed, 30 Apr 2008 12:42:07 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Newall <davidn@...idnewall.com>
cc:	Chris Friesen <cfriesen@...tel.com>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org
Subject: Re: Slow DOWN, please!!!



On Thu, 1 May 2008, David Newall wrote:
>
> You're taking this far too personally.

Umm. If you didn't want a personal opinion, why did you Cc me in the first 
place then, and ask for my input?

I gave my input to you. I think your arguments are ludicrous, to the point 
of being totally idiotic. You complain how I don't release kernels that 
are stable, but without any suggestions on what the issue might be, apart 
from apparently me merging too much and making too many releases.

But do you really expect me to stop merging, or hold up releases that fix 
hundreds of issues, just because there are other issues pending? Do you 
really think development can be stopped? Trust me, we've tried. Every 
time, it just leads to worse problems when the floodgates are then opened.

And yes, there is a solution: don't develop so much. Don't allow thousands 
of developers to be involved. Do a small core group, and make development 
so hard or inconvenient that you only have a few tens of people who write 
code, and vet them and force them to jump through hoops when adding new 
features (or fixing old ones, for that matter).

And yes, that *does* result in a "stable" system. Never mind that it's 
stable for all the wrong reasons, and generally doesn't actually work well 
across a dynamic environment (whether the hardware base below or user 
space above).

See? This is why I think your arguments are so silly and misguided. 

But if you actually have real constructive ideas on things to actually 
*do*, please do mention them. We've changed our models over time, several 
times, exactly because we've searched for better ways to do thigns. But do 
realize that

 (a) we can't just stop, or even really slow down. We can onyl try to 
     regulate and to some degree direct the flood, not hold it up for any 
     particular issue.

 (b) We do have process in place, and it may not be perfect, but I doubt 
     anything is, and what we do have actually has evolved over the years. 

     And that's not just my process (ie "two-week merge window, followed 
     by about 6-8 weeks of fixups"), but the whole process both before and 
     after it (Andrew and now linux-next in front of it, and stable kernel 
     tree and the vendors after it).

 (c) the "big picture" discussion is separate from individual issues. If 
     you want your suspend-to-disk issue resolved, or a memory leak 
     solved, you don't solve those by trying to complain about other parts 
     of the system, that are totally separate.

     The global flow of patches and releases is not something that we can 
     hold up for _any_ of your individual problems. I do end up delaying 
     releases for really core things, so individual problems do obviously 
     affect (for example) the release timing. But the solution to them is 
     not in complaining about slowing down development, it is about 
     actually trying to engage the developers of *that* feature in *that* 
     particular bug.

And finally, trust me, if you want to have people care about your 
problems, the last thing you want to do is say "I might switch to BSD". 
Because quite frankly, I really don't care. People who think that threats 
like that work in any productive way can go screw themselves. I'll flame 
idiots like that, and my likelihood of helping people because they think 
they hold a gun to my head is almost zero.

		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

Powered by Openwall GNU/*/Linux Powered by OpenVZ