Hacker News Reader

Comment by twblalock | Hacker News Reader

Shared libraries were considered a bad idea in Plan 9, and I really wish that point of view had made it into commercial Unix and Linux.

View on HN

Shared libraries are a fantastic idea. Static linking wastes system resources and makes system-wide library updates problematic. Docker's approach to things is essentially a higher level form of static linking, which is to say that it's not a very good approach. It's papering over the package management problem. We need general-purpose package management systems that allow for different applications to use different versions of shared libraries without interference. Luckily, the Nix and GNU Guix projects solve this problem very well, if only they could get some more "mindshare."

Yeah, having to rebuild every app that uses OpenSSL when a new advisory is issued... wow, that would be expensive!

Thousands of mobile app developers feel this pain now, from that particular library.

Not updating these applications is not acceptable to most organizations / device operators.

Just in case anyone thought the parent was sarcasm or theory, some refs:

http://www.digitaltrends.com/mobile/heartbleed-bug-apps-affe...

http://blog.trendmicro.com/trendlabs-security-intelligence/b...

There is also Gobolinux, that do so in a less stringent fashion.

This in that, as i understand it, compiling a lib with a feature enabled or disabled will produce different tree branches in NixOS/Guix, while Gobolinux will happily replace one compile with another if it is of the same lib version number.

So you can't have lib foo 1.0 with feature X enabled in one compile sitting side by side with the same foo 1.0 with feature X disabled when using Gobolinux.

Then again, Gobolinux has never been meant as a server distro...

Edit: thinking about it, Gobolinux could perhaps be extended with checksum dirs inside the version-subdir to separate different compiles. Not sure if this has been considered or attempted.

Shared libraries are a great idea, but not when they're fixed in an environment.

Dynamic linking everywhere has been one of the JVMs greatest strengths and best selling points. Every JVM app just names its dependencies and their versions in its build file, and often overrides (upgrades) its transitive dependencies for security/bug-fixes/performance (conflicts can be resolved by the build tool) and no configuration interferes with that of any other app as there are no environments or well-known location for the dependencies (and it's only getting even better with Java 9's modules).

Reply on news.ycombinator.com