From owner-freebsd-stable Thu Mar 19 19:03:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA06079 for freebsd-stable-outgoing; Thu, 19 Mar 1998 19:03:42 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from const. (willow19.verinet.com [199.45.181.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA06066 for ; Thu, 19 Mar 1998 19:03:32 -0800 (PST) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id UAA19202; Thu, 19 Mar 1998 20:02:55 -0700 (MST) (envelope-from allenc) Date: Thu, 19 Mar 1998 20:02:55 -0700 (MST) From: allen campbell Message-Id: <199803200302.UAA19202@const.> To: mike@smith.net.au Subject: Re: 'Code Freeze' Cc: stable@FreeBSD.ORG In-Reply-To: <199803200125.SAA29636@xmission.xmission.com> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > 2.1.6 and 2.1.7 got tested much more, and fared better because of it. > If you're running production *anything* on FreeBSD 2.2.x, you should be > reading -stable, and you should be beta testing your own configuration > to make sure it works. What I find amazing is the extreme patience shown by the FreeBSD developers toward these supposed sysadmins who seem to have too much time on their hands. If you are responsible for the administration of a production system, the last thing you should be trying to do is keep your machines on the cutting edge of anything. Unless you have a specific need that requires a build, find something productive to do with your time. Your users will appreciate it. I my experience, the vast majority of production system failures can be traced back to system modifications on the part of some administrator. This is true regardless of the OS. Perhaps the worst case of this I have witnessed is an ongoing issue with a Novell admin I have the pleasure of earning a living with. When the Novell network I have to deal with goes down, it is usually not a coincidence that our beloved administrator is standing right at the console at the time. Most failures are pilot error. IMO, if you are responsible for a production system which other people are paying you to keep up, the best policy you can have is to stay consistently behind the latest *anything*. If you don't have the resources to do comprehensive testing, you need to stay even further back. I would like to know from some of the system administrators directly involved in the FreeBSD project; what is the current state of some of the more significant machines (mirrors, list servers, HTTP/FTP sites, CVS, etc) and how often do you 'make the world' on these boxes? I'll bet that most are several releases back and some are downright obsolete :) Thank you. I'll also bet you are not frequent contributors to the 'can't make world!' set. Good system administration is measured in uptime. As an administrator, If you are motivated by something other than uptime do the world a favor and rethink your career choice. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message