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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
