2012/5/10 Sergio <[email protected]> > 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
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : [email protected] Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
