Date: Sun, 17 Dec 2006 15:55:28 -0600 From: Astrodog <astrodog@gmail.com> To: "Doug Barton" <dougb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Am I an Idiot? Message-ID: <2fd864e0612171355u1183779ds2eb2086442e13da6@mail.gmail.com> In-Reply-To: <4585B4EC.1070906@FreeBSD.org> References: <4579EB08.8080704@intersonic.se> <20061210.230622.-1844001233.imp@bsdimp.com> <45845F8B.3060304@intersonic.se> <45851DBC.9010604@FreeBSD.org> <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> <4585B4EC.1070906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/17/06, Doug Barton <dougb@freebsd.org> wrote: > > Astrodog wrote: > > Something that, in my opinion, may have been missed in all of this, > > > It hasn't been missed. It's been said over and over again. > > > Why, exactly, do you want to run -CURRENT in production? > > If you had actually read this thread, you'd know the answer to that. "It just works better on our fileserver than 6.x does on our production systems" is not a reason. Its an anecdote, that because of the vast differences in load between a fileserver, and a database, webserver, or mailserver, is not particularily valuable. > Running -CURRENT is quite a bit more work than running -STABLE. > > The OP has stated repeatedly that he knows this, and is willing to do > the work as long as time is available. > > > Many of the > > problems that may exist in -CURRENT will be induced by specific > > types of load. Race conditions, Lock Order Reversal, and certain > > driver issues in many cases, only appear under particularly heavy > > loads, or particular types of load. What this means, simply, is > > that when you test the next version of -CURRENT you'd like to run, > > there's quite a bit of testing you'll have to do. > > And this exact testing is what we need from the user base if we're > going to make this thing work. It's ok if _you_ don't want to do it > (really, it is), but please stop trying to discourage someone who has > said repeatedly that he knows what he is signing up for. This isn't testing, though. Since he's removing all of the debugging options, he can only help with 2 things. Either it works, or it doesn't, and he can point out significant performance problems. The kind of testing needed in -CURRENT is controlled, in my opinion. Just look at the PR database, and mailing lists for "Cannot Reproduce". A production system will rarely have an environment that is easily recreated, when someone goes to fix the problem. Understand, that I'm not trying to discourage him, just make sure he's clearly aware of what he's getting into. Everyone seems to be glossing over some important details. > Along side this > > type of problem, is the issue of security. If you are running > > -CURRENT as of 2 weeks ago, and a security vulnerability is > > discovered, in some cases, you will be compelled to upgrade to the > > latest -CURRENT, even if it has known stability problems, or > > performance/functionality regression. > > Um, that's just bollocks. If the only way you know how to update a > system is buildworld, you really should not be giving someone advice > on system administration. There is no other *acceptable* way to upgrade a -CURRENT system every time, as any other method will have undefined results. It might work, but no testing whatsoever is performed on it with any regularity. While its possible to do this with other methods, it will be specific to what needs to be updated. At which point, his system no longer runs -CURRENT, and may run into a crop of bugs that no one will be able to recreate, or even patch for. Enough is enough already. This thread pole-vaulted past its useful > lifetime ages ago, let's let it die. I'm wondering if it might be benificial to put something together for people who are considering -CURRENT on production. I'll send it off list if I come up with something. --- Harrison Grundy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2fd864e0612171355u1183779ds2eb2086442e13da6>