[ale] OT: ruby/redmine/apache

[leam hall]

JD's point is valid, the Enterprise OS versions are literally years
behind. For example, the current Python on RHEL 5 is 2.4.3, Perl is
5.8.8, and PHP is 5.1.6. You also get their bundled compile time
options which may not be what you want.

However, it is a matter of time management. if you're building an
application that works with the OS tools, then you can spend more time
developing. For RHEL, they packport security fixes but keep the same
major versions intact just for this reason.

If you business case works for keeping up with security patches and
stuff yourself, then you might as well take the freedom of custom
compiling and module management too.

Leam

On 5/9/12, JD <jdp at algoloma.com> wrote:
> 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.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>


-- 
Mind on a Mission <http://leamhall.blogspot.com/>