41–48 of 48 posts
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…
Slightly off topic, but I'm really frustrated with the state of software packaging these days. Every solution tries to solve the same problems (reliable dependancy resolution, reliable installation and removal) but they all try and solve it in different incompatible and flawed ways. Consider the following: I need a reliable way to deploy my app to clients. The popular options are: 1) Source code + Configuration syste…
You mean sort of like npm?
Earlier quoted context omitted.
I wouldn't use npm as an example of a stellar package manager.
Not using it as an example of a 'stellar' package manager. Just one where the dependencies can be defined with version. I was under the impression that apt-get will just use the most recent version.
Earlier quoted context omitted.
Snappy packages are definitely containers in the sense that they 'contain' an application along with all its (runtime library) dependencies. Think of containers in order of size/scope like this: 1. Physical appliances. 2. Virtual machine images. 3. Docker images. 4. Snappy packages (and similar) At the top we have an actual physical piece of vendor-chosen hardware that "contains" a vendor-controlled application and e…
As docker still doesn't really provide security (by design) - the main thing that docker brings with it is an awareness of dependencies. Now anyone can whip up a microservice that's ready to run in chroot, with minimal access to the rest of the system. Looks like Snappy packages does much the same thing. Try to hand-craft a chroot for Firefox, and see how far you get (at least without cheating and doing something lik…
Earlier quoted context omitted.
Not using it as an example of a 'stellar' package manager. Just one where the dependencies can be defined with version. I was under the impression that apt-get will just use the most recent version.
You can specify a version. The real trouble is that you generally cannot have multiple versions of the same package installed on the same system. Thus, if multiple packages specify different versions as dependencies, you're hooped.
Earlier quoted context omitted.
As docker still doesn't really provide security (by design) - the main thing that docker brings with it is an awareness of dependencies. Now anyone can whip up a microservice that's ready to run in chroot, with minimal access to the rest of the system. Looks like Snappy packages does much the same thing. Try to hand-craft a chroot for Firefox, and see how far you get (at least without cheating and doing something lik…
Can you point to the security tradeoff/design decisions regarding Docker? I would really appreciate it.
But generally, docker doesn't do all that much locking down - if you have the libc/code to do something in a docker container, you can in general do it. The layered fs is mostly like a chroot - it's safe as long as the kernel is safe, and then it's completely unsafe - if the kernel isn't safe. The flip side of this is that if you write a program/daemon that works on regular gnu/linux, it'll work (as long as you provide the needed library code) in a docker container. And docker helps focus dependencies, in particular data dependencies (the other tricky part of getting something to run in a chroot - where's /etc/shadow? Where's /etc/group etc)).
I'm sure we'll see Docker move in a stricter direction, as more people are wrapping their minds around isolation -- apart from the running under same kernel, LXC can do more. And we have things like rkt with kvm backend that takes all the hard work put into containers and magically(ish) transplants that to work with minimal vms.
Docker did/do(?) one thing: it didn't allow you to run Docker in docker (you need/needed to run a "privileged" container for that).
I'm not sure if that was as coherent as what you hoped for, but that's sort of what I tried to imply wrt design tradeoff.
Earlier quoted context omitted.
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…
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 mor…
It would be interesting to see the statistics - how many packages in average really use the same libraries.
Earlier quoted context omitted.
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 mor…
> 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.
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.