Date: Sun, 21 Mar 1999 12:50:27 -0700 From: Brett Glass <brett@lariat.org> To: W Gerald Hicks <wghicks@bellsouth.net> Cc: wghicks@bellsouth.net, grog@lemis.com, chat@FreeBSD.ORG Subject: Re: Use of FreeBSD-STABLE (was: Oddity in name resolution) Message-ID: <4.1.19990321121915.00b17500@localhost> In-Reply-To: <19990321132457X.wghicks@wghicks.bellsouth.net> References: <Your message of "Sun, 21 Mar 1999 10:54:00 -0700"<4.1.19990321105156.03f213d0@localhost> <4.1.19990321105156.03f213d0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 01:24 PM 3/21/99 -0500, W Gerald Hicks wrote: >production uses. These are mostly development systems, hosts for >in-circuit emulation, and a few CVS repository servers. Our developers >are at *least* as fussy about downtime as a typical ISP customer. > >I suppose an ISP's shell host, mail or news servers would have different >concerns Absolutely. Because it can affect hundreds of those fussy customers all at once! The machines I've been setting up are mission-critical for the organizations they serve -- mail servers, PPP routers for whole branch offices, and Web servers which take orders that keep the company in business. I'm pleased to say that FreeBSD does very well at that. However, for a server like that, you want a build which has been shaken down and stress-tested by a LOT of people. Only the -RELEASE builds are REALLY known to really meet that criterion now. I've brought in patches and individual programs from -STABLE to solve specific problems, but if I were to bring in an entire build, here would be my requirements: 1. A large number of users should have installed and tested that particular build. Because -STABLE is built frequently, the only -STABLE builds that would meet this criterion would be "snapshots" which were marked as such and distributed via the CD-ROM subscription program. A "snapshot" could be a candidate if it were known that it had been used in several HUNDRED diverse and demanding installations. 1000 would be a nice round number to shoot for. 2. A few weeks should have elapsed in which that snapshot had not proven to have significant problems. (Yes, by then, -STABLE would have moved on, so we'd install the snapshot because it was a tested build.) It would instill even more confidence if the snapshots were rated in terms of problems encountered, and one could pick one that had an especially good rating. >but the people I know who administer those usually end up with >heavily customized and finely tuned systems anyway. Updating them is >often a real PITA. By working from a locally modified FreeBSD repository >(another thread) even this can be made more manageable. Yep, but we would still try to limit our updates and changes. It was a nightmare when we hit the ATAPI_STATIC problem in 2.2-STABLE. (If you didn't compile with the ATAPI_STATIC option, a machine with an IDE hard drive would crash under heavy loads. It took us a VERY long time to figure out that this was what made the difference, even after we took the machine out of production and installed a temporary replacement. Why? Because the machine would crash when building new kernels for itself. >Don't like -STABLE? Fine. Pick your own mix of proven kernel/userland >components. It's not that we do or don't "like" -STABLE. We just have very stringent standards for what we'll put on a production machine. Those standards require widespread testing (ideally, 1000 or more diverse installations) in actual use over at least a few weeks. (My guesstimate is that it could take 3-4 weeks before that many people receive, and get around to installing, a new snapshot.) Having it on a branch such as -STABLE in which the modifications are conservative is also important. I have systems that are out on the hairy edge of -CURRENT too, but I don't think I'm alone in wanting a thoroughly tested build for a production system. It'd be nice if one could find, at any given time, an official snaphot that met these criteria. Maybe that version could be called -PRODUCTION and updated to the latest snapshot that had been "tested and proven." --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.1.19990321121915.00b17500>