From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 19:22:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D866916A47B for ; Thu, 14 Dec 2006 19:22:17 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9D743CCF for ; Thu, 14 Dec 2006 19:18:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBEJK6Ot025359; Thu, 14 Dec 2006 12:20:11 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4581A3E3.9060807@samsco.org> Date: Thu, 14 Dec 2006 12:20:03 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Peter Jeremy References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi+mx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org> <200612140917.25523@aldan> <20061214183026.GA1532@turion.vk2pj.dyndns.org> In-Reply-To: <20061214183026.GA1532@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 19:22:18 -0000 Peter Jeremy wrote: > On Thu, 2006-Dec-14 16:35:41 +0100, Ivan Voras wrote: >> For what it's worth: +1. It's going to be practically required even for >> medium-performance applications as CPU clock rate stagnate and more >> cores are grown. > > Sun have stated that they do not expect SPARC clock speeds to increase > significantly. Instead, they will be doubling the number of threads > per chip every year or so. (32 now, 64 next year). > > Intel have announced quad-core x86 chips. AMD will presumably follow suit. > > Based on the current release engineering guidelines, FreeBSD 7.x will > probably be supported until around 2011 (-RELEASE next year, -STABLE > for about 18 months, continued support for 2 years after 8-RELEASE). > The system toolchain is a critical piece of infrastructure and making > a major change within a release is impractical. IMHO, rather than > looking at what is mature now, FreeBSD -CURRENT should be looking at a > toolchain that is closer to the leading edge (as long as there are > no significant regressions in stability) but will mature shortly > before 7-RELEASE. This is a valid point. > This maximises the period of "vendor" support for > the toolchain and therefore reduces the amount of FreeBSD developer > effort that will be spent supporting the toolchain once the vendor > stops doing so. "Vendor support" from the FSF is a myth. FreeBSD has been chasing this myth for years, and it never ever turns out to be true. GCC 3.4 was rushed in a fast as possible on the exact argument that 3.4 had vendor support and 3.3 did not. That was 18 months ago (May 18, 2005), which is not very long. In that 18 months, the FSF apparently has stopped supporting 3.4, 4.0, and 4.1. Calling that "vendor support" is insane. The FSF only "supports" the latest and greatest and possibly the previous release for a short period of time. > > The computing industry moves relatively fast and you can't wait for > your supplier's product to be fully mature before you start developing > on it or your customers will go elsewhere because their customers > won't buy what they see as a product running on an obsolete base. > Yes, the industry moves fast, but that's no reason to fool ourselves into thinking that the FSF will support GCC 4.2 a day after they release 4.3 and start working on 4.4. Your point above about the lifespan of FreeBSD 7.x is a valid one, and I agree that it should be a consideration. Vendor support is a myth and should not be a consideration. Scott