Am 15.10.2013 19:49, schrieb Jan Kratochvil: > On Tue, 15 Oct 2013 19:42:25 +0200, Reindl Harald wrote: >> * look at the amount of updates and how they hit prelinked libraries until >> prelink ran again >> * look at the "lsof | grep DEL | grep /usr" output caused by prelink > > Sorry I do not see what disadvantage is it? have fun in distinct between prelink caused "needs-restarting" or real >> * look at the wasted cycles of running prelink itself and compare to the gain > > the cycles of prelink happen during night when nobody waits for anything. > The gain happens when user waits until the program starts. your notebooks are running 24 hours a day? really? >> in the past on notebooks i hated prelink and god bless the maintainer which >> removed the prelink-require out of rkhunter which was pervert >> >> most of the time i noticed the weak performance while prelink ran >> between that i got alarmed all the time by rkhunter-notifies >> *because* i should prelink this and that file > > Sorry I do not see how is rkhunter related and what is the disadvantage. well, read what rkhunter does it verifies file integrity wonderful idea have a software default touching the binaries and try what happens if there where some updates and prelink did not run before the next rkhunter startip -> you get alarm mails > If you mean that prelink ever runs while you sit at the computer then it is > a bug in cron, not in prelink. /etc/cron.daily/mlocate has a similar problem there are people wich shut down or suspend machines when they are not in use how do you imagine the cronjob run while they are not in use for this *majority* of users?
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
