We like randomized addresses, improves security so exploit code cannot anticipate the address.
Prelinked address might improve startup speed, but I'm not convinced the speedup is worth the risk.
I believe even when sysctl is set to randomize address space, prelink will still effect normalized addresses.

Also, there are questions about the actual speedup.

I feel prelink should be disabled in fedora completely.

However, updating the package is still desirable for resolving dependencies.


-Jon


On Tue, Sep 6, 2011 at 12:14 PM, Gordan Bobic <gordan@bobich.net> wrote:
 On Tue, 6 Sep 2011 19:01:57 +0200, Jan Kratochvil
 <jan.kratochvil@redhat.com> wrote:
> On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote:
>>  Can you elaborate as to why? My experience and measurements show
>> that
>>  prelink does more harm than good more offten than not. I can think
>> of a
>>  lot of reasons to not use it, and very few reasons to use it.
>
> It speeds up the program startup up to 50% (you can Google out
> various
> benchmarks).

 I did, and found no definitive, reproducible results to support the 50%
 claim. It certainly wasn't corroborated by my own measurements - last
 time I tested what benefit it gives, the results were at best
 inconclusive.

> As almost any performance feature it sure comes with more
> complexity of the ELF files handling.  The most easy ELF files
> processing
> would be with -O0 code - so why do we build the programs with -O2?
>
> Nowadays some people do not consider performance as anything to care
> about so
> in such case it is understandable they do not see a need for prelink.

 The only performance claims that are worth listening to are the ones
 supported by evidence showing consistent and reproducible improvement -
 and I have seen no such thing to support prelink recently.

 And I just thought of another reason to not use prelink, in addition to
 tripwire/IDS issues and vserver's hashify feature - flash media.
 Rewriting a large chunk of your binaries on a semi-regular basis isn't
 going to help the longevity of a system running off cheap flash media,
 as most ARMs are doing.

> It is true that if program is written in C it is usually fast enough.
> But specifically ARM may be the only popoular platform where I do not
> find the C programs fast enough, though.

 If we're going to argue the performance toss, rewriting yum in C would
 be a good start toward addressing the eyewateringly big performance
 issues. Compared to that, anything that prelink could possibly achieve
 gets lost in the noise.

 To summarize - I'm unconvinced of the benefits of prelink. But I will
 happily be persuaded otherwise by reasonably broad and repeatable
 empirical evidence.

 Gordan
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm



--

-Jon