On Wed, 2007-06-13 at 22:32 +0200, Rasmus Skaarup wrote: > Guy Hulbert wrote: [snip] > > Obviously the line counts are not a completely fair comparison but > it > > seems that the tools are progressively less accessible (perl, C, lex > > +yacc) and the code seems to become *more* complex (though each tool > > covers more different logs). > That's not really fair as dlog consists of analyzers for many other > tools. The data-collecting tools can be used directly to feed mrtg for
I did not really mean to get hung-up on line counts. It was just not clear to me why there were so many different programs. [snip] > But the prize winner will still be the dodlog.pl script that creates > the graphs: > > $ wc dodlog.* > 1804 5324 64631 total > > (Approx. 1/3 is definitions for the RRDtool databases that could exist > in a config-file maybe) Yes. I did look through the code. > > - but again that script handles all the different types of log files, > but it does not have to be executed on the same hosts as the This point was not clear to me. > data-collecting tools. Many largescale installations produce GB's of > logfiles, and the small binary file that actually searches through the The GB of logfiles explains why you are interested in performance, as Charlie Brady pointed out. [snip] > > Is it really necessary to have a different program for each log or > is it just easier to do it that way ? > > > Many of the tools produce output that is very similar (I think axfrdns > and tinydns is almost identical), so it's difficult to make one pattern > to rule them all. This last sentence does not make sense to me. I don't see anything which manages syslog output (no 'dlogsyslog.*') or apache logs. Is this just aimed at DJB programs (and qpsmtpd) or is there some idea of more general use? Depending on what you want to do with this, it might help if you were to document *why* someone would want to use your tools both in the source distribution and on your website. When I find new software, the first thing I look for is either an attempt to market the software to me or some other evidence that the software is going to still be available in 5 years from now. Source availability alone is not usually enough for a package to be really useful. For example, when Debian started up, they announced two goals: 1. to be the leading non-commercial, GNU-compatible linux distro 2. to maintain compatibility with RedHat, which they saw as the leading commercial distro at the time This was about 1994 or so. Ubuntu has, as bug number 1, in their bug-tracking system: "Microsoft has more market share" (from memory). Obviously, these both imply a bit bigger commitment than one developer can make ;-). > > > -Skaarup -- --gh
