Re: prelink performance gains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux