[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50362788.20406@gentoo.org>
Date: Thu, 23 Aug 2012 08:52:24 -0400
From: "Rick \"Zero_Chaos\" Farina" <zerochaos@...too.org>
To: john-users@...ts.openwall.com
Subject: Re: make install
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/23/2012 05:10 AM, Solar Designer wrote:
> On Wed, Aug 22, 2012 at 02:24:10PM -0400, Rick Zero_Chaos Farina wrote:
>> Really? What is is with password crackers with not wanting to be
>> installed? john doesn't like being installed, hashcat doesn't like being
>> installed, cryptohaze doesn't like being installed... it can't just be
>> me that sees this as an issue can it?
>
> "make install" for a password cracker is primarily useful for distros'
> packages. However, at least for John the Ripper (I can't speak of the
> others) something trivial like that, if it were supported in the obvious
> way, would usually not be the best thing a package can do anyway. For
> example, Owl's package of John the Ripper builds as many as 10 separate
> binaries on 32-bit x86 (and 6 on x86-64), enabling the various runtime
> fallbacks (e.g., XOP -> AVX -> SSE2 when running on a CPU only capable
> of SSE2, and OpenMP -> non-OpenMP when the thread count would be 1 and
> thus the non-thread-safe code would likely be faster). It places the
> transparent fallback binaries in /usr/libexec/john. I'm not sure if
> it'd be good for a "make install" to include such distro-specific things
> in it or not, whereas without those it'd be of relatively little use (a
> smart package would need to do better anyway).
>
> That's for the core tree and CPUs only. When we add non-jumbo vs.
> jumbo, CUDA and OpenCL vs. not, we get even more binaries. Indeed, a
> package could choose to build jumbo with both CUDA and OpenCL only, and
> it might even be OK for a distro that always provides the prerequisites
> (BackTrack maybe?)
>
> Maybe Gentoo is a special case here, since on one hand it uses packages,
> but on the other those are commonly tuned for the specific system (thereby
> reducing the need for having multiple alternative binaries in one package).
>
I believe debian typically commands a top level directory (called
debian) so that they can do hacking like this to work around the normal
install process. IMHO distro specific things have no place in the
makefiles or otherwise in your package. It should be assumed that you
have a single or multiuser system and the admin wants to install the
program system wide. This means only one binary is needed because it
builds for the hardware on that system. Distro specific hacks are the
problem of the distro and were not intended to be included in my rant,
my concern of "no make install" was for the users. Things are just so
much better in PATH...
> Also, what should "make install" do if John the Ripper was not built for
> system-wide install? Should it include a check for that and refuse to
> work if so (suggesting how to rebuild for system-wide install)? Maybe.
> Without this check, we'd annoy a lot of people (they build, install, and
> then see John fail to work). As to possibly making builds for
> system-wide install the default, I'd rather not, because I find it most
> convenient to use John without installing. I think that's how most
> "pro" users use it (and will continue doing so), whereas the system-wide
> mode is primarily for distros, and the inclusion of John the Ripper in
> distros is primarily to make people aware of it and for casual uses.
>
I'm sure there is some clean way of doing this without forcing
systemwide to be default. Although personally I can't imagine "pros"
who really prefer having to "cd /john && ./john" instead of "john".
Especially when you imagine the number of tools most of us have
installed the whole idea of leaving every program in it's own dir
because ridiculous. That said, your choice of defaults are completely up
to you as long as we keep the systemwide stuff for those of use who
don't build out own hierarchy of programs in our home dir.
> That said, I might in fact add a "make install" in 1.8+. I just need to
> decide on how to approach these issues.
I hope that the above helps, and I would be very happy to give my
opinion (and help) on this goal to the best of my ability (and in a
non-gentoo specific way.
>
> For Johnny (as it is), implementing "make install" should be trivial.
Yes, yes it is. I just could not stop my jaw from dropping when it said
"make install not tested". I kept thinking "then why on earth did you
bother to write a "make install". Personally I like to test the things
I write (and release).
Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQNieIAAoJEKXdFCfdEflKIUMP/RIheKv7q77kuHq4jnICjVwU
lgG0DDgUycJtV6UPe+FP3FXSwM/88cdyg5L9yW3g88v33stQlVrZxviKKnqIocEw
sIQApIVeOqD6Vg+VXK55bJBBhzmLDfeN2KA2sCI1zFTWAhlfVGgSZSrbIELeTCHY
sMQafvh9qeazVXJIFx2EB2wgrBT3qbp3UfNofEU1m7zYTn3PXIjd26/M4ycDVdGu
RSsi9ZhPnEZvlWwRXBOtARCsm7nKh8KFPqOlu67lyakJcIFnnRrsUoBusRcNGvT4
yHwPpwkThmEA6VLTD7hk6emJ/RnJRl8tl7fUdEuXg7jTgmQf8SQ4V582Ipjqn5KC
zuGWtgXEZGZ5HhOpjmR7fhWMQXdOlGGzzrpJeWw8t0PU8q+LPbazl8fzlAc6VxY/
t7tQlWXWCfIOy0qSFRhz+A4nA73S681RyW/wI/ASE2+9SPuLs6yhBbR8orxFyAb9
CviTkSsIexyJ4dBsNG5uNYtUkdXrDEUE1g93y/MRM7lCehqVIwm5T7da+nS2DiuN
qxUTuLkfqHvp3rLh45stvCUq6pvK4IVOCtLBg3rgI8AkwZdXLzzYOoEi3XvG3GkS
P3ZBSwinUMVinaSdPnmxnjoGhANKXtS2bWEg9Z9VvQtDXN4So0h8DCpHML0gLguN
BhsKxBiCFhzglOGegWnQ
=itX9
-----END PGP SIGNATURE-----
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.
