From owner-freebsd-arch@FreeBSD.ORG Mon Sep 12 11:16:00 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97361106564A; Mon, 12 Sep 2011 11:16:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 577878FC16; Mon, 12 Sep 2011 11:16:00 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E92CD46B2D; Mon, 12 Sep 2011 07:15:59 -0400 (EDT) Date: Mon, 12 Sep 2011 12:15:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Adrian Chadd In-Reply-To: Message-ID: References: <4E6C829A.2080007@gmail.com> <20110911161228.EE0F5106564A@hub.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: johan Hendriks , "freebsd-arch@freebsd.org" , Simon Subject: Re: 4.x era X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 11:16:00 -0000 On Mon, 12 Sep 2011, Adrian Chadd wrote: > I've heard this many times, and here's my (paraphrased) stock response: > > People remember FreeBSD 4.x fondly. They likely don't remember 3.x fondly. > They remember 2.x fondly - because it was rock stable for a lot of users. > Then 3.x came along, with (new!) softupdates, and VM changes, and some other > stuff I was too young to understand. It was stable for me, but unstable for > a lot of much more serious and larger users. 4.x was when that matured. > > People see 8.x as stable. Not in all situations, but in a lot of them. 9.x > may not be as stable for some, but there's a lot of good stuff going into > it. If the developers play their cards right, 9.x will be the cycle where > those bugs are shaken out and later 9.x releases will be rock solid. The > only way that (and hopefully, 10.0) is going to be rock stable and be > remembered like 4.x was remembered is if users actively use it, report bugs > and work with developers to fix it. > > Rather than, you know, staying on FreeBSD-4.x :-) The other rather interesting thing I've observed is that people often remember the same releases quite differently, depending on their environment and workload. I know of several companies that have quite happily deployed early 5.x pre-releases in products that have now been in the field for years -- whereas I tend to remember the early releases as a bit shaky (especially as background file system checking shook out its bugs). The best general strategy is what many companies do: begin early deployment of .0 releases so that you can gain experience, and in particular, help identify critical bugs. Do widespread deployment with .1 and .2 releases, and as you begin to reach .3 and .4, think really hard about how to upgrade! For appliance vendors, it's particularly important to be tracking in-development FreeBSD while building a product, since you want to maximise overlap between FreeBSD's support lifetime for a release and your own. This is particularly critical so that you can avoid backporting drivers yourself when the FreeBSD Project (effectively) de-supports an old development line, but you still have to provide in-the-field hardware upgrades that necessarily involve newer parts that aren't supported by the old release. At least in my own deployments, multi-year uptimes of all our major releases are common. I have one box doing quite active service based on a FreeBSD 7.1 prerelease that has just shy of 900 days uptime. This isn't to say that there aren't problems, but rather to point out that a lot of our intuitions depend on our own quite specific perspectives. A lot depends on the hardware you select -- some of it down to good choices of vendors and avoiding discount parts, but some of it is pure luck -- did you get a generation of disks that was particularly poor, or end up with a BIOS revision that seriously harmed stability. You can often significantly improve OS stability by disabling lots of random BIOS features, regardless of the OS, reducing use of features like SMM that are beyond the OS's control. Robert