The enterprise OS is a different beast from the cutting edge newhotness stuff. RHEL backports the security fixes from bleeding edge release to the tried and true version they ship. So the version (API and feature list) may be 2.1.2, there's a different number after a dash that covers the patch level. For that understanding, one must read the security docs, knowlegebase RHSAs or get the src.rpm and read the patch list.<br>
<br>-or-<br><br>take the overworked admin way and update the tool using the OS approved method. It will generally not break things like a Java upgrade does. When the machine to admin ratio hits above 200:1, admins generally use the OS tools for sanity reasons. When the user count is over 1k, admins are generally not going to use tarball installs with./configure, make, make install dances.<br>
<br>BTW: php-5.3 ships with RHEL5 in a package called php53 (and assorted friends).<br><br><div class="gmail_quote">On Wed, May 9, 2012 at 8:12 AM, leam hall <span dir="ltr"><<a href="mailto:leamhall@gmail.com" target="_blank">leamhall@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">JD's point is valid, the Enterprise OS versions are literally years<br>
behind. For example, the current Python on RHEL 5 is 2.4.3, Perl is<br>
5.8.8, and PHP is 5.1.6. You also get their bundled compile time<br>
options which may not be what you want.<br>
<br>
However, it is a matter of time management. if you're building an<br>
application that works with the OS tools, then you can spend more time<br>
developing. For RHEL, they packport security fixes but keep the same<br>
major versions intact just for this reason.<br>
<br>
If you business case works for keeping up with security patches and<br>
stuff yourself, then you might as well take the freedom of custom<br>
compiling and module management too.<br>
<br>
Leam<br>
<div class="HOEnZb"><div class="h5"><br>
On 5/9/12, JD <<a href="mailto:jdp@algoloma.com">jdp@algoloma.com</a>> wrote:<br>
> On 05/09/2012 06:07 AM, Leam Hall wrote:<br>
>> On 05/08/2012 08:48 PM, JD wrote:<br>
>><br>
>>> BTW, using RVM is a great idea. NEVER use the OS perl, python, php or<br>
>>> ruby<br>
>>> installs for non-OS purposes. That just beings dependency problems at<br>
>>> every<br>
>>> upgrade, unless you can use the package system for the apps (redmine)<br>
>>> too.<br>
>><br>
>> I will disagree with this from an enterprise perspective. If you use the<br>
>> OS version then you are letting the OS team maintain security<br>
>> vulnerability remediations. If your application can't handle an upgrade<br>
>> you probably need to find a better application.<br>
>><br>
>> The other side of that is if you are happy to spend your time<br>
>> recompiling and distributing your application every time software you<br>
>> depend on comes out. For Java that would be about 4-6 times a year. Not<br>
>> as often for the others.<br>
>><br>
>> It really depends on where you want to spend your time.<br>
><br>
><br>
> OS patch levels are often months, if not years, behind. Package managed<br>
> perl<br>
> and ruby are. Those OS patched versions would be "downgrades", not<br>
> upgrades.<br>
> The only way to stay up to date is with RVM and PerlBrew getting patches<br>
> directly from current gem and CPAN repos.<br>
><br>
> Java might be a different animal. We avoid it. Got burned too many times<br>
> with an<br>
> app that always broke after every java version update. That app had been out<br>
> of<br>
> development for a while.<br>
><br>
> For me, this is about time management. Troubleshooting issues caused by 2<br>
> yr<br>
> old perl modules from the OS vendor sucks. I'm not suggesting that every<br>
> system<br>
> needs a special version of perl or ruby or python. I'm suggesting that when<br>
> the<br>
> primary application on a server is perl, ruby, or python, then the<br>
> application,<br>
> not some OS vendor, needs to control the patching for perl used by that<br>
> application.<br>
> As an OS release becomes more mature, often they only maintain an older<br>
> version<br>
> of the scripting interpreters. Apps under constant development need newer<br>
> release tools and compatible modules/libraries.<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>
><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Mind on a Mission <<a href="http://leamhall.blogspot.com/" target="_blank">http://leamhall.blogspot.com/</a>><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br><br>As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as
they please, and those who survive will be left to contemplate the
outcome.<br>- <i><i><i><i>2011 Noam Chomsky<br><br><a href="http://heretothereideas.blogspot.com/" target="_blank">http://heretothereideas.blogspot.com/</a><br></i></i></i></i><br>