From owner-freebsd-advocacy@FreeBSD.ORG Wed Dec 3 16:14:54 2003 Return-Path: Delivered-To: freebsd-advocacy@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD75816A4CE for ; Wed, 3 Dec 2003 16:14:54 -0800 (PST) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69E8343F3F for ; Wed, 3 Dec 2003 16:14:53 -0800 (PST) (envelope-from mike@adept.org) Received: from localhost (localhost [127.0.0.1]) by localhost.adept.org (Postfix) with ESMTP id 35A9F15442 for ; Wed, 3 Dec 2003 16:14:53 -0800 (PST) Received: from fubar.adept.org ([127.0.0.1]) by localhost (fubar.adept.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 32006-05 for ; Wed, 3 Dec 2003 16:14:53 -0800 (PST) Received: from adept.org (mojo.televoke.net [63.237.196.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fubar.adept.org (Postfix) with ESMTP id F015215440 for ; Wed, 3 Dec 2003 16:14:52 -0800 (PST) Message-ID: <3FCE7C7C.3090901@adept.org> Date: Wed, 03 Dec 2003 16:14:52 -0800 From: Mike Hoskins User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: advocacy@freebsd.org References: <002b01c3b99e$a1dc3340$6c01a8c0@MITERDOMAIN> In-Reply-To: <002b01c3b99e$a1dc3340$6c01a8c0@MITERDOMAIN> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: uptime 4.0 X-BeenThere: freebsd-advocacy@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD Evangelism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2003 00:14:54 -0000 Paul Robinson wrote: > 1. Uptimes of 1,200 days says wonderful things about FreeBSD. > 2. Uptimes of 1,200 days says terrible things about the administrators > of those boxes. i can see both sides. i tend to agree (in practice) with #2, but i also know people running "mission critical" apps on 2.2.x... apps much larger than the ones i admin... so i can't really judge (too much). ;) > Of course, the real answer here is to work on a way of allowing for an > "upgrade" to happen without re-booting the machine, thereby getting > kerenel patching without losing service or uptime. However, until we get > to that point, consider patching at least once a quarter to a recent > -RELEASE or even better, -STABLE cvsup, and go from there. i believe the best/recommended way is to track the relevant (preferably latest) _security_ branch in production envrionments. that would be RELEASE + bug/security fixes. STABLE isn't always "stable" (for good reasons). i've tracked stable in production environments, but wouldn't suggest doing so unless you have a nice staging environment. tracking RELENG_x_x ("security") vs. RELENG_x ("stable") can avoid some hassle, but admittedly there are times when only STABLE will do.