Date: Sun, 8 Jun 2008 13:49:35 +0200 From: "Andy Kosela" <andy.kosela@gmail.com> To: freebsd-stable@freebsd.org Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 -- Andy Kosela ora et labora
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2>