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.