10 ms·

In docker and vagrant you do it the same way, the hash of the specific artefact. That can be a commit ID, but you can also do this without Git and the likes and

In docker and vagrant you do it the same way, the hash of the specific artefact. That can be a commit ID, but you can also do this without Git and the likes and use a content hash. Those are guaranteed to always refer to the same thing. >> Usually you don't really want "the more deterministic way to get all, and only, the things you absolutely need." >IMO, you do, as otherwise you'll need to fix additional issues every time your CI runs, no? That is why I wrote about the specific exception for CI, but since we're talking about humans experimenting in a box, we're not talking about CI.

kreetx 3y ago
> In docker and vagrant you do it the same way, the hash of the specific artefact. No, in nix you pin the commit hash of nixpkgs, which gives you the exact same package set every time. But with a Docerfile, even if you add it to your project's repo then any `apt-get install something` will still give you a different something depending on when you build the image. In nix, you always get the same something. > That is why I wrote about the specific exception for CI I meant that you keep the dev environment the same as CI because if you develop in a different environment than the CI then whenever CI runs then you'll get new issues (because you weren't using the same environment).
- oneplane 3y ago
  I wasn't referring to Nix, how Nix uses hashing, what specific hash, or source implementation it is using, or that it might be using an artefact hash. I was referring to the referencing method: a hash. This is the same method in the three mentioned products (nix, docker, vagrant): an immutable pointer to a specific resource. As for CI, dev environments, not relevant here. I only mentioned in passing because CI is a common use case for hardcoded immutable reference. We're talking about someone wanting a box to experiment in, not CI. Not even software engineering either.
  - kreetx 3y ago
    What hashes do you use in docker or vagrant?
    - oneplane 3y ago
      SHA256, generally. So for example, you might use 5c15a6e5c0bf02e6c0eaa939cb543c41d7725453064c920b9a4faeea7c357506. (This is a digest hash you'd use in Docker, as an example) You can both consume that specific one, but also reproduce it locally if you want to. Depending on your intent, bandwidth and trust you can pick the method you desire.
      - kreetx 3y ago
        I mean hashes of what, not which hash algorithm. If you build the same Dockerfile, then I don't think you'll get the same hash, so I'm not sure what the use of that hash would be. (Did you mesn a hash of some other thing?)
        nunez 3y ago
        See my post above. Those hashes are a checksum of the image as seen by the registry plus some additional magic.
        kreetx 3y ago
        Yes, but every other thing you install in the container you'd somehow need to manage the hashes for, too.
        oneplane 3y ago
        The hash of the image. So you cannot get the same hash if you change something in the image. This is also why you have reproducible builds, the source should always result in the same hash, otherwise the build would not be reproducible. So building the same Dockerfile twice gets you the same hash. This does of course not work if you change something each build, like pulling in some random dependencies that you didn't also pin to a hash, or if you don't use a fixed point in time for the filesystem. We also sign the images so you get some protection against (future) hash collisions. Works for about 900 different images in our internal registries so far. We also used nix, but only a handful of developers actually enjoyed it, so that project got killed off. You can use any search engine and search for "Dockerfile reproducible build" if you want to learn more.

kreetx 3y ago

> In docker and vagrant you do it the same way, the hash of the specific artefact. No, in nix you pin the commit hash of nixpkgs, which gives you the exact same package set every time. But with a Docerfile, even if you add it to your project's repo then any `apt-get install something` will still give you a different something depending on when you build the image. In nix, you always get the same something. > That is why I wrote about the specific exception for CI I meant that you keep the dev environment the same as CI because if you develop in a different environment than the CI then whenever CI runs then you'll get new issues (because you weren't using the same environment).

oneplane 3y ago
I wasn't referring to Nix, how Nix uses hashing, what specific hash, or source implementation it is using, or that it might be using an artefact hash. I was referring to the referencing method: a hash. This is the same method in the three mentioned products (nix, docker, vagrant): an immutable pointer to a specific resource. As for CI, dev environments, not relevant here. I only mentioned in passing because CI is a common use case for hardcoded immutable reference. We're talking about someone wanting a box to experiment in, not CI. Not even software engineering either.
- kreetx 3y ago
  What hashes do you use in docker or vagrant?
  - oneplane 3y ago
    SHA256, generally. So for example, you might use 5c15a6e5c0bf02e6c0eaa939cb543c41d7725453064c920b9a4faeea7c357506. (This is a digest hash you'd use in Docker, as an example) You can both consume that specific one, but also reproduce it locally if you want to. Depending on your intent, bandwidth and trust you can pick the method you desire.
    - kreetx 3y ago
      I mean hashes of what, not which hash algorithm. If you build the same Dockerfile, then I don't think you'll get the same hash, so I'm not sure what the use of that hash would be. (Did you mesn a hash of some other thing?)
      - nunez 3y ago
        See my post above. Those hashes are a checksum of the image as seen by the registry plus some additional magic.
        kreetx 3y ago
        Yes, but every other thing you install in the container you'd somehow need to manage the hashes for, too.
      - oneplane 3y ago
        The hash of the image. So you cannot get the same hash if you change something in the image. This is also why you have reproducible builds, the source should always result in the same hash, otherwise the build would not be reproducible. So building the same Dockerfile twice gets you the same hash. This does of course not work if you change something each build, like pulling in some random dependencies that you didn't also pin to a hash, or if you don't use a fixed point in time for the filesystem. We also sign the images so you get some protection against (future) hash collisions. Works for about 900 different images in our internal registries so far. We also used nix, but only a handful of developers actually enjoyed it, so that project got killed off. You can use any search engine and search for "Dockerfile reproducible build" if you want to learn more.