Wait... binaries inside a ~homedir/.dotfile/? Why on earth?
Nix as OS X Package Manager
101–110 of 209 posts
Re: Nix as OS X Package Manager
#102Earlier quoted context omitted.
How do you recommend applying security updates to the image, short of running (for example) `apt-get dist-upgrade`? What if that breaks? Do you just continue with the out-of-date image?
This is the biggie for me. When the next heartbleed comes out, it would REALLY suck to be running a bunch of opaque images that you have no idea how to patch.
That's the thing, I surprised how many people were "ok" with that binary imagine that someone built on their laptop. Few saw an issue with it, and instead praised it as a great win.
I mean, it was a win, not having to untangle the hairball of rpm/deb dependencies. I like that part too. But not understanding the downside was what shocked me. It was like everyone drank the magic kool-aid potion.
Re: Nix as OS X Package Manager
#103Earlier quoted context omitted.
Can you give me an example of projects which require this setup? (Even a personal anecdote will do)
Can't reply to sibling post for whatever reason. > Working for a full-time software consulting agency, I'm normally actively working on many projects at the same time, each of which have their own nuances of packages that are required (e.g. different versions of PHP, different sets of dependencies, etc.) I don't think this is what Nix offers. This is more like a homebrew competitor (I assume you don't use homebrew to…
According to zachrose though (GP) it's exactly what it's supposed to do.
See also this comment (great uncle post?) https://news.ycombinator.com/item?id=11773206
It talks about being able to setup and instance of emacs referencing a specific nix environment.
Edit:
This comment also talks about using it to solve virtualenv shortcomings. https://news.ycombinator.com/item?id=11773036
Re: Nix as OS X Package Manager
#104Earlier quoted context omitted.
I mean, that's exactly what a Dockerfile is for. I don't know of anyone seriously using Docker that isn't using Dockerfiles exclusively. I only know of a single time when it's valuable to "commit" a new image (recovering logs from a stopped container). None of which is to detract from Nix. Nix+Docker is a powerful combination. It takes Docker's declarative nature all the way down to the compiler used to build the bit…
The big difference is that nothing about Dockerfiles implies that the processes they perform to build an image are deterministic or repeatable. Will a build step that runs `curl https://github.com/something/whatever` do the same thing in six months that it does today? Docker doesn't help with that at all. Nix improves determinism by (almost) guaranteeing that if you build the same nix expression six months from now,…
You're not wrong, but Docker comes at it from a different angle; Docker expects you to be handing around tagged images, to solve a similar set (but not the same set!) of problems that reproducible builds solve.
Ideally, I want _both_ of them: tagged Docker images being sent between environments (with `docker run -e SOME_ENV=testing imagename` for changing the internal config), but reproducible builds in my Dockerfile. I wonder if Nix can be used to achieve that last part?
Re: Nix as OS X Package Manager
#105Earlier quoted context omitted.
> I wouldn't have known how to reproduce that "working state". So what? You don't need to reproduce that working state: The work has already been done! Think about how the interactive approach Lisp and Smalltalk programmers use is superior to the compile/run/rerun approach used by C++ and Java programmers -- by exploring the problem in a nonlinear way, you can find your way to a solution more quickly. Docker package…
> You don't need to reproduce that working state: The work has already been done! My background is physics, and the philosophy there is "If you can't reproduce it, it doesn't exist." In my experience with software, sharing opaque binary blobs is a Bad Thing. It doesn't matter if the blob is a proprietary firmware image, or a "open source" docker image. It's a magic unreproducible image. And (to me, at least) therefor…
> If you can't reproduce it, it doesn't exist.
I can't reproduce me, so do I not exist?
Re: Nix as OS X Package Manager
#106Earlier quoted context omitted.
I mean, that's exactly what a Dockerfile is for. I don't know of anyone seriously using Docker that isn't using Dockerfiles exclusively. I only know of a single time when it's valuable to "commit" a new image (recovering logs from a stopped container). None of which is to detract from Nix. Nix+Docker is a powerful combination. It takes Docker's declarative nature all the way down to the compiler used to build the bit…
I sort of agree, but I also think there's no reason to view Docker commits any differently to Git commits. Are you screwed if you lose a working .git project, or its maintainer? Well, yeah. But we don't actively worry about that happening all that much because we routinely take precautions like distributing it across developer's machines and servers. Maybe a commit does break, but that's why we didn't just overwrite…
It doesn't have anything to do with a commit breaking anything. It has to do with reproducability. As others have mentioned, a Dockerfile isn't perfect (I'd argue Dockerfile+Nix is pretty close) but at least you don't have to ask "Oh god, what did OJ Ford run manually before commiting the image we use in Prod." That's truly horrific and simply isn't a problem if you use a Dockerfile.
>Not everything's open source.
I don't know what that means. Whether the source is closed or not has zero impact on the use-cases I'm discussing for Docker. Even if the source of the base layer isn't available, it doesn't stop you from using that base layer in a new Dockerfile, at all.
Re: Nix as OS X Package Manager
#107Wait... binaries inside a ~homedir/.dotfile/? Why on earth?
I believe they're just soft links to the latest/appropriate version of the executable under the /nix/... directory.
Re: Nix as OS X Package Manager
#108Earlier quoted context omitted.
The big difference is that nothing about Dockerfiles implies that the processes they perform to build an image are deterministic or repeatable. Will a build step that runs `curl https://github.com/something/whatever` do the same thing in six months that it does today? Docker doesn't help with that at all. Nix improves determinism by (almost) guaranteeing that if you build the same nix expression six months from now,…
You're not wrong, but Docker comes at it from a different angle; Docker expects you to be handing around tagged images, to solve a similar set (but not the same set!) of problems that reproducible builds solve. Ideally, I want _both_ of them: tagged Docker images being sent between environments (with `docker run -e SOME_ENV=testing imagename` for changing the internal config), but reproducible builds in my Dockerfile…
Yes, you can do this. There is a utility "nix-docker" that will convert a Nix configuration file into a BusyBox Docker image (see e.g. http://zef.me/blog/6049/nix-docker)
Re: Nix as OS X Package Manager
#109Earlier quoted context omitted.
The big difference is that nothing about Dockerfiles implies that the processes they perform to build an image are deterministic or repeatable. Will a build step that runs `curl https://github.com/something/whatever` do the same thing in six months that it does today? Docker doesn't help with that at all. Nix improves determinism by (almost) guaranteeing that if you build the same nix expression six months from now,…
You're not wrong, but Docker comes at it from a different angle; Docker expects you to be handing around tagged images, to solve a similar set (but not the same set!) of problems that reproducible builds solve. Ideally, I want _both_ of them: tagged Docker images being sent between environments (with `docker run -e SOME_ENV=testing imagename` for changing the internal config), but reproducible builds in my Dockerfile…
The problem is tagged images are fundamentally broken. If I can't reproduce, bit-for-bit, what is in the tag, how can I vouch for the tag?
Images are nothing but a caching technique for the results of deterministic builds.
If you're using them for any other reason, you have a flawed process that is going to come back to bite you some day.
Re: Nix as OS X Package Manager
#110Wait... binaries inside a ~homedir/.dotfile/? Why on earth?
I believe those are just symlinks to the binaries in /nix/xxxx, so that $HOME/.nix/bin can be added to PATH.