Very useful. Thank you very much. Regards, Mahmood
________________________________ From: David Sommerseth <[email protected]> To: Mahmood Naderan <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Friday, February 15, 2013 4:53 PM Subject: Re: Lokking for stable linux 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
