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