Les Mikesell wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">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.
Why Perl? Because writing/maintaining 20,000 lines of terse Perl code is manageable, whereas the equivalent 200,000+ in Java ruled itself out at the very beginning, (even at a time when I knew some Java but no Perl). A practical decision I clap myself on the back for every single day despite knowing that had I gone with Java (and this project fallen over long ago) I could now be getting big quids from some corporate developer who needs a team of new Java graduates overseen.....(hmmmmm or was it the right decision?).....
Core Perl stability? I agree.
Why BerkeleyDB? I dont know of an embedded-db equivalent that will store 'any and every data exactly as is'.
Originally on RH8 for 3/4 years, the first attempt to port onto a brand new release of FC4 broke everywhere. The second attempt a year or so later went better and remains. In the meantime FC support philosophy has tightened/altered to the point where I simply must abandon it. I believe it has become just an 'alpha test ground' for RHEL. Reminds me of the painful Dos saga -- the first version to work properly (Dos-6) was just about irrelevant when finally released. So yes, CentOS has come into my sights ... (and I'm a bit long in the tooth to tiptoe around as you may have gathered!).
Sean