Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a two sided coin, if you update a dynamically loaded library that subtly breaks backwards compatibility, you end up with apps that mysteriously stop working because of some other update in the system.

Really, it's up to the app maintainer to update their program, and if it has a vulnerability, in theory the sandbox will prevent it from doing damage to others.



If someone updates a library incompatibility, they deserve what they get. That's why shared libraries have versioning.

In the mobile space, it would be even more beneficial if platform holders and ISVs actually followed this; the memory and space usage savings could be substantial.


I'm uncertain why someone would downvote my comment above, but shared library versioning is a real thing, and it is a best practice:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries...

https://www.usenix.org/legacy/publications/library/proceedin...

Linux distributions heavily depend on this for the GCC runtime libraries (such as libgcc_s); it's how they provide backwards compatibility.

Many operating system distributors also rely on symbol versioning for their shared libraries as well so they can compatibly evolve interfaces for consumers.

So my original point stands, if someone incompatibly updates a shared library without accounting for versioning, they're doing it wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: