It was <2013-10-16 śro 05:42>, when Carsten Haitzler wrote: > On 10/16/2013 01:24 AM, Thiago Macieira wrote: >> On terça-feira, 15 de outubro de 2013 17:35:13, ?ukasz Stelmach wrote: >>>> This is not madness. Before we had dynamic shared libraries we had >>>> static shared libraries. No runtime linking required, everything is >>>> done via table lookups. You can't delete interfaces from a static >>>> shared library, so they make development slightly more difficult. They >>>> are lots faster. >>> a.out? I may be too young to remember. >> Yeah, that's pre-ELF. It's also before my day. My first Linux install still >> had >> a.out support and libc.so.4, but that was only for compatibility. >> >> ELF is a big beast, however. To speed up, I recommend prelinking libraries, >> executables, using techniques like ELF symbol visibility, protected >> visibility, -Bsymbolic, etc. > > i'm not so sure on prelinking. it does have perf upsides, but comes > with downsides. namely ANY change of a shared lib (eg upgrade, > security fix etc.) requires re-running prelink on all binaries and > other shred libs that depend on it. this is costly and requires a lot > of tracking. it also negates the ability to keep md5/sha1 hashes of > all files in a "secure place" and compare against it to detect > intrusion and hacking... :(
Could you please, give some more details. What's wrong with keeping hashes (sha-256 rather than sha-1 and for ...'s sake not md5) in extended attributes. If this is what you mean than what's wrong with offline (initramfs) updates running prelink after upgrading? -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpi_K1EQ_1ng.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
