12 ms·

We have evaluated Snappy a lot. In Snappy you can only share executables as dependencies, not librarires. So, you can use curl as a program, however if you want

by CSDude 11y ago

We have evaluated Snappy a lot. In Snappy you can only share executables as dependencies, not librarires. So, you can use curl as a program, however if you want to use libcurl in your application, you have to include the library in package. When this list goes large, you have to keep track of the state of the every dependency you include. Bugfixes, security patches.. However, in regular package managers, you can also depend on libraries. And this solves a lot of headache, since those packages are shared globally and updated by system. I have almost never seen a backwards incompability caused by an update (some program needs to update liba, but some other program cannot use that upper version), it happens very rarely. If you insist of using a specific library version, there is nothing stopping you from including it in your package , like snappy's. Lastly, when you include libc a million times, or static compile your binaries, the size goes up and storage/bandwith also becomes an issue. I agree that Snappy solves some problems, but introduces new serious ones as well.

riskable 11y ago
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.
CaptSpify 11y ago
> When this list goes large, you have to keep track of the state of the every dependency you include. Bugfixes, security patches.. However, in regular package managers, you can also depend on libraries. And this solves a lot of headache, since those packages are shared globally and updated by system. And this is the back-and-forth problem that nobody has the answer for. Do we make this one app fail, because the maintainer for it isn't updating for library updates? or do we cause system-wide insecurity because we need that one app to work? I'm in favor of the former, but I think both sides have good arguments.
- Karunamon 11y ago
  Having been burned repeatedly by the primary problem you mention, I lean more towards the second case simply because security depends on the application involved and how it's used. An insecure app may have mitigations available that don't reduce its usefulness. A broken app is just broken and useless.
deleted 11y ago
[deleted]

by CSDude 11y ago

riskable 11y ago

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.

CaptSpify 11y ago

> When this list goes large, you have to keep track of the state of the every dependency you include. Bugfixes, security patches.. However, in regular package managers, you can also depend on libraries. And this solves a lot of headache, since those packages are shared globally and updated by system. And this is the back-and-forth problem that nobody has the answer for. Do we make this one app fail, because the maintainer for it isn't updating for library updates? or do we cause system-wide insecurity because we need that one app to work? I'm in favor of the former, but I think both sides have good arguments.

Karunamon 11y ago
Having been burned repeatedly by the primary problem you mention, I lean more towards the second case simply because security depends on the application involved and how it's used. An insecure app may have mitigations available that don't reduce its usefulness. A broken app is just broken and useless.

deleted 11y ago

[deleted]