Re: a slightly updated rpm spec file for Ger Hobbelt crm114 branch

On Fri, Jan 30, 2009 at 05:53:22PM +0100, Ger Hobbelt wrote:
...
> set of other functions in the current codebase. Thanks to the low
> profile of crm114, nobody with an eye for such things has yet had a
> really good look, as we don't seem to feature on the CVE list or
> SecurityFocus. Yet.

no? s**t :( ... what a shame. We ought to be there, every popular sw
features a long list over there, the longest the more popular it is.
It's for sw what facebook is for humans these days - if you'ren't (listed)
in there and haven't your long (CVE) list of floobydust, you just 
don't exist - likewise for sw, no CVE entries? nobody's gonna talk about
it.
Really, CVE-like listing turns out to be (also) another marketing tool.
What about putting in some easter-egg? some dbl-free()? some null-pointer?
...
 [ARGH-098] [CVE-2009-2345] CRM114: several off-by-1/3 in mmap() ...
 [ARGH-101] [CVE-2009-2375] CRM114: code injection on TRAP() without ...

 [cve-lurker] hm, crm114? what's that? lesse ....

good if you're running a biz 'roud it; else not that much, I'm afraid.
Or the converse? hmmmmmmmm ... MS docet

> your marks, but backend financial systems (to name but one area)

yeah, it'd be a pity that such a crm114, sitting there to crunch SM feeds
and uncover the magic predictor(s), stumbles on an 'internal error' and 
swaps buy/sell actions ;)

> missing from vanilla megatest & GerH 'make check': there's a whole
> range of errors/'oddities' which is not caught by those (e.g. input
> series fed to train / classify). We're just darn lucky they don't
> happen... don't they?

maybe the public is taking care of it? ;) - ie seems that lot of people feed 
many GB / day through crm114-powered filters; occasionally somebody catches
some weird stuff in the logs and reports to the ML.
The problem is, that - besides platform-dependent oddities - it's 
programmable, some are using it with just the basic LEARN+CLASSIFY,
while others use complex crm scripts, so several levels (or classes) of 
errors add up. Not the most favourable situation to devise a robust test
vectors set.

> well. Think: intelligent routers and packet filter hardware. Need
> filesystem. Nyet. Want libcrm114? You betcha.

or even a kernel-module.

> (And for anybody else out there who likes their own script languages
> (perl, PHP, Python,. Lua, Ruby, you name it), a non-file-based
> libcrm114 is a real boon (language add-on!) as well as they don't need

see Fidelis' approach ...

> to learn crm114 script, which was once referred to as TECO on acid,
> IIRC. crm114 script as a language design a cool, geeky idea, and for
> that, I like it and respect it. But it's holding back crm114 as a tool
> for statistical filtering/dissemination, as not everybody is willing
> to cope with another language, even when it comes preconfigured.
> Especially in business/professional environments.)

yes, and no: that's the old point of fully modularizing it, like the
(now only) compile-time classifiers-list option - just add the crm-engine
as module. But once you've torn it apart into its little components, it'll
be a nice option among a host of others for experts, and little interesting
for many others. Not everybody interested in stats/data mining/whatever
grok some prg idiom, esp these days with abundant computing facilities; in
this scenario, the stock crm114 is a small & fast, self-contained 1-stop 
solution for such tasks, and once you get reasonably used to crm, you can 
use it ~same way in a few platforms.

> GerH is a fork. And apparently, that's official.

there's nothing wrong with that.


-- 
paolo

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword