<p dir="ltr">RHEL uses a "point in time" model for each release. So that is a stock 2.6.32 kernel with 500+ patches applied. Each patch is a backport from a later kernel that is a security or bug fix. As a rule, no feature changes are applied like scheduler, etc. They will backport support for newer hardware.</p>
<p dir="ltr">They do the same thing with glibc, gcc, etc.</p>
<p dir="ltr">The way to understand this is to consider you have a mission critical application that runs well on centos 6. The application will get updated, rereleased, etc. over time. But for now, it works well on this release. By using this model, the updates needed for security and bugs will have little to no impact on the mission critical application. However, if you use a <a href="http://kernel.org">kernel.org</a> version, each change is a hodgepodge of feature changes as well as as what you need.</p>
<p dir="ltr">When it's time for a major upgrade to your applications, you build a new machine running the latest and greatest version of RHEL. The old hardware is still running the old version until the plug is pulled and the hardware is repurposed or recycled (into development machines).</p>
<p dir="ltr">Since each RHEL release overlaps the support time for prior releases, there's time to have dual systems running if needed. There's also no big rush for a major upgrade as the bug and security patches will keep flowing.</p>
<p dir="ltr">So getting 10 years of use from a mission critical application release that cost a zillion dollars to launch is the driving factor for the process.</p>
<p dir="ltr">From an admin standpoint, breaking systems into release clusters is easy. It also works well for devops. For advanced access, put devels on Fedora and upgrade daily. It forces them to write broader rather than rely on hyper-tight versions. </p>
<p dir="ltr">Over the years, the running joke was "RedHat x.2" was the rock solid version. With RHEL, it's become x.1 . Once a new version arrives, the later updates to the prior release may include optional preview and/or transitional code. It's still the same base kernel, libs, compiler, but other stuff may begin to include feature changes. So 6.6 requires some extra reading of update notices.</p>
<div class="gmail_quote">On May 20, 2015 9:29 AM, "DJ-Pfulio" <<a href="mailto:DJPfulio@jdpfu.com">DJPfulio@jdpfu.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm new to CentOS. Last time I used Redhat was around 2000-2002-ish. Been a<br>
Unix and Linux admin since the mid-1990s. Installed a CentOS 6.6 minimal server<br>
this week, did a yum upgrade and rebooted.<br>
<br>
The kernel is like - 40 yrs old - is that normal or RHEL/CENT?<br>
<br>
$ uname -a<br>
Linux cent18 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 UTC 2015<br>
x86_64 x86_64 x86_64 GNU/Linux<br>
<br>
<br>
I've been having fun learning the redhat ways of doing things the last few days.<br>
Fun, fun.<br>
<br>
So - do I just need to reset expectations for using a 3.x kernel?<br>
<br>
<br>
--<br>
Got Linux? Used on smartphones, tablets, desktop computers, media centers, and<br>
servers by kids, Moms, Dads, grandparents and IT professionals.<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>