Date: Wed, 03 Dec 2003 16:14:52 -0800 From: Mike Hoskins <mike@adept.org> To: advocacy@freebsd.org Subject: Re: uptime 4.0 Message-ID: <3FCE7C7C.3090901@adept.org> In-Reply-To: <002b01c3b99e$a1dc3340$6c01a8c0@MITERDOMAIN> References: <002b01c3b99e$a1dc3340$6c01a8c0@MITERDOMAIN>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FCE7C7C.3090901>