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 <gor...@bobich.net> wrote: > On Tue, 6 Sep 2011 19:01:57 +0200, Jan Kratochvil > <jan.kratoch...@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
_______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
