Re: [squid-users] CentOS 4.3 and Squid Version

From: Domingos Parra Novo <[email protected]>
Date: Wed, 26 Jul 2006 16:03:50 -0300

        Hiyas,

Brad Taylor escreveu:
> I'm getting ready to put 3 Squid reverse proxy servers into production
> and I'm looking for the best distro do to this with and the best way to
> maintain Squid updates. I'm familiar with CentOS 4.3 and would like to
> use that distro but found that Squid 2.5 STABLE6 is the latest version
> for CentOS 4.3. Any reason why such a popular program like Squid would
> not be updated for CentOS (Red Hat Clone)? I prefer to use up2date or
> yum to update packages. Anyone have any suggestions for me?

        Like you said, CentOS is a RedHat "Clone". To be more exact, it simply
gets the source RPM packages from the RH enterprise distros, and
recompile it (modifying only what is strictly needed).

        So, it could be considered an enterprise linux distro (without
commercial support, that is), updating packages and fixing stuff only
when RedHat does the same on RHEL. This means that all policies
regarding this distro (packaging, updating, bug fixes and security bug
fixes) takes in account that the product is targeted to an "enterprise
client" (thats the most important phrase in my message).

        For a long time, "enterprise clients" asked for an enterprise linux
(and there where none). RedHat was the first to fix this issue, building
an enterprise version of its Linux (called RHEL). By enterprise, they
meant an operational system which was stable, scalable, well supported
and with a distant EOL date. So, the paradigm for this kind of distro is
way different from the ones end users and small companies use. We can
sum the basic changes in a few lines:

- The life cicle of an enterprise distro is way longer then a normal
distro. To get the picture, just compare the EOL date of any Fedora Core
version, with any version of Solaris, or even better, Windows. For the
matter, Windows 98 finally ended its "cicle of life" (EOL) this month.
RHEL usually have a EOL date of 5 years from the date it was launched
(and even more, if the marked asks for it).

- The enterprise distro is not meant to be bleeding edge. Alas, no
software is upgraded to the latest version. In truth, developers do the
most they can to stay using the same version of any package or lib for
the lifecycle of the product. We can break this statement in two parts:

        - package updates are made only when security bug fixed are found.
Also, the package is not updated to a newer version, but instead, the
fix is backported to the current version. If you take a look at RHEL
4.x, you'll see that it contains thousands of packages. To stay "feature
freeze", you must guarantee that all packages are 100% compatible betwen
updates (try to do an automatic update of squid 2.5-stable6 to squid
2.6-stable1, and see if works at all).

        - developers take much more care about updates, and usually, stay away
from "functionality" fixes (unless the bug makes the software useless).
So, the number of package updates ir far greater on end user distros,
when comparing to enterprise distros. Also, those updates are usually
delivered in batches (think of Microsoft service packs. RedHat does the
same with RHEL).

        Finally, on RHEL 4, squid 2.5-stable6 is not really the "stock" squid
2.5-stable6. The latest RPM package contains dozens of patches, fixing
any know security bug for this version, and a handfull of feature fixes.

        For an stable and secure (enterprise) environment, I'd recomend all
users to stay with the vendor's packaging and updatind, and let the
administrator deal with other tasks.

OB: I've worked at Conectiva, which was a former member of the United
Linux Consortium (another flavor of a boxed Enterprise Linux). It was
even one of the few distros "recomended" to run Oracle 9i. So, I didn't
"invent" anything. This just what the commercial distros do, when
building an Enterprise product (for enterprise clients).

Regards,

Domingos.

-- 
Domingos Parra Novo
Coordenador de Projetos
Terra Networks Brasil S/A
Received on Wed Jul 26 2006 - 13:04:08 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Aug 01 2006 - 12:00:02 MDT