[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Apr 2015 03:22:33 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Johnny as a job scheduler (was: Johnny: core/jumbo differences)
On Wed, Apr 22, 2015 at 10:17:46AM +0300, Shinnok wrote:
> I think Johnny could potentially differentiate itself from CLI usage in the following ways:
> 1. Makes session management a breeze
> 2. Makes concurrent cracking management a breeze(on a single machine)
> 3. Makes wordlist management easier(mulitple, concat, dedup, reseed from pots, etc..)
> 4. Makes hash management(inclusion, exclusion, dedup, concat, merge, recognition) easier
> 5. Simplifies the path towards testing several attacks modes quickly(rules, formats, modes)
This sounds right to me.
In fact, most or all of this would also make sense in an interactive
text mode user interface, e.g. with ncurses. So it could make sense to
have an abstraction layer there - a job scheduler on one layer, and a
(maybe-)user interface (GUI or TUI or web or even API) on a higher layer.
On top of this, the same interface could also manage instances on remote
machines. (BTW, some people have been doing that already, for their
teams' or companies' internal needs.) However, I feel that for the
current Johnny project that sort of abstraction would be a distraction,
so perhaps it's something to revisit later... or never. It isn't as
much work to rewrite pieces of code later as it would have been to try
and come up (or rather fail to come up) with a "final" design for a
layering model like this right away. So it's appropriate to try things
out in Johnny's GUI-specific context now.
Alexander
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.
