elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

2012/5/10 Sergio <sertorbe@xxxxxxxxx>

>  About the part where you say that maybe an application won't like it and
> we may end up with an "unexecutable", prelink skips incompatible apps (if
> you want i can send you a log from prelink working in my PC).
>
I know it does attempt a graceful failure, but it doesn't always work, as
that Glib example shows. And accodring to this
thread<http://www.pclinuxos.com/forum/index.php/topic,100956.0.html>,
such issues still happen with some modern libs. Maintaining an internal
blacklist of things which should not be prelinked, compiled by trial and
error doesn't seem to be a good idea.

Also, that thread suggests that prelink works only on 32bit systems. I got
tired of rumors and tried to find some official documentation on Prelink.
All I've got is a manpage and a
paper<http://people.redhat.com/jakub/prelink/prelink.pdf>dating back
to 2004 - not very reassuring. In additon, I've stumbled upon
this: "It has been observed that if you are low on disk space and you
prelink your entire system then there is a possibility that your binaries
may be truncated. The result being a b0rked system" at
https://wiki.archlinux.org/index.php/Prelink
Too bad we don't know how much space it will need to avoid such disasters.

And "When I prelink my system some static binaries don't work anymore" at
http://www.gentoo.org/doc/en/prelink-howto.xml isn't very reassuring
either, and even though static linking shouldn't be used, IRL it happens.


> I agree with you in the case of shutdown or blackout, however prelink can
> delete the prelink in a executable as easy as can put it.
>
I suspect it won't work on a broken executable. Either way, did I
understand correctly that you suggest the user to acknowledge that the
issue is in failed prelinking and revent the prelinking manually via a
terminal command, while the user is A) not aware of prelink's existence and
B) most likely doesn't know anything about terminal? (that's our target
audience).


> Also when i have some time (maybe this weekend) i will try to do some
> benchmarks in order to see wether it has a important impact or not.
>

Looking forward to it. Please run the tests in identical environments to
eliminate interference from preload and various kernel caching stuff, e.g.
from a virtual machine saved state. This mail from Preload's original
developer suggests a reproducible testing technique:
http://gcc.gnu.org/ml/gcc/2001-05/msg01670.html

But however good or bad the result is, I seriously doubt we'll ever tackle
it because of all the issues listed above. I'd much rather hit up on
something from this list:
http://shnatsel.blogspot.com/2012/04/5-ideas-that-every-desktop-os-should.html

-- 
Sergey "Shnatsel" Davidoff
OS integrator @ elementary