[Asterisk-Users] Re: RHL/FC releases v. RHEL releases -- WAS: SATA hard disk compatibility

[Bryan J. Smith]

Assaf Flatto <assaf at atelis.net> wrote:
> Fedora core stable version now is FC4

Actually, it's FC5.

Fedora Core (FC) 2 and 4 radically changed the GCC/GLibC versions (as
well as the kernel in the case of 2).  FC 3 and 5 were largely
revisions of the former, respectively.

> (which is to say Red hat 10 version 4 or even Red Hat 11 if
> we count in the old way RH did ).

If feel you must relate versions, it's best to track them by
releases, here is how FC/RHL map to Red Hat Enterprise Linux (RHEL)
...

RHL 6.2 "E" (the "first" w/Service Level Agreements, SLAs)
- Based on:  RHL 6.0 -> 6.1 -> 6.2

RHAS 2.1 (later relabeled RHEL 2[.1])
- Based on:  RHL 7 -> RHL 7.1 -> RHL 7.2
- Also:  RHL7.3 (released after RHAS 2.1)

RHEL 3
- Based on:  RHL 8.0 -> RHL 9
- Also:  FC1 (released after RHEL 3)

RHEL 4
- Based on:  FC 2 -> FC 3

RHEL 5 (by all estimates ...)
- Based on:  FC 4 -> FC 5

Red Hat started its original .0 -> .1 -> .2 release model with Red
Hat Linux (RHL) 4.0.  It stopped differentiating after RHL 7.3.  With
exception of FC 1 (with added 2 months (8 months total) in the
trademark and other review (such as removing a lot of dependency hell
and security issues, long story), Red Hat maintained its 6 month
release cycle within 2-3 weeks through FC 3.  FC 4 and FC 5 took
betwen 8-9 months to release.

This 6 month release cycle is actually a 2 -> 2 -> 2 month cycle
formerly known as Red Hat Rawhide -> Beta -> Release, now known
formally as Fedora Development -> Test -> Core (although most Red Hat
developers still call "Development" the original label, "Rawhide"). 
The 18 month RHEL release cycle comes after 2-3 RHL/FC revisions.

The earlier you adopt a "major change," the more issues you'll run
into with maturity, compatibility (which is where 90% of the problem
is -- Red Hat "pushes the envelope early" and forces everyone to
adopt newer API changes).  The more you "hold off" on latter
releases, or RHEL, the less issues you'll have with existing code --
although you might not be able to run the latest stuff.

That's why FC is recommended when you're running newer software --
more "leading edge."  RHEL is recommended when you're running
established software -- more "trailing edge" (which also makes SLAs
possible and supportable for Red Hat).  Some people go "in between"
-- avoiding certain FC releases (just like RHL releases prior).

E.g., I avoided RHL5.0, 6.0, 7.0, 8.0, FC2 and FC4.  I didn't upgrade
until 5.1, 6.1, 7.1, 9, FC3 and, most recently, FC5 came out.  In
other words, I waited for "+1 release" after a major GCC/GLibC
change.

> As John suggested CentOs is a good idea to use,

Agreed.  CentOS is virtually a 1:1 rebuild of RHEL, because Red Hat
releases _all_ of its work in Source RPM (.src.rpm aka SRPMS)
packages unlike many other vendors (e.g., SuSE for SuSE Linux
Enterprise Server or Novell Linux Desktop).  CentOS is a great choice
when you don't want to pay for a SLA.  But it comes with all the same
pros/cons of "trailing edge" Red Hat.

> however there are some well documented problems with the zaptel
> ( that is if you are using digium hardware ) compilation ,but all
> in all it shouldn't be a problem.

On which CentOS release?
CentOS 3?  CentOS 4?

CentOS 3 has the same GCC/GLibC as RHL9.
CentOS 4 has the same GCC/GLibC as FC3.

If it's built for FC4+, then yes, CentOS is not ideal ... yet.
You'll have to wait for CentOS 5, or consider FC5.

You do _not_ want to run FC4 -- FC5 is typically far, far better.
Just like FC3 was over FC2 for the most part.


-- 
Bryan J. Smith            Professional, Technical Annoyance
b.j.smith at ieee.org             http://thebs413.blogspot.com
-----------------------------------------------------------
Americans don't get upset because citizens in some foreign
nations can burn the American flag -- Americans get upset
because citizens in those same nations can't burn their own