4 ms·
It would be nice to have a third option when building binaries: some kind of tar/jar/zip archive with all the dependencies inside. It would give the pros of sta
by amenghra 10y ago
It would be nice to have a third option when building binaries: some kind of tar/jar/zip archive with all the dependencies inside. It would give the pros of static and shared libraries without everything else containers imply. The OS could the be smart enough to only load identical libraries once.
- Longhanks 10y agoThat's basically what OS X does with bundles.
- ori_b 10y agoThat's equivalent to static linking, but with extra runtime overhead. You can already efficiently ship updates to binaries with something like bsdiff or cougrette, so the only reason to bundle shared libraries in an archive is for LGPL license compliance, or for poorly thought out code that wants to dlopen() itself.
- amenghra 10y agoUpgrading a library that has been statically linked isn't as nice as a shared lib + afaik the OS doesn't reuse memory for static libs.
- dkersten 10y agojars already support this.
- amenghra 10y agoyes, I think we should have the same capabilities in a language agnostic way. Signed jars are a little painful to use (you can't easily bundle them), but that's a minor issue.
- justincormack 10y agoA container image is a tarball of the dependencies.
- amenghra 10y agoYes, but containers also provide more stuff that I might not want to deal with.
- ianburrell 10y agoThe OS can be smart enough to load identical libraries once. But it requires them to be the same file. This can be achieved with Docker image layers and sharing the same base layer between images. It could also be achieved with content-addressable store that deduplicated files across different images. This would be helped by container packaging system that used the same files across images. Page sharing can also depend on the storage driver; overlayfs support page cache sharing and brtfs does not.