On 14/02/13 20:15, Mahmood Naderan wrote:
> Dear all,
> I am looking for a good long stable Linux distribution for servers.
> Currently we have ubuntu 12.04 with users that need wide services. Here
> are the main list of request.
> 
> Kernel > 3.0 (2011)
> 
> GCC/G++ 4.1 (2007)
> GCC/G++ 4.4 (2009)
> GCC/G++ 4.6 (2011)
> 
> libstdc++5 and 6
> 

Just summarizing some of the earlier posts and adding a few more comments.

Don't look blindly at the version numbers.  With Enterprise Linux
distributions, the game is very different from bleeding edge Linux
distributions such as Ubuntu.

With Enterprise Linux distributions, I'm primarily considering Red Hat
Enterprise Linux (RHEL), Novel SuSE Linux and I'm also putting Debian
into this category (even though this one might be more debatable).  The
core feature of these distributions is that they are aiming at long term
support.  And that is usually lasting at least 3 years.  For RHEL the
support lasts for at least 7 years, even up to 10 years.

RHEL uses Fedora as it's playground where new things are tested out
before things stabilises and becomes the foundation of a new RHEL major
release (That is RHEL 4.x, 5.x, 6.x etc).  Novel SuSE Linux uses
openSuSE as their upstream source.  Debian have their own model here,
which I'm not too much familiar with.

You can find more info about the release dates for RHEL here:
<https://access.redhat.com/knowledge/articles/3078>
<https://access.redhat.com/support/policy/updates/errata/>

Then you have distributions like ScientificLinux and CentOS.  Those
distributions are downstream distributions based on RHEL.  And those
distributions follow RHEL very closely.  In fact, they basically take
the RHEL source code, strips out trademarks and such, adds their own
branding.  Then the sources are compiled and released as ScientificLinux
or CentOS.  SL/CentOS developers probably cringe a bit with this
simplification, as they need to do a lot more to actually prepare the
build environments and such.  But from a end-users perspective, this is
generally what happens.  RHEL ships source RPMs, downstream distros pick
them up and recompile them.

One important thing about these distributions: they generally don't move
the packaged versions much forward.  But when new features are needed,
bug fixes or security issues are found, they backport these fixes into
the old versions.  For RHEL which is certified on a grand scale of
hardware and software, it is important to keep the versions and software
as stable as possible for a long time.  Which is why backports happens
instead of pulling in the latest kernel or glibc version, as that would
require a completely new certification round on all certified hardware
and software.  And such certifications are costly and time consuming.

But nobody can accept that RHEL falls behind when new hardware arrives.
 So what happens is that, despite RHEL6 is based on kernel 2.6.32, a lot
of new hardware is made available through backports of newer kernels.
The 2.6.32 kernel in RHEL effectively contains much code from 3.x
kernels, which solves new hardware, bug and security fixes.  And each of
these kernel releases are tested by Red Hat before they shipped.
ScientificLinux picks up the source code from RHEL, compiles it and
ships it in their own distribution.

As an example.  KVM support arrived in an upstreak 2.6.20-something
kernel release.  RHEL5 is based on 2.6.18.  But RHEL5 got KVM support in
the RHEL5.4 release.  That means the whole set of KVM patches were
backported and adopted to 2.6.18 from a newer upstream kernel version,
tested and released.

So, please don't look blindly at the package versions in Enterprise
Linux distributions.  There are more into those versions than you might
think at first glance.

For certified hardware on RHEL, see:
<https://hardware.redhat.com/>

But!  Even though RHEL is certified, that does not mean SL or CentOS are
certified.  As it is the compiled binary code which is certified, and
SL/CentOS only takes the RHEL source code and recompiles it; that breaks
the certification.  For 100% assurance on a fully supported long term
release, there is only one option.  However, you may find that what
works on RHEL works very fine on SL or CentOS too.  But you won't get
the same kind of support from hardware or a third party software vendors
on unsupported distributions.

And the reason Red Hat does all this backporting, is that they do have
paying enterprise customers who wants to be sure that once they install
a system, that system will be fully functional through (minor release)
upgrades, secure and as bug free as possible for the supported period.
If they deploy their own software or software from ISV (like f.ex Oracle
databases, SAP installations, etc), they want to be sure that upgrades
doesn't give them any headaches next week, next year or after the next
update arrives.  And if an issue shows up, that they have access to
people who can help them out ASAP.  And also considering physical server
hardware often have an expected lifetime of 7-10 years, that's why RHEL
have the similar time frame.  You install a new server with a certain
RHEL major version, and it will run stable until you don't need the
hardware any more.

Then it comes to the compiler and library stack.  It is of course very
difficult to move forward on that, without breaking already compiled
binaries, especially system libraries like glibc.  However, this is
where the already mentioned "Red Hat Developer Toolset" comes in.  This
toolset provides gcc 4.7 (iirc) and quite some newer libraries as well.
 And this toolset enables you to compile code requiring these features
and run that compiled code on RHEL installations which does not have the
toolset installed.

You can find more info about the Developer Toolset here:
<https://access.redhat.com/knowledge/docs/Red_Hat_Developer_Toolset/>


I hope this could clarify some of your questions in regards to what a
stable Linux distro is and how it works in a long term perspective.


--
kind regards,

David Sommerseth