Re: GerH source distro at hebbut.net: HOW TO compile/compare/merge for Bill et al

On Wed, Apr 02, 2008 at 12:22:22AM +0200, Matthias Kilian wrote:
> > penalties, for no good reasons.
> 
> Including a driver into a kernel doesn't harm people not using that

In a perfect (=bugfree, both hw+sw) world, that might be true. Not in
real world. Heck, how many times I've seen such'n'such generic driver, 
compiled in or as module loaded by default, usually always there because
 - you know, just in case ... - make the system hang.
But that's the kernel stuff.

> driver. Same for crm classifiers. If you don't use it, it can't
> harm you. If some classifiers are potentially dangerous, the question

not quite, sorry, that's too ingenuous. Experimental stuff is likely more
buggy - fancy macros, unintialized vars, weird #define, you name it - which 
might trigger a complier/linker bug so that to expose an exploit.
How about those heisenbugs? the more code you stuff in, the worse the 
situation when you go try to debug. 

crm114 was born as a monolithic lang.engine+classifier, but quickly became 
clear the modular/lib/plugin design is the way to go, as more classifiers 
were, are and likely will be added.

It took some time + efforts to break the once monolithic .c into the saner
.c collection we've now, let's not waste e-ink on another 
monolithic-vs-modular debate, which has the latter as the clear winner since
ages: think of *nix itself, Linux kernel, MACH kernel, PERL (what about a
176MB /usr/bin/perl with all cpan.org complied in, cool eh?).

Like *_t portbility salad, modular config / compile / run time (better)
(infra)structure is a missing feature - now we've a bunch of classifiers, 
but there are so many out there in the data mining realm - are we going to
consider modularization at the 15th? 23rd? what's the breakeven here?

Moreover, consider a cool RabOof classifier coded by Joe Crack, pity its
license, free or not, doesn't allow a merge into mainline, not even a 
bundled distribution; you'd get the crm114 code here, RabOof src there and
go glue&use them on your machines. No problems with modular structure
in place, as long as RabOof keeps in sync with API, but quite a mess with
current situation.

Consider crm114 packaging for distros, eg Debian: 
  old-mainline-hopely-stable_stable-only-stuff	-> 'stable'
  old-mainline-hopely-stable_everything-in	-> 'experimental'
  mainline-current_everything-in		-> 'unstable'
would be a matter of --config stuff, just like tre/pcre/posix.

> is wether they should be included AT ALL or wether there should be
> some prominent documentation that they ARE dangerous (i.e. probably
> buggy).

that's the point/usefulness of such main switch like Ger's 
 CRM_PRODUCTION_CLASSIFIERS_ONLY
which is like the Linux kernel's '[ ] experimental code' main config option.
Then you check the [stable/exper] kernel modules you wnat/need.
Likewise we'd need for crm114.

> So just document possibly broken classifiers as, well, possibly
> broken and dangerous.

ok, we've documented x y w z are unstable, experimental, buggy; now what?
if we've our modular structure in place, it's a matter of config choices,
else it's useless hacking on each and every release.

> 
> Just my 2p

and my 0.013 EUR

[sorry for the rant/blast, that'd be stuff for -devel, actually]

-- 
apolo

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace