On 12/17/10 2:12 PM, Sean wrote:
> Interesting, and probably worth a play with indeed, although I tend to
> steer clear of Bash (unhappy with) whenever possible to do the same in
> Perl (happy with). I imagine there is machine level stuff involved that
> would rule out a pure Perl version?
> However, my difficulties for OS replacement are not so much the OS setup
> itself but the 'production' stuff that needs to go on top and a raft of
> dependencies -- compilers, BerkeleyDB, myriad Perl modules etc etc etc.
> Since the system is 'live', I usually have to run 2 versions in parallel
> for a long time... so lots of rollbacks, synchronising overhead and so
> on. Usually newer versions of some things have to be replaced with older
> versions and then inter-dependency issues arise... some of the stuff I
> upgraded specifically for suddenly stops working. You are familiar with
> the general picture, I'm sure.
> But thanks for the thought.
You didn't exactly make it clear whether you've used CentOS or not, but keeping
those interfaces from changing in ways that break things that used to work is
the whole point of 'enterprise' distributions and CentOS inherits the work of
backporting bug/security fixes without introducing behavior changes over the
long life span from RHEL.
You might also do your own homework and avoid components with a history of
breaking backwards compatibility (like BerkeleyDB...). As you have probably
noticed, core perl has excellent historical stability - interpolating unquoted @
in strings is just about the only change in perl 5 that might require a change
all the way back from perl1 code. But the modules are done by lots of other
people and occasionally are re-factored in ways that require coordinated
changes. If you are getting these from a 3rd party repository, someone else has
usually done the work of vetting the dependencies among them.
Or, you might move to java for a more self-contained, OS/distribution
independent way of doing things.
--
Les Mikesell
lesmikesell at gmail.com