From owner-freebsd-questions@FreeBSD.ORG Fri Feb 17 18:52:41 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8577E16A420 for ; Fri, 17 Feb 2006 18:52:41 +0000 (GMT) (envelope-from lars@gmx.at) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C825F43D58 for ; Fri, 17 Feb 2006 18:52:40 +0000 (GMT) (envelope-from lars@gmx.at) Received: (qmail invoked by alias); 17 Feb 2006 18:52:40 -0000 Received: from 66.86.62.81.cust.bluewin.ch (EHLO [192.168.1.10]) [81.62.86.66] by mail.gmx.net (mp033) with SMTP; 17 Feb 2006 19:52:40 +0100 X-Authenticated: #912863 Message-ID: <43F61B7F.2080207@gmx.at> Date: Fri, 17 Feb 2006 19:52:47 +0100 From: lars User-Agent: Thunderbird 1.5 (X11/20060203) MIME-Version: 1.0 CC: freebsd-questions@freebsd.org References: <20060216005036.L60635@ganymede.hub.org> <20060216053725.GB15586@parts-unknown.org> <20060216085304.GA52806@storage.mine.nu> <43F4CAA3.1020501@schultznet.ca> <43F4F43D.2090304@gmx.at> <20060216194336.L60635@ganymede.hub.org> <43F5F149.1040001@gmx.at> <20060217140638.B60635@ganymede.hub.org> In-Reply-To: <20060217140638.B60635@ganymede.hub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [Total OT] Trying to improve some numbers ... X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2006 18:52:41 -0000 Marc G. Fournier wrote: >>> You can say you are losing out on 'stability fixes', else the server >>> itself wouldn't stay up that long ... so about the only thing you >>> lose would be performance related improvements and/or stuff like >>> memory leakage ... >>> >>> And I could do this all *without* any firewalls protecting it ... > >> Even if you managed to maintain an old version of a particular OS's >> uptime for so long, what did you prove? > > Wasn't arguing that I "proved" anything, only that a long uptime could > be achieved *without* any security implications :) Point taken :-) >> IMHO 'uptime' as a 'feature' is overrated, not to say obsolete. > > Agreed 100% ... Availability is the useful metric, not how long a > stretch of time the OS can remain running ... not necessarily worded the > best way, but our uptime policy (http://www.hub.org/uptime_policy.php) > was such that we tried to upgrade our servers once every 30 days or so > ... not always possible, and lately less so, but it was our aim ... Actually it sounds quite reasonable. I used to work for a major IT corporation and their SLA didn't amount to much more than that in that particular class of service (i.e. not highly available and/or clustered machines). But they needed a lot more words, to spread the wealth to the legal departments of all parties involved. I'm not entirely against such efforts of long uptimes. I strongly believe in efforts to back up rumor with fact, as in the rumor 'FreeBSD is rock-solid'. Actually I believe it is, but I can't prove it beyond talking of my own experience with it. IMHO a lot of so-called fact is actually hear-say or anecdotal, either because the people spreading these 'facts' don't bother to update their info, the info is purely from each sysadmins personal experience and/or because there's a lack of info that is standardised and repeatable. So this web-site's effort, although similar to the Netcraft uptime stats, is quite alright since it's a first step towards getting some numbers.