Date: Wed, 11 Jun 2008 12:53:02 +0300 From: Anton - Valqk <lists@lozenetz.org> To: Andy Kosela <andy.kosela@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <484FA07E.60103@lozenetz.org> In-Reply-To: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just my 5cents (some thoughts), I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. As mentioned in reply posts the 3 branches 6.X 7.X and 8.X takes too many resources and is very hard to support. I, personally, will be waiting for 7.2 release (noticed that .2 over few (3-4 years)) are most stable ones. My main drama with FreeBSD is that ports don't have -SECURITY patches, and if I there is a bug in php I have to rerbuild and populate the latest version. Another _very important_ thing is that there is no binary support to packages that has vulns, and you have to rebuild them from ports. Just a simple example: I have 4-5 fbsd machines and about 15-20 debian stable machines. To administer fbsd machines when there are ports bugs(bugs in ports I use) it takes me at least about 4times more time than update _all_ debian machines... Well...I have other things to do too, too many... now guess what I will choose? I'll use debian, and that's not because I don't have will to use freebsd, it's simply because I do my tasks 4 times slower than when I choose debian. Someone will say "FreeBSD is not for you, then back off". That's not the point, I like fbsd, but as more busy I get, as less I'll be able to use it, takes too much of my time. Once I've told that there is no binary support (but I didn't expressed myself correctly). There is no ports VULNS binary support. If there is (and I've never heard of it), I'll be very happy someone to point me out this, because I'll continue running fbsd. Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... in linux (debian for me) there is xen that works with 'new' intel hardware virtualization, that's another red point for debian.... there are other things that I'll leave unsaid....so... that's all for now. sorry for my bad english, it's not my native. these are just my thoughts and don't want to force anyone to agree with them, but I'll be happy to read your thoughts on this. cheers, valqk. Andy Kosela wrote: > On 6/8/08, Freddie Cash <fjwcash at gmail.com> wrote: > >>> On 6/7/08, Jo Rhett <jrhett at netconsonance.com> wrote: >>> The question I raised is simply: given the number of bugs opened and >>> fixed since 6.3-RELEASE shipped, why is 6.3 the only supported >>> version? Why does it make sense for FreeBSD to stop supporting a >>> stable version and force people to choose between two different >>> unstable versions? Is this really the right thing to do? >>> >> Define the terms "stable" and "unstable", how you measure said >> "stability" and "instability", and what you are comparing them >> against. >> > > This whole discussion is really interesting as it clearly showcases two > common trends in computing (rapid development vs stability) On the one > side we got people (let's call them developers or computer scientists) > who are more interested in development than stabilization of the existing > code base. It's natural for them to think more about new features, > researching new ideas and implementing them. It resembles an > academic project, research project.Those computer scientists do not > care much about stability, they are mainly interested in hacking on the > code for the fun of it. It is open source after all as someone wisely > remarked. From my own experience most if not all community based > projects are more interested in following this trend than stabilization of > the code. Although they do care about stability of their code base, their > focus is more on implementing new features and moving rapidly forward. > In today's quickly changing world we see this trend as prevailing. > > On the other hand though, there is a trend which focuses on maximum > long term stabilization of the code base. Usually we see this trend in high > end commercial companies serving the needs of mission critical > businesses where even a minute of downtime can cause loss of > thousands of dollars or even loss of lives of people (imagine stock > exchanges, banks, financial & insurance institutions, army and police > facilities, hospitals, nuclear plants etc.). Those types of > businesses/institutions truly needs a maximum stable operating system. > They really do not care about "new features", but they do care about > maximum stability of the existing code, security, and nonstop business > continuity even in the face of natural disasters. There is only one operating > system I know of that survived 9/11 attacks - this is OpenVMS. > It's not uncommon to see VMS uptimes of more than 10 years (you can ask > Amsterdam police for evidence). Now that is a true stability! On the other > note though, stability is the direct opposition of development and change. > Something which is *stable* cannot change or must change very slowly in > the long term. On the other hand something which is changing rapidly cannot > by the very definition of it be stable but rather is...unstable. Plato said it > very wisely in Timaeus: "What is that which always is and has no becoming; > and what is that which is always becoming and never is?". In other words > one could say - what is that which is always the same and stable and what > is that which is always changing and is unstable? This elaborate thinking > is directly connected even with the trends in todays computing. When the > code base is changing rapidly and quickly you cannot say it's very stable. > Something stable is always something heavy tested and unchanging. > > So on the one hand we got users like Jo who wants long term stabilization, > who depends on FreeBSD to run their mission critical systems, and on the > other the developers who are more interested in the *development* than > maintaining and supporting older releases for many years. I got to agree > with the developers -this is open source project with limited resources. In > order to offer long term support the whole focus of the project would have > to be changed - and you can't force people to do something they don't want > to do in the open source world. > It's more fun to work on implementing new code, than squashing bugs or > fanatically audit the code in search of security flaws in old releases. The > open source is moving very rapidly forward and it's not only FreeBSD. Look > at Linux. There is more than 10,000 messages each month on LKML. > Kernel.org peoples also do not care much about stability (recent problems > with vanilla kernels do support my thesis) - they commit so fast and massively > that it becomes real hard to maintain this "beast" even for seasoned hackers. > But someone who is sane will not be using kernel.org kernels in mission critical > production environments but rather commercial distro kernels like Red Hat's > versions. Also they won't be using 8-CURRENT on production systems either. > Those are more research projects than operating environments for data > centers. But when Red Hat is taking kernel.org kernel and put it out as part > of their distro they give 7 (read: seven) years support for that particular > kernel, userland and any third party application they support. They backport > all security and bug fixes to the "so called" stable release during those seven > years. That is a long time in the open source world, as in the general > computing world. They can do this because they have resources for > that - they are operating as a commercial company. > > In FreeBSD even if you upgraded cleanly base system (this is very easy > and fast now with freebsd-update(8)) there is always problem with ports. > I'm perfectly aware that developers are more focused on the base system > and ports are served on "as is" basis but most of the production systems > deployed worldwide are using ports and depends on them most of their time. > I also understand ports team in saying that there is no resources to have > many branches of ports tree at the same time, but this little example will > show that in the long term sometimes things are not working very smoothly > for people who are running mission critical systems. Let's say some > hypothetical 6.x-RELEASE comes out in January. The Apache port is > freezed at hypothetical 2.0.40 version. Now in April someone discloses > some very critical security flaw which affects all versions of Apache prior > to 2.0.43. Now what you can do? You can update your Apache port to > 2.0.43 fixing a security hole. But at the same time you don't know the > upstream team changed dramatically some internal things in code, added > tons of new features and at the same time introduced a ton of new bugs > and possibly new security flaws which will be founded at a later time. > Those changes in code can also very well break your applications which > depended on the specific code in 2.0.40 version. So you are left with > headaches and backup tapes (of course you would first test the upgrade > process on the test machines). But my issue here is that ports really do > not offer real stability for mission critical systems who often depends for > years on specific versions of particular software (like banks). Red Hat in > that case backports new security patches to those old stable versions and > it seems it is some solution for such businesses. Of course I know there is > no resources for creating supported -SECURITY branch of ports tree which > would backport those patches. > > FreeBSD has always been known for its legendary stability and mature > code base which is why many commercial companies depend on it every > day. "The anomaly" as someone said of long term support for 4.x releases > only helped to see FreeBSD as more stable and viable solution than Linux by > many businesses. Mission critical systems needs long term support (read: at > least backporting security patches) and stable systems that can run for years > without interruption. When it comes to stability vs development maybe there is > time to rethink FreeBSD overall strategy and goals. Major companies using > FreeBSD in their infrastructure like Yahoo! or Juniper Networks would > definetly benefit from such moves focused on long term support of stable > releases. I honestly think it is in their interest to support, even financially > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?484FA07E.60103>