From owner-freebsd-stable Sat Jun 23 20:53:31 2001 Delivered-To: freebsd-stable@freebsd.org Received: from guru.mired.org (okc-27-141-144.mmcable.com [24.27.141.144]) by hub.freebsd.org (Postfix) with SMTP id B542C37B401 for ; Sat, 23 Jun 2001 20:53:26 -0700 (PDT) (envelope-from mwm@mired.org) Received: (qmail 67877 invoked by uid 100); 24 Jun 2001 03:53:26 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15157.25654.158066.311481@guru.mired.org> Date: Sat, 23 Jun 2001 22:53:26 -0500 To: FreeBSD Admin Cc: "Stable" Subject: RE: Staying *really stable* in FreeBSD In-Reply-To: <4.3.2.7.2.20010623150807.034a09a0@24.0.95.106> References: <15155.29806.145760.832648@guru.mired.org> <4.3.2.7.2.20010623150807.034a09a0@24.0.95.106> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG FreeBSD Admin types: > I haven't posting anything in some time, so I'm making up for it now with > this tome. 8-) It says nothing important and means nothing, so skip as you > like. You do have some very good points, and some of them are being addressed already. > Don't think that the computer industry doesn't look at what goes on at the > FreeBSD jamboree. FreeBSD could be the next Linux, (stop booing) in terms > of gaining a much larger industry following since we all know it totally > trashes Linux. But and it's a big BUT, the industry PERCEPTION of the > FreeBSD community, it's response to security problems, it's ability to > recognize problems with stability, and reliability, seems to matter more > than what the reality is. This is all very true, but you have to consider what the goal of the project - or rather, the people working on it - is. While I don't speak for them, as far as I'm concerned getting lots of people to use FreeBSD is less important than continuing to provide a quality computing platform. One of the advantages of open source is that the developers can ignore the popularity contest of the market, and concentrate on quality. Not that I wouldn't like FreeBSD to be the most popular platform around, but if it has to become Windows - or even Linux - to do so, it clearly isn't worth it. I've seen enough tools go sour in pursuit of market share that I'd rather not see a single change that sacrifices quality for market share. > I use and maintain AIX and HP-UX systems. I very much love FreeBSD --- that > is, except for this maintenance nightmare. Because it's so hard to pinpoint > an exact microsecond in time when STABLE is really almost/nearly/ stable, > I'm still running a 2.2.8 system. Since there's also no decent way to > upgrade, I've been waiting for the time to built a new system and switch > over. Except, that time never seems to come. I finally stopped my > subscription to the CD. I have a stack of them from 2.2.5 all the way up to > 3.4 (3.5?). Note that the section heading of the handbook is "The Cutting Edge". I don't track current on anything in any kind of production, and I don't track stable on anything even remotely critical. I've maintained AIX systems, but SunOS, Solaris and Ultrix are what I normally deal with. The process of upgrading those systems is no easier than ugprading a FreeBSD system that's through the subscriptions. FreeBSD doesn't have anything like the binary patches available for those systems, and I've complained about that lack myself. Then again, none of them have anything like tracking stable - much less current - and I miss that when dealing with those systems. > I started once before with the 3.x branch, building another system. Oops. > Suddenly all the device and partition and slice names changed. I just > didn't have a whole weekend to devote to this, so it got abandoned. There's a reason for such things. If you really want, I can explain it. I will note that Solaris does - well, once did, as they fixed it - worse. It renumbered the disk drives after an upgrade, which left one system trying to mount a raw Ingres partition as /usr. > I need a relatively painless way to keep my system current with vital > security patches, and fix broken subsystems, without having a Ph.D. in > FreeBSD, or needing to spend 20 hours of my weekend figuring out what to do. I agree, that would be really nice. I do it by tracking stable on a production machine that's not critical. I'm very careful about it - which means it takes time. Mission critical machines generally run softare off the CDs. I watch the security list, and when a bug shows up in software that they are running, I'll skip updating the production system tracking stable, and ugprade the effected machines from the source tree that machine has been running for at least a week. With 4.3, there's a new branch to track - RELENG_4_3 - that contains nothing but security fixes. I'm looking forward to giving it a try. There are apparently also binary patches built from RELENG_4_3, which I may well use instead. > How can I patch my system from a STABLE branch that doesn't have specific > "builds" that I can choose from? My druthers would be to stay back a few > weeks and then pick up something that's had the problems know up to that > time, worked out. Sort of like doing a bi-weekly code freeze and new build. > But I think that means propagating the fixes to the fixes back to each > build along with other problems. There must be a way something like this > could be done to increase the stability and reliability of the product. That's pretty much what RELENG_4_3 addresses. It doesn't make the job of upgrading from one RELEASE to another any easier; after all, you'll be upgrading from RELEASE X.Y + bug fixes - whether they are applied as binary patches or as a source build - to RELEASE X.(Y+1) in either case. > Without making it insanely difficult for hundreds of wonderful volunteers, > shirley (8->) there must be some way to rethink the reliability and > serviceability of the product. You can have all the gee-whiz-bang features > and performance, but without some assurance of stability, reliability AND > serviceability (i.e. fairly straight forward update/patch mechanisms), > FreeBSD will never be able to rule the world. Has FreeBSD become so adamant As noted, I'd rather have stability, reliability and serviceability than rule the world. In fact, I feel I get those now. It takes more work than using commercial software - but it's also better than the commercial software I'm familiar with. Granted, I'm not familiar with HP-UX and it's reputation suggests that it may provide the stability, reliability and servicability of FreeBSD without the work. But FreeBSD just grew new update/patch mechanisms. I would once again advocate seeing how well those work before trying to change things again. If they still need more work, I've got some ideas myself. But I'm going to wait and see how well the new features work before doing anything with those ideas. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message