Re: two cents or not two cents

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




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


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux