From owner-freebsd-security@FreeBSD.ORG Wed Sep 8 04:03:53 2010 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8139010656C3 for ; Wed, 8 Sep 2010 04:03:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 26B538FC18 for ; Wed, 8 Sep 2010 04:03:52 +0000 (UTC) Received: (qmail 12643 invoked by uid 399); 8 Sep 2010 03:37:10 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Sep 2010 03:37:10 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C8704E3.5000408@FreeBSD.org> Date: Tue, 07 Sep 2010 20:37:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Vadim Goncharov References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> <4C8627A6.1090308@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 04:03:53 -0000 On 09/07/2010 02:31 PM, Vadim Goncharov wrote: > 07.09.10 @ 18:53 Andriy Gapon wrote: > >> on 07/09/2010 13:38 Vadim Goncharov said the following: >>>> Just to clarify things a little for those following it: >>>> the original I4B code was removed > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (1) >>>> for entirely practical reasons: it couldn't run without the Giant >>>> lock, and support for the Giant lock over the network stack was >>>> removed. >>> >>> But if it was used, removing a component just because of Giant lock >>> is not >>> practical and is purely ideologic, isn't it? >> >> Which part of "support for the Giant lock *over the network stack* was >> removed" >> [emphasis mine] do you not understand? > > No, component removed was (1), I've underlined. > >> The reason is performance for overall network stack, not ideology. > > For a practical reasons, "it works but slow" is better than > "doesn't work at all (due to absence of code in the src tree)". I think you are misunderstanding the situation. It wasn't a case of, "It works but it's slow." The situation was that in order to take performance of the network stack as a whole up to the next level it was necessary to remove the Giant lock. Because the original I4B code didn't work without the Giant lock, and because no one stepped forward to fix that, the code had to be removed. >> BTW, there were advanced notices for users, request for volunteers, etc. >> >> So, if you didn't speak up at that time please keep silence now :-) > > You do not understand the problem. It is not in notices & volunteers, In this case it was 100% about the latter. In addition to the fact that without volunteers there is no project, period; the fact that no one steps forward to maintain/improve a given piece of code is generally a pretty good indicator that it's not widely used. > but rather in the Project's policy - delete something which could still > work. This was not the case here. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/