[ale] OT: ruby/redmine/apache

[JD]

On 05/09/2012 06:07 AM, Leam Hall wrote:
> On 05/08/2012 08:48 PM, JD wrote:
> 
>> BTW, using RVM is a great idea. NEVER use the OS perl, python, php or ruby
>> installs for non-OS purposes. That just beings dependency problems at every
>> upgrade, unless you can use the package system for the apps (redmine) too.
> 
> I will disagree with this from an enterprise perspective. If you use the 
> OS version then you are letting the OS team maintain security 
> vulnerability remediations. If your application can't handle an upgrade 
> you probably need to find a better application.
> 
> The other side of that is if you are happy to spend your time 
> recompiling and distributing your application every time software you 
> depend on comes out. For Java that would be about 4-6 times a year. Not 
> as often for the others.
> 
> It really depends on where you want to spend your time.


OS patch levels are often months, if not years, behind.  Package managed perl
and ruby are.  Those OS patched versions would be "downgrades", not upgrades.
The only way to stay up to date is with RVM and PerlBrew getting patches
directly from current gem and CPAN repos.

Java might be a different animal. We avoid it. Got burned too many times with an
app that always broke after every java version update. That app had been out of
development for a while.

For me, this is about time management.  Troubleshooting issues caused by 2 yr
old perl modules from the OS vendor sucks.  I'm not suggesting that every system
needs a special version of perl or ruby or python. I'm suggesting that when the
primary application on a server is perl, ruby, or python, then the application,
not some OS vendor, needs to control the patching for perl used by that
application.
As an OS release becomes more mature, often they only maintain an older version
of the scripting interpreters. Apps under constant development need newer
release tools and compatible modules/libraries.