prelink performance gains

[Paul Wouters]

On Tue, 15 Oct 2013, Jan Kratochvil wrote:

> I just do not understand why to give up on that negligible optimization when
> it brings no disadvantages.

Because you did not my previous email?

- complexity
- complicated prelink blacklists
- complicated cron job exclusion with sysconfig
- FIPS foot-bullets
- reduced alsr

Other people added:

- battery drain (i dont care if its cron or not, without prelink no
   drain)
- sluggish systems when prelink is updating
- additional ram use when logged in for a long time

So far you seem to say "those are not prelink bugs".

Just the FIPS issue for me (speaking as a member of the Red Hat Security
Group) is enough to say that if the gains are too small to measure, that
it's time for Ocam's Razor and not make our systems needlesly complex.

Furthermore, in the past I've indicated that we should have support for
systems booted in FIPS mode with fips=1, where though libraries and
programs that could not be prelinked should be unprelinked, as the
sysadmin specifically told us (via fips=1) that they value security over
speed gains)

prelink has served us in the past. It's time to let it go.

Paul