Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Jan 2003 13:45:35 -0500
From:      Bill Vermillion <bv@wjv.com>
To:        stable@FreeBSD.ORG
Cc:        freebsd-stable-digest@FreeBSD.ORG
Subject:   Re: FreeBSD Stability
Message-ID:  <20030104184535.GC63678@wjv.com>
In-Reply-To: <bulk.52038.20030104095649@hub.freebsd.org>
References:  <bulk.52038.20030104095649@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
When asked his whereabouts on Sat, Jan 04, 2003 at 09:56 , 
stable-digest took the fifth, drank it, and then slurred:

> stable-digest        Saturday, January 4 2003        Volume 05 : Number 756

> Date: Sat, 4 Jan 2003 15:41:57 +0100
> From: Thomas Seck <tmseck-lists@netcologne.de>
> Subject: Re: FreeBSD Stability

> * Wes Peters (wes@softweyr.com):

> > On Fri, 2003-01-03 at 15:43, Thomas Seck wrote:

> > > * Nimrod Mesika (nimrod-me@bezeqint.net):

> > > > And uptimes are not important. Downtimes *are*.

> > > Yes. Especially the unscheduled ones.

> > Don't be silly, uptimes are terribly important when they're
> > not long enough to be useful. They're no longer important
> > when they've gotten long enough to last between system
> > upgrades, which FreeBSD and a number of other systems are
> > regularly capable of these days.

> You are over interpreting my message. Using publicly gathered
> uptimes as a scale to measure 'stability' with is just
> nonsense, because you cannot tell from the outside whether
> a 'low' uptime is due to stability issues or due to good
> maintenance. Doing advocacy based on this is even sillier.

You can have long uptime with good maintenance.  I had a mail
server that I had up for 575 days [In a colo with mamoth backup
systems] and I updated components that needed it.  It was running
basically only mail and a secondary DNS.  And that was about it.

> Tell me: what is the maximum uptime one can achieve when following all
> FreeBSD security advisories which involve loading a new kernel due to
> locally or remotely exploitable kernel vulnerabilities?

Most of the security problems were in modules that did not require
kernel upgrades.  Just keeping up with those can keep you on your
toes.

But if the system were using far more than just a few things I'd
probably have done it earlier.  Mainting colo machines I don't like
to reboot/rebuild them unless absolutely neccesary. And then I do
it late at night so I can drive there >if< something fails to comp
up.

Bill
-- 
Bill Vermillion - bv @ wjv . com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030104184535.GC63678>