3 ms·

The only problem Snappy creates is one of (initial) size. When every package is a .snap that means you're going to have many duplicated dependencies all over t

The only problem Snappy creates is one of (initial) size. When every package is a .snap that means you're going to have many duplicated dependencies all over the place. It also means that any security update that exists in a common dependency will require updating a zillion Snappy packages all at once. Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages. Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both.

binarycrusader 11y ago
Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages. That's not really a solution though, just a mitigation. Updating a single package for security fixes or other changes instead of a 1,000 is still vastly more efficient and faster. Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both. That's because the solution alone can't be through packaging; it requires changes at every level of the stack. The system needs to provide robust backwards-compatibility and sane packaging. Applications need to use interfaces responsibly, pick dependencies carefully, and use a sane build environment. When developers attempt to solve everything with the blunt hammer of packaging, they end up with a lot of "bent nails".
- annnnd 11y ago
  > Updating a single package for security fixes or other changes instead of a 1,000 is still vastly more efficient and faster It would be interesting to see the statistics - how many packages in average really use the same libraries.
  - binarycrusader 11y ago
    Almost everything uses libc, so that's an easy one. But after that, libraries tend to be domain specific. For example, all C++ programs will probably be linked against libstdc++. Programs compiled with gcc have a good chance of being linked against libgcc_s. All desktop applications are probably going to be linked against libgtk or libqt, libx11, and various other X libraries. In short, there's a significant, obvious benefit. As I mentioned somewhere else though, if a library is only used by a single application and that library and application are built together, then yes, you might as well statically-link it unless there's some other requirement.

binarycrusader 11y ago

Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages. That's not really a solution though, just a mitigation. Updating a single package for security fixes or other changes instead of a 1,000 is still vastly more efficient and faster. Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both. That's because the solution alone can't be through packaging; it requires changes at every level of the stack. The system needs to provide robust backwards-compatibility and sane packaging. Applications need to use interfaces responsibly, pick dependencies carefully, and use a sane build environment. When developers attempt to solve everything with the blunt hammer of packaging, they end up with a lot of "bent nails".

annnnd 11y ago
> Updating a single package for security fixes or other changes instead of a 1,000 is still vastly more efficient and faster It would be interesting to see the statistics - how many packages in average really use the same libraries.
- binarycrusader 11y ago
  Almost everything uses libc, so that's an easy one. But after that, libraries tend to be domain specific. For example, all C++ programs will probably be linked against libstdc++. Programs compiled with gcc have a good chance of being linked against libgcc_s. All desktop applications are probably going to be linked against libgtk or libqt, libx11, and various other X libraries. In short, there's a significant, obvious benefit. As I mentioned somewhere else though, if a library is only used by a single application and that library and application are built together, then yes, you might as well statically-link it unless there's some other requirement.