From owner-freebsd-hackers Mon Dec 10 12:37:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6A2EB37B416; Mon, 10 Dec 2001 12:37:33 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBAKYwi08014; Mon, 10 Dec 2001 15:34:58 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 10 Dec 2001 15:34:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: D J Hawkey Jr Cc: Michael Lucas , hackers@FreeBSD.ORG Subject: Re: Tangent for discussion: FreeBSD performs worse that Linux In-Reply-To: <20011210074151.A29219@sheol.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Dec 2001, D J Hawkey Jr wrote: > I can backport to 4.2REL and 4.3REL (I have these releases), but I don't > have the resources (read: "free partitions") to accomodate 4.1 or 4.4. For 4.3-RELEASE, there's a RELENG_4_3 branch in CVS that security fixes are committed to; you'd probably want to generate patches with respects to the head of the RELENG_4_3 branch so as not to have to duplicate the security bug fixes, only the non-security ones that don't go into RELENG_4_3. Otherwise, you'd lose out on some of the more desirable bug fixes :-). Note also that as a release gets older, it drops off the "security-officer supported" list, due to a gradual increase in the level of work required to support the release. This tends to happen when a major subsystem has to be replaced in order to fix the bug, rather than a minor tweak being sufficient. For example, the death of RELENG_3 from the SO perspective was when ncurses had to be replaced, rather than patched, to cover all known holes. This required relinking of countless binaries, making a binary update relatively infeasible, and requiring a high level of investment in order to update past changed APIs. How fast the window runs out on a release depends on what needs fixing, so it's hard to predict when it will happen. Having the "release branches" has made generating security updates far more efficient, and permitted us to handle a binary update model for userland binaries. Without version control in place, as it wasn't for this stuff for a long time, it was very hard to generate relative patches, manage large numbers of patchsets for various versions, or keep any notion of binary updates in order. It doesn't fix the windowing issue, but it does make it easier to deal with. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message