Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 09 May 2011 21:02:50 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: FW: the jumbo-2 RC1

On 2011-05-09 17:48, jfoug wrote:
> For jumbo-3, here is what I think we were wanting to target:
>
> 1.Utf-8 -> Unicode (would we also benefit from a simple but faster ASCII
> -> Unicode, at some areas?)

I'm not sure what you mean here. The faster ISO-8859-1-to-Unicode 
conversion is what we have had all the time without the UTF-8 patch. 
Nothing can be faster than that. With UTF-8 patch, we still have that as 
default when not giving the --utf8 flag. I think you know all that so I 
probably misunderstand what you wrote.

As for doc/ there is a UTF8 user documentation and UTF8-DEVEL.txt (maybe 
we should drop the .txt) for coders wanting to use the shared UTF-8 
functions.

And MPI has README.mpi (file named like that for years) for users, also 
including some compiling hints (and MPI environment). Now come to think 
of it, maybe I forgot to add the simple fact you actually need to 
un-comment the MPIFLAGS line in Makefile...

> 3.Possible build changes for formats listing (options.c), for formats
> declaration code (john.c), and formats init code (john.c), possibly done
> at the makefile level. Also, it might be possible to have the .o
> inclusion IN the makefile be auto computed also.

Maybe we need to agree on (or, much easier, have Solar dictate) a more 
unified way of using the format tags (FORMAT_LABEL, FORMAT_NAME, 
ALGORITHM_NAME, BENCHMARK_COMMENT) so they are, for example, showing 
MMX/SSE/whatever in the same way (inside the brackets when testing? 
That's ALGORITHM_NAME).

> Am I missing anything, or have too many things been ‘packed’ into this
> jumbo? As for releasing, I think the method Solar mentioned of having
> multiple jumbos released, trying to generic-ify many of the more
> used/wanted patches into jumbos, and releasing them to the john-dev
> group, and once we have most of the active stuff stabilized and in
> jumbo, then release it to the world. Thus, some of these ‘projects’ may
> be better to get into jumbo-4, jumbo-5, etc, etc.

I think the fastest way to get stuff stable again is to make an utter 
mess at once and then sort it out. That's just my opinion, and the 
rationale is that all major core changes will be made and everybodys 
patches will be a lot smaller and clash a lot less from that point.

So we/you/Solar/I could create a Jumbo-3 (still not for the masses) 
right now with MPI, UTF-8 and the auto-formats-list added (btw the 
posted version works fine with your Jumbo-2 except it starts with 
listing md5-gen 21 times or so :). Then as soon as Intrinsics are ready, 
throw them in for a Jumbo-4. If not, release a Jumbo-4 as soon as it's 
there. Likewise, as soon as someone updates the SybaseASE/rar/ssh 
formats (easy fixes) we can throw out a new Jumbo-RC with them, bumping 
the revision number. Same goes for the Makefile ideas, if someone has 
the time to look at that. During this time bugs will be found and fixed 
but those patches will likely be small, non-intrusive and not by far as 
demanding on exact versions of everything around.

I believe it wouldn't take very long before things are pretty stable 
again, and from that day, format patches will almost never clash (if we 
get that Makefile magic)!

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ