[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150513112255.GA7396@openwall.com>
Date: Wed, 13 May 2015 14:22:55 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [core john] [Johnny] Windows event loop
Mathieu,
On Tue, May 12, 2015 at 02:25:09PM -0400, Mathieu Laprise wrote:
> Shinnok said :
>
> > As you probably have figured out by now, this took me a considerable
> > amount of time to do, so Mathieu, next time around, please strive a bit
> > more when I tell you that you haven't been exhaustive enough regarding an
> > approach.
>
> I'm sorry you invested so much time redoing it. Since there were no
> objections when I asked, I sincerely thought you'd be happy with the
> working solution CTRL_BREAK even if it wasn't done your way. Unfortunately,
> you were not so I apology. I'm used to work in environments where time is
> money and if we have something 100% working and OK code-wise, we are not
> encouraged to spend a lot of time rewriting something that already took a
> lot of time to do unless it has important benefits. But now, I understand
> more how it works in this company.
Sometimes I and Shinnok fail to provide reasonable feedback in a
reasonable time. You do quite fast and I am very happy with it, but I
keep in mind that it may be needed to redo some things.
When I talked about the pattern "elegant and limited solution vs ugly
solution that covers all versions", I referred to the use of a
temporary file to get original hashes. Now the situation is a bit
different.
New solution only improves quality: correct ctrl-c usage eliminates
the helper program that may confuse users. While a patch to john core
for some versions is needed, it may be a problem in john. Also it is
not obvious to me that the helper program will cause john to save its
files in cases when the patch is needed.
The helper program was the best among proposed solutions because it
covers all versions of john (except mingw builds that are jumbo and
should be patched). That's why I emphasized it among others. I did not
dig deeply and just chose from proposed solutions.
"time is money" is too general phrase. Beforehand it is not obvious
that something will need lesser amount of time. Will not maintenance
of the second project in the tree eat time? Similarly I think that
"100% working" code is a very very rear thing, and as I wrote above:
the helper program may work wrong just killing versions that need
Shinnok's patch (built on 64-bit cygwin, I guess).
Also I should say that quick making of solutions with bigger codebase
may slow down because it becomes harder to maintain code, implement
newer features and/or bring the quality to the level needed for
release usable practically. Though the correct balance between
quality, size and other parameters is hard to find. I think you may
implement features postponing problems and reduction of the code size
to releases. But you have to improve quality before releases. It can't
be postponed for too long. This time, it happened immediately.
To avoid miscommunication, I and Shinnok may try to ask you several
times emphasizing the important parts brighter each time (also our
view changes in the process). Miscommunication is a common problem and
we all have to work around it to get more from GSoC.
It is my view. You are not obliged to accept it. Please comment.
Thanks!
--
Regards,
Aleksey Cherepanov
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.
