[ale] OT: ruby/redmine/apache
Jim Kinney
jim.kinney at gmail.com
Wed May 9 10:58:45 EDT 2012
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.
-or-
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.
BTW: php-5.3 ships with RHEL5 in a package called php53 (and assorted
friends).
On Wed, May 9, 2012 at 8:12 AM, leam hall <leamhall at gmail.com> wrote:
> 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/>
> _______________________________________________
> 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
>
--
--
James P. Kinney III
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.
- *2011 Noam Chomsky
http://heretothereideas.blogspot.com/
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120509/89e109be/attachment-0001.html
More information about the Ale
mailing list