Date: Wed, 15 Jul 2009 08:55:06 -0500 From: "JimF" <jfoug@....net> To: <john-users@...ts.openwall.com> Subject: Re: Contributing significant changes to the jumbo patch (mostly performance improvements) > from bartavelle: > > Small suggestion : adding an ETA would be a nice addition. That sounds like a good idea. The only 'problem' with percentages done (or any percentage computation), is if there are lots of rejection rules within the rule set, it is not possible to know which words will be skipped due to rejection of form. So, if you had 10 rules each having 100 preprocessing rules (say, appending num-num), and followed that by 10 rules which each having 1000 preprocessing rules, but the 2nd set of 10 has rejection rules that filter out 90% of the words, both halves would take the same theoretical time, but when the first half is complete, john would claim only 10% of the work was done, vs 50%. I do not see a way around that, as until you run the words, john has no way of knowing that it will skip a bunch. One other idea I have, is to change markov to allow a range [min .. max]. Thus, you could run up to 220, then later pick up the search, and run from 221 to 240, and only end up with the 'new' material, assuming you use the same statsfile. Right now, about the only way to 'resume', is to drop both levels out to flat files (using --stdout), and then write code to strip the lines out of the larger file from the smaller one. But changing the markov processing to not output or use values that are under a certain threshold should not be hard at all. Jim. -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.