Comment on Another reason to love Linux

• PhilipTheBucket@ponder.cat ⁨4⁩ ⁨weeks⁩ ago

  Yes because that is a wrong and clunky way to do it lol.

  If you really wanted to, you could use dockerTools.BuildImage to create an “imaged” version of the container you made, or you could send around the flake.nix and flake.lock files exactly as someone would send around Dockerfiles. That stuff is usually just not necessary though, because it’s replaced with just a better approach (for the average-end-user case where you don’t need large numbers of Docker containers that you can deploy quickly at scale) that accomplishes the same thing.

  I feel like I’m not going to convince you of this though. Have fun with Docker, I guess.

  source

  • Boomkop3@reddthat.com ⁨4⁩ ⁨weeks⁩ ago

    The issue is, nix builds are only guaranteed to be reproducible if the dependencies don’t change. Which they shouldn’t, but you can’t trust the internet to be consistent. Things won’t be there to be fetched forever.

    Images do. And you can turn one into a container in seconds. I suppose it’s a matter of preference. I like one a package to be independent

    source

    • PhilipTheBucket@ponder.cat ⁨4⁩ ⁨weeks⁩ ago

      The issue is, nix builds are only guaranteed to be reproducible if the dependencies don’t change.

      Dude, this is exactly why Nix is better. Docker builds are only guaranteed to be reproducible if the dependencies don’t change. Which they will. The vast majority of real-world Dockerfiles do pip install, wget, all kinds of basically unlimited nonsense to pull down their dependencies from anywhere on the internet.

      Nix builds, on the other hand, are forbidden from the internet, specifically to force them to declare dependencies explicitly and have it within a managed system. You can trust that the Nix repositories aren’t going to change (or store them yourself, along with all the source that generated them and will actually produce the same binaries), if you’re paranoid. You can send the nix.flake and nix.lock files and it will actually work to reproduce a basically byte-identical container on the receiver’s end, which means you don’t have to send multi-gigabyte “images” in order to be able to depend on the recipient actually being able to make use of it. This is what I was saying that the whole thing of needing “images” is a non-issue if your workflow isn’t allowing arbitrary fuckery on an industrial scale.

      I like one a package to be independent

      Yes, me too, which is why an affinity for Docker is weird to me.

      source

      • Boomkop3@reddthat.com ⁨4⁩ ⁨weeks⁩ ago

        you can trust the nix repositories aren’t going to change

        That, I do not. And storing the source and such for every dependency would be bigger than, and result in the same thing as an image.

        I think you’re trying to achieve something different than what docker is for. Docker is like installing onto an empty computer then shipping the entire machine to the end user. You pretty much guarantee thing will work. (yes this is oversimplified)

        source

        • -> View More Comments