1 |
On Sat, Jun 18, 2016 at 4:01 AM, Mick <michaelkintzios@×××××.com> wrote: |
2 |
> On Thursday 16 Jun 2016 21:25:01 J. García wrote: |
3 |
> |
4 |
> How does Nix compare to flatpack, docker, snap, et al. from a gentoo |
5 |
> perspective? |
6 |
> |
7 |
|
8 |
Nix is a similar sort of approach. I don't think they run apps in |
9 |
containers (though they probably could if they wanted to do the work |
10 |
and a lot of bind mounting). The reality is that they're a form of |
11 |
bundling, but the bundled libs can be shared. Basically everything is |
12 |
linked to uniquely identified dependencies. So, a package isn't just |
13 |
linked to zlib, or even a particular version of zlib, but a particular |
14 |
build of zlib. However, 15 different packages could all depend on |
15 |
that same build. So, you potentially don't get the same kind of |
16 |
memory duplication that you do with outright bundling. However, if |
17 |
you install a new version of zlib on your system, nothing will |
18 |
actually use it, unless those packages are themselves updated. So, in |
19 |
that respect it is just like bundling. |
20 |
|
21 |
Since the libraries you're running with on your box are exact copies |
22 |
of the binaries the packager was using, you're going to get the same |
23 |
experience the packager did when they were testing their package. So, |
24 |
that's the big upside. There are no conflicts or collisions either, |
25 |
since every package is installed in what amounts to a private |
26 |
namespace. You can have 14 different packaged builds of zlib-1.2.3 if |
27 |
you want to, with different builds being used by different |
28 |
applications. |
29 |
|
30 |
This is just my understanding based on having looked into NixOS a bit |
31 |
out of curiosity. Somebody closer to the project should feel free to |
32 |
correct any errors I made. There are obviously pros and cons to this |
33 |
approach. |
34 |
|
35 |
-- |
36 |
Rich |