Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Jun 2001 22:53:26 -0500
From:      Mike Meyer <mwm@mired.org>
To:        FreeBSD Admin <freebsd@home.com>
Cc:        "Stable" <stable@FreeBSD.ORG>
Subject:   RE: Staying *really stable* in FreeBSD
Message-ID:  <15157.25654.158066.311481@guru.mired.org>
In-Reply-To: <4.3.2.7.2.20010623150807.034a09a0@24.0.95.106>
References:  <JBEOKPCEMKJLMJAKBECCGENKDBAA.jwatkins@firstplan.com> <15155.29806.145760.832648@guru.mired.org> <4.3.2.7.2.20010623150807.034a09a0@24.0.95.106>

next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD Admin <freebsd@home.com> 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.

	<mike
--
Mike Meyer <mwm@mired.org>			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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15157.25654.158066.311481>