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