Date: Thu, 21 Jul 2005 11:02:49 -0700 From: "Alexey Yakimovich" <aiy@ferens.net> To: "'Robert Watson'" <rwatson@FreeBSD.org>, "'Marc Olzheim'" <marcolz@stack.nl> Cc: freebsd-stable@FreeBSD.org Subject: RE: Quality of FreeBSD Message-ID: <200507211803.j6LI34dV005050@ferens.net> In-Reply-To: <20050721125632.F97888@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
First of all thank you very much all for your replies. I just want to add some comments based on previous mails. - I completely agree with MikeM - any kind of complex software could be tested with right prepared test cases, specially if they are going to be reused in the next release; - if those problems happened to 5 branch, probably it would happened = again for 6 or 7, so why I have to switch to 6 right now? Is it because 5 will never be fixed? Does word "production" mean something to FreeBSD project now?=20 - I remember some time ago you can stay on current all the time not = worrying that your box is crashed and didn't auto rebooted; - chip hardware was always in use by FreeBSD, as far as I remember, or something is changed recently, specially to US, and people buying only expensive hardware. Probably it is no longer important to support chip hardware because of more important FreeBSD clients like Yahoo or Apple = use real hardware, not the stupid one like ATA and they have these = "aggressive" project schedules. Believe me I know what "aggressive" project schedule means, with long, long list of new features. It is important for such companies like Yahoo only and I know why, because it's easy to sell = useless product with lots of new features than stable product with few ones. For regular guy better to have some stable system running all the time and = doing real work (development or providing some service) than rebooting the = box, because of some new fancy feature. It's getting close to Windows right = now. - IBM, Yahoo, Intel, Apple ..., those guys are smart, having millions of unpaid open source developers working on them. The problem is that some = day those projects will have theirs "aggressive" project schedules, then = will disappeared or changed to .com. So make sure you are still doing what = you like to do and you are having a fun of it. Thanks, Alexey > -----Original Message----- > From: Robert Watson [mailto:rwatson@FreeBSD.org]=20 > Sent: Thursday, July 21, 2005 5:21 AM > To: Marc Olzheim > Cc: Alexey Yakimovich; freebsd-stable@FreeBSD.org > Subject: Re: Quality of FreeBSD >=20 >=20 > On Thu, 21 Jul 2005, Marc Olzheim wrote: >=20 > > Indeed. That's why my company started taking FreeBSD 5.3 in use for=20 > > production servers when it was out. Since then numerous=20 > bugs were fixed,=20 > > some of which reported by us. Now that we're X bug fixes=20 > later in time=20 > > and started to get a good feeling about the number of open=20 > problems, it=20 > > is extremely annoying to hear the "This will (probably) not=20 > be fixed in=20 > > 5.x" statements. That conflicts with 'gradually get=20 > resolved'. What do=20 > > you recommend larger consumers to do ? Keep using FreeBSD 4=20 > and start=20 > > testing FreeBSD 6.x, dropping 5.x all together ? > > > > I know FreeBSD 5 was a strange exception in the relase=20 > scheduling and=20 > > that a lot has been learned from it for the future and I'm=20 > certainly not=20 > > unthankful for all the work that's done, but I'd like a=20 > clear answer on=20 > > what to do now in regard to taking FreeBSD 5 into 'real'=20 > production... >=20 > Marc, >=20 > I should start out by saying I appreciate your clear and concise bug=20 > reports, and the list of your company's show-stopper 5.x bugs=20 > has made the=20 > rounds among FreeBSD developers. I'm happy that at least one of the=20 > issues on the list was fixed by me. :-) As you probably saw=20 > yesterday,=20 > I've started bugging Poul-Henning to look at the pty problem you're=20 > experiencing, and will get that on our 6.0 release=20 > show-stopper list. I=20 > haven't yet had a chance to reproduce it locally, but it=20 > sounds like that=20 > should be straight forward. >=20 > FreeBSD 5 has been an exception -- "normally", in as much as major=20 > releases have a "normal", the set of new features is a lot=20 > less agressive,=20 > and it has been our goal with 6.x to restore the expectation=20 > of a more=20 > rapid release cycle with a less agressive feature set. This=20 > should reduce=20 > the number of problems by virtue of reducing the level of change. It=20 > should also make it easier for users to pick what version to=20 > run on, as=20 > the amount of adaptation they have to do to slide forward a=20 > version will=20 > be greatly reduced. I.e., right now it's relatively easy to=20 > move back and=20 > forward between 5.x and 6.x. >=20 > With respect to 5.x vs 6.x upgrades: I've seen companies take two=20 > different strategies. Most of them have been at least=20 > experimenting with=20 > deploying 5.x, and are very interested in its feature set. =20 > Support for=20 > large file systems, 64-bit support on newer AMD and Intel hardware,=20 > improved PAM support, etc. Some of my customers are specifically=20 > interested in the support for mandatory access control, but that's=20 > obviously a less common feature request :-). The biggest determining=20 > factor for companies today comes from their own product=20 > schedule, since=20 > most big consumers of FreeBSD treat it as a component in a=20 > "product" they=20 > deliver for others. >=20 > For example, my understanding is that Yahoo is now deploying=20 > 6.0 betas=20 > across their server environment with great success, but was actually=20 > unable to seriously deploy 5.x because their goal was to support full=20 > 32-bit compatibility on 64-bit amd/intel hardware, which has=20 > only recently=20 > reached the level of maturity they require. In fact, you'll=20 > notice if you=20 > follow FreeBSD commit logs that much of that support has come=20 > from Yahoo!.=20 > Since 6.x is maturing in pretty good synch with their=20 > deployment timeline=20 > for 5.x, they are actually deploying 6.x. Of course, Yahoo!=20 > has a team of=20 > in-house OS developers who adapt FreeBSD for their needs, and=20 > is quite=20 > capable of debugging a kernel or two if they run into problems. >=20 > The ATA driver issue is a sticky one for many users -- we=20 > hope to get the=20 > 6.x ATA code back into 5.x in the next 5.x release. However,=20 > hard-earned=20 > experience tells us that ATA driver code is notoriously=20 > difficult to get=20 > right across the broad range of available hardware. Soren has been=20 > lobbying to get it merged to 5.x, but given the level of=20 > testing performed=20 > so far, we can't yet justify the merge. My hope is that with=20 > 6.0 out the=20 > door and a lot of testing of that code, we can get it merged=20 > back to 5.x=20 > before 5.5. Many other fixes have gone into 5.x, correcting=20 > many of the=20 > most significant issues. If you compare 5.4 with 5.3, you'll=20 > find that in=20 > most cases, it's both faster and more stable. >=20 > The tty issue is a sticky one also. The tty code in 6.x has been=20 > substantially rewritten to better support the SMPng=20 > environment. Because=20 > the tty code "plugs in" to a number of device drivers, T1=20 > adapter drivers,=20 > etc, changing the tty interfaces is a fairly big event, and=20 > will affect=20 > third party vendors like Cronyx. This code has also not yet=20 > seen as wide=20 > deployment as I'd like, so it's also something that really isn't=20 > appropriate for an MFC immediately. However, once it has=20 > seen significant=20 > 6.0 deployment, it may well be. A question then will be whether it's=20 > better to simply say "you're better off making the jump to=20 > 6.x, which is=20 > minor" than backporting, and it's something we can't really=20 > answer until=20 > we're comfortable that it's seen sufficient deployment. My=20 > hope is that=20 > we can identify a workaround for 5.x that will avoid the code=20 > upheaval a=20 > full backport would require. It's not as ideal as having the=20 > "right" fix,=20 > but it would stop the panics. I need to ping phk and some of=20 > the other=20 > tty-centric folk to look at this some more. >=20 > In terms of advice: >=20 > If you have a "product" due out more than 3 months from now,=20 > I think 6.x=20 > is the obvious way to go: you want to be ahead of the curve=20 > so that you=20 > can have the foundation for your product in sync with the FreeBSD=20 > production release cycle, and avoid jumping major releases=20 > early in the=20 > product life cycle. 6.x has significant performance and stability=20 > improvements -- performance especially in the area of file system=20 > performance on SMP, preemption, network stack, and memory=20 > management, and=20 > stability especially in the area of tty support. By=20 > "product", I mean a=20 > range of things: the OS foundation of an embedded product such as a=20 > firewall or storage appliance, or deployment of an internal=20 > product, such=20 > as a virtual server product at an ISP. >=20 > On the other hand, if you're deploying today, I think that=20 > unless you're=20 > prepared to deal with the 6.0 bug fix cycle (both the BETA/RC=20 > cycle, and=20 > the inevitable post-release fixes for a .0 release), 5.4+patches or=20 > 5-STABLE is the right place to sit. At least two of the=20 > critical bugs on=20 > your list were fixed in 5-STABLE after the release of 5.4, so=20 > for some,=20 > 5-STABLE is the best place to be. We've opted not to do a=20 > patch/errata=20 > update for 5.4 for the socket error you were receiving on the=20 > basis that=20 > it doesn't affect a wide audience and doesn't correct a=20 > "Critical" failure=20 > -- i.e., a crash or the like, unlike some of the NFS server=20 > fixes, for=20 > which we did do an errata fix. >=20 > From the perspective of the FreeBSD developers, if you can=20 > tolerate the=20 > 6.x release process, we encourage you to jump on that=20 > bandwagon. It will=20 > help us release a better 6.0, and that's where the future=20 > lies. Our goal=20 > is to make 6.x a pretty seemless upgrade from 5.x, as it has a less=20 > agressive feature set, and far fewer user-visible changes (i.e., no=20 > conversion to OpenPAM, devfs,=A0UFS2, large compiler version=20 > upgrade, ... as=20 > in 5.x). When I upgraded my personal web/shell server to 6.x=20 > from 5.x=20 > last week, I didn't have to change any configuration in /etc=20 > at all, other=20 > than a painless pass through mergemaster to merge the _dhcp user and=20 > group. As always, we look to the freebsd-stable users to=20 > help us test new=20 > features ahead of the release. >=20 > Thanks, >=20 > Robert N M Watson >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507211803.j6LI34dV005050>