[CentOS] two cents or not two cents

Mon Dec 20 22:56:26 UTC 2010
Sean <soso at orcon.net.nz>

>  And there are IDEs like eclipse that do a lot of the grunge work 
> boilerplate for you, and maven to manage components as you scale up.
eclipse froze my first FC4 tryout ... is for me what BerkeleyDB is for you.
>
> I do agree personally - I can't think in java and do much better when 
> you can squeeze the logic of a routine onto one page where you can see 
> it all at once.
> .....
> I'd relate the importance of code size to the amount of RAM you can 
> afford.  For a long time now it has been cheaper to buy RAM than to 
> hire someone capable of shrinking your code base - unless maybe you 
> have a mass-market application that will run on millions of boxes.
By 'size' I was actually referring to 'source size' :  (1) you say it 
above "..[all micro] logic..[on] one page ..".    (2) the same idea but 
in a project-macro-logic sense viz a viz sheer quantity of code lines to 
manage overall.
I do rate java for designing GUI-interfaces. No argument there. GUI 
components ARE objects. But most of the real world aint ..(malfits being 
the reason for extensibility in OOP).. and it turns out I think that 
re-usability mostly goes hugely custardly. (And aside, if best 
programming is the truly 'creative' kind, not just spending time finding 
the right lego blocks to make new combinations with, then OOP fits badly 
anyway).
>
>>>> Why BerkeleyDB? I dont know of an embedded-db equivalent that will 
>>>> store
>>>> 'any and every data exactly as is'.
>>>
>>> I'd think sqlite first - these days anyway.  
>
> You can always do input into temporary tables structured more like the 
> input data and process to normalized form later (if needed).
Not if normalising implies any user-interactivity (the usual scenario). 
An early input in the automated background input stream off the wire 
generates some KEY which a later input of the same stream hours later 
may try to match against. Would the latest sqlite accept a KEY that was 
say (& maybe badly) both QP-encoded and HTML-encoded, and even if it did 
so now would that be guaranteed to endure through future versions of 
those encodings without ever rejecting? Even if the 'normalising' could 
be automated satisfactorily to avoid all rejections for sqlite right now 
within the capture process, it would be biased to sqlite's constraints, 
an unwanted extra layer that may well also actually corrupt the heavy 
duty (search-engine)-normalising already being performed on difficult 
data ..(eg stemming, scoring, indexing).

In a sense, BDB serves the "temporary tables" suggestion already, but so 
much more as to be sufficient in itself. You seem unduly anti-BDB? Quite 
frankly I have had far less trouble with it than any other db ever. In 
the past year I have had to do one dump/(re)-load [about 1 hour], and 
twice delete the environment files [about 1 minute] so that they would 
self-rebuild on next access. That's it!

Which doesn't mean I'm not also always open to suggestions.

>
> Sqlite should be equally usable - and easier to convert to/from server 
> backends.  That might not have been true long ago, though.
>>> If you had moved to Centos3 as the first step, you could have run that
>>> with nothing more drastic than a periodic 'yum update' for years, then
>>> jumped to Centos5 with no rush to change again even now.
>> Ah, now you tell me!
> You should have asked sooner.   I still have a few centos3 boxes going 
> strong. I had problems with perl modules and a few other things in the 
> early stages of centos4 and skipped over that for most systems.
And proves that the time I can make available for discovery falls short 
by heaps. Nearing closure on a very long project right now, thinking 
ahead to next steps, reviewing the robustness of past decisions, is very 
enjoyable and an unusual luxury for me. Playing the 'distro-hopping' 
game that many seem to indulge in for instance has just been out of the 
question.
I have some processes shared with win boxes over RPC (producung excel 
charts) which require that both Perl version and versions of modules 
like Storable.pm exactly match, so am largely at the mercy of  what the 
Activestate repo provides as to what must be run on the linux box too.
I need lots of browsers too (alongside Firefox) for day to day work. The 
old versions of Mozilla, Konqueror and Opera which will run under FC4 
are critically dysfunctional on some operations needed. So am looking to 
try a more up to date team.
CentOS is beginning to look more & more like my cup of tea, and since I 
gather that a new major is immanent maybe it will support the new Google 
Chrome (along with Seamonkey, Opera-11+)? I wonder if there is a list of 
packages somewhere. If the repo web-page for CentOS provided the actual 
repo-address I was going to try direct my FC4-yum there for listings, 
but cannot seem to find it. It may be still the case that I cannot have 
'both worlds' on one box, or maybe I can try a CentOS + VM-XXX 
configuration.... hmmm.

Sean