Date: Sat, 23 Jun 2001 16:32:05 -0700 From: FreeBSD Admin <freebsd@home.com> To: "Stable" <stable@FreeBSD.ORG> Subject: RE: Staying *really stable* in FreeBSD Message-ID: <4.3.2.7.2.20010623150807.034a09a0@24.0.95.106> In-Reply-To: <15155.56039.812973.488190@zircon.zircon.seattle.wa.us> References: <JBEOKPCEMKJLMJAKBECCGENKDBAA.jwatkins@firstplan.com> <15155.29806.145760.832648@guru.mired.org> <JBEOKPCEMKJLMJAKBECCGENKDBAA.jwatkins@firstplan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Several observations: Your definition of STABLE or really stable can very wildly from mine and the millions (hopefully) of other FreeBSD users. Since there are no "test metrics" to track, AFAIK, and nothing is published on the bugs found and fixed per week, what does STABLE really mean? How stable is stable? What makes STABLE stable? It boots up OK? Only crashes after 10 days instead of 10 minutes? Or maybe only n number of serious problems and y number of minor problems have been reported. Those would be things that we could point to as a measure of just how solid and stable the system is. But again, being just a volunteer organization, no one has the time. I see it as a matter of priorities and resource allocations. Just my worthless opinion. 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. FreeBSD could be the most well-organized, most stable, easy to patch/upgrade system on the planet, but no one would look twice at it, if the *perception* is of a disorganized, chaotic system with no procedures and "best practices" for producing and maintaining a fairly solid system. I'm not saying that it the way we look to the industry, but that the perception of FreeBSD and it's developers as a whole (including committers, porters, and conductors) can be critical to it's success. Sure, FreeBSD powers many major corporate sites, big and small. But that doesn't mean that they would want to sell their systems, running on FreeBSD, unless it was fairly easy to maintain, update for security and most of all have a perceived idea of stability. OK. So here I am, a poor lowly user. I'm far from an expert and just barely past newbie stage. I subscribe to the FREEBSD-STABLE list. But, that doesn't mean that I can make sense of all the arguments that go on here. Did the reporter of a problem just have a mis-configuration or was it a real problem. Timing seems to be the difficult problem here, and it a leap-frogging issue. Let's say that I actually have the time each weekend to wade through hundreds of messages to find out what's going on, and it turns out that as of that Wednesday, things looked pretty solid on the STABLE branch. But now, it's Saturday morning, and other problems have cropped up on Thursday and Friday. Now what? There's no "branch" or "label" that I can go back to, to get the most stable STABLE from Wednesday. STABLE seems to be constantly cycling between stable-sorta stable-not stable-maybe stable-hopefully stable. 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?). Had there been an not-too-painful incremental upgrade process, I'd probably be more current now. But since I'm NOT an expert like so many people here, the warnings about problems with upgrading a system rather than building a new one, scare me. I have only one system that I depend on for my firewall/NATD. It's an old P200 system and I don't have the same parts (drive sizes, two NIC's, SCSI adapters, etc.) to build a test system. Nor do I really have the funds to do that. 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. I've already tried to install 4.3 with the ISO image. I've wasted 2-3 weekends already. I'm at the point where, although the system installation, booting from floppies doesn't seem to have a problem reading the old IDE CD-Rom that I have, it couldn't actually finish using it for the rest of the install. It shows up in the boot DMESG devices but it's not usable. OK, so I put in a SCSI drive. Again, another problem. I was hoping to boot from the ISO image. But the Tyan Tomcat I & 1542CP does something weird like making it the A: drive since it's El Torito and I couldn't get FreeBSD to boot. I have a BIOS option to boot from SCSI first, that if that's the CD-ROM, it get's weird. Fine. Made the boot/root floppies from the CD. Got into the install, CD seems to be recognized by the boot process, but later it just tells me I have no CD. At that point I just had to give up due to time constraints. I haven't yet explored every possible combination ( 256 according to my calculations ;) and I haven't wanted to bother the group with some dumb thing I could probably figure out if I had enough time. While a "turnkey" system would be nice, I'm certainly willing to check out a web page or something that points me to a current "patch list" that tells me how critical the patch is and lets me get specific security patches AND recent system updates, at a certain level/date. Right now, any CVSUP I do to STABLE seems like it's always on the bleeding edge and by it's very nature, will always lag behind the problem reports on the list. It's extraordinarily time consuming to hunt through hundreds of messages on the STABLE list to figure out the exact moment that I can CVSUP and have a minimum of problems. I guess this is mostly because it's all volunteers, BUT, I have to agree with one of the earlier posters in this thread, that maybe, just MAYBE, it's possible to have some coordination mechanism or procedures for the commiters, etc. to keep STABLE just that. Stable. 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. Yes, it's all in the handbook/FAQ, etc. but again, it's not all complete and not always up-to-date. If I understand CVSUP, it seems like it's OUTSIDE core FreeBSD and not an integral part of it. It's also easy to jump on people for the absolute letter of what they say and pick that apart instead of actually listening to the IDEAS that they are trying to get across. Many people "seem" to talk in absolutes when they really mean shades of gray. Don't jump all over someone who says "X always does Y", and start a "fight" about the "always" and totally miss the point the poster is trying to make. What if I had said "People talk in absolute ...". Why waste time trying to refute that when, I think, many people can see that as "Many/Most/A lot/Some people ...", etc. I think that there seems to be lots of wasted time "fighting" over semantics and not content. 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. What about having just a few STABLE snapshots that have been found to be relatively OK. Maybe some generic label like STABLE-2 & STABLE -4. One would be at the most stable level of 2 weeks ago and one could be 4 weeks ago, except minus the latest security patches. I'm sure everyone will jump on me and tell me why it can't be done and why it's always been done this way. But those kinds of attacks to encourage people to think "outside of the box". Maybe some of the ideas presented here actually do have some kernel of usability. But it's never possible to see it if it's always going to be shouted done. As an outsider, it seems like a lot of people are very heavily invested in the traditions and doing things a certain way. Maybe that's why FreeBSD doesn't seem like a good, solid stable bet for Corporate America. We all know just how much better FreeBSD is than Linux. And yet, it's now the little darling of Corporate America? Wait until they find out just how dirty it's diapers are. 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 in it's open-source, anti-commercial positions that it completely eschews all industry "best practices" for delivering and maintaining a first class product? It's got HUGE potential to be THE NUMBER ONE open-source UNIX for the rest of us. But not if you have hundreds of egos clashing with each other. I now return you to your regularly scheduled list feed. Enjoy, Mark At 04:55 PM 6/22/01, Joe Kelsey wrote: >Jason Watkins writes: > > >>> If the problem is instead that STABLE isn't STABLE enough and RELENG > > doesn't move fast enough - though evidence for the latter would also > > seem to be in short supply - then one of those two problems should be > > attacked, rather than trying to automate something that experience > > shows doesn't automate well. > > > > Thanks mike. I didn't mean to criticise anyone, I just mean that the root > > problem here is -stable isn't always stable. > >Sorry Jason. Adding another tag is *never* going to solve your >imaginary problem. I say imaginary because it really is not a problem. >The people who complain are always people who have an "automatic >midnight cvsup" or some other regular procedure that they run without >thinking first. As the handbook says, you *must* track the stable >mailing list before even thinking about running cvsup against the >appropriate tag. Adding a new tag will simply move the problem to those >people who still don't read the mailing list or even try to engage their >brains before running cvsup. > >This is an organization of *volunteers*. It is up to each and every >individual who wants to run FreeBSD to understand the consequences of >their actions before starting. I would personally recommend that >most people stay away from FreeBSD. It is definitely *not* a turnkey >system. Anyone who has an automatic cvsup and rebuild overnight is just >asking for trouble. > > > Although adding another tag would provide another buffer layer, I > > personally feel it's missing the point. Somewhere, someone has to > > approve moving things from -current to -stable, and figuring out how > > to better equip those people is what I think would bring about the > > best situation. > >Have you ever looked into the committers list? It is simply not >possible for there to be any central control over checkins as you >describe. The number of projects and people is simply overwhelming. > >The way to better equip people is to force them to read the handbook. >The way to force them to read the handbook is for them to get surprised >by their unthinking actions. FreeBSD is not for tyros. > > > I definately think life is easyer when you rebuild the system every > > month or 2 on a reasonable schedual instead of letting changes > > accumulate until it becomes a day long affair. > >I personally think it does not matter how often you cvsup and rebuild. >Sometimes, I go for months, sometimes I do it daily. It all depends. >If you have any thoughts of running cvsup at all, you need to have a >fast connection. It is definitely not for dialup users. Maybe that >should go in the handbook--only do it if you have DSL or cable modem or >better. > >My basic point is that it is not possible to "schedule" the activity in >advance due to the changing nature of the source tree. You have to >constantly monitor the mailing list and make your own decision based on >mailing list traffic. > >/Joe > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-stable" in the body of the message 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?4.3.2.7.2.20010623150807.034a09a0>