Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix as OS X Package Manager

ariya.ofilabs.com

Post reply on HN
Print view View original

131–140 of 209 posts

Re: Nix as OS X Package Manager

#131

Post by cstrahan »

arm wrote: post #129

It seems like when installing Nix, it needs to create a 'nix' directory in your root directory. While I haven’t tried installing Nix yet myself, I’m guessing this probably won’t work on OS X v10.11 El Capitan due to System Integrity Protection¹. You’ll have to temporarily turn it off² first before attempting to install Nix (and then optionally turn it back on after). ―――――― ¹ — https://derflounder.wordpress.com/2015/…

Ooh, that's an excellent point -- thanks for bringing it up. I've had Nix installed since early 2014, so I haven't run into any trouble with SIP yet. Looks like we might need to update our docs, and maybe have the installer give a helpful tip.

Re: Nix as OS X Package Manager

#132

Post by koverstreet »

thejosh wrote: post #97
benley wrote: post #56

Earlier 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,…

YES. Finally someone understands what really annoys me when I say that docker isn't 100% reproducible if you aren't using version pinning or something similar. If you have 2 developers, and one of them does a build the next day, you could have them with two different versions of a package when the version went up.

That isn't even the bad part - the bad part is that give some big complicated docker image (or any build in general!), you really have no practical way of knowing what's different.

That should scare people.

Re: Nix as OS X Package Manager

#133

Post by mgkimsal »

thejosh wrote: post #97
benley wrote: post #56

Earlier 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,…

YES. Finally someone understands what really annoys me when I say that docker isn't 100% reproducible if you aren't using version pinning or something similar. If you have 2 developers, and one of them does a build the next day, you could have them with two different versions of a package when the version went up.

sounds like 'emerge hell' from gentoo 12 years ago.

Re: Nix as OS X Package Manager

#134

Post by koverstreet »

drewcrawford wrote: post #118
rdtsc wrote: post #15

When I first heard about Docker, I thought it did what Nix does. Then someone handed me a docker image saying, "I got this working on my laptop, deploy this. Isn't this great!". I had no idea how they arrived at that configuration. If something happened to them or that image, I wouldn't have known how to reproduce that "working state". So I am happy to see Nix / Guix become popular. It is what I imagined package mana…

But how do you reproduce the dpkg packages? When your friend hands you a deb, instead of a docker image, what have you accomplished as far as knowing how they arrived at their configuration? Debs are also binary blobs, just more of them, and separately. From what I can see, there are two philosophically pure approaches to software packaging. Either we can build everything from source, so that we have reproducibility…

It is a major problem - that's why debian has been on a major push for reproducible builds too.

Re: Nix as OS X Package Manager

#135

Post by yarou »

I demoed NixOS a few years back when I was wrangling with the Haskell ecosystem.

I was pleasantly surprised, as I could rollback the entire state of my system from GRUB itself if anything went screwy.

Re: Nix as OS X Package Manager

#136

Post by cstrahan »

colemickens wrote: post #31
rdtsc wrote: post #15

When I first heard about Docker, I thought it did what Nix does. Then someone handed me a docker image saying, "I got this working on my laptop, deploy this. Isn't this great!". I had no idea how they arrived at that configuration. If something happened to them or that image, I wouldn't have known how to reproduce that "working state". So I am happy to see Nix / Guix become popular. It is what I imagined package mana…

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…

As another use points out, there was some relevant discussion earlier on HN about using Nix+Docker: https://news.ycombinator.com/item?id=11502989

Copying a comment I left on that blog post:

---

Q: "What does building a a Docker image using Nix give you over creating a regular Dockerfile to build a Docker image?"

A:

* Better abstraction (e.g. the example of a function that produces docker images)

* The Hydra build/CI server obviates the need for paying for (or administering a self hosted) docker registry, and avoids the imperative push and pull model. Because a docker image is just another Nix package, you get distributed building, caching and signing for free.

* Because Nix caches intermediate packages builds, building a Docker image via Nix will likely be faster than letting Docker do it.

* Determinism. With Docker, you're not guaranteed that you'll build the same image across two machines (imagine the state of package repositories changing -- it's trivial to find different versions of packages across two builds of the same Dockerfile). With Nix, you're guaranteed that you have the same determinism that any other Nix package has (e.g. everything builds in a chroot without network access (unless you provide a hash of the result, for e.g. tarball downloads))

---

IMO, NixOS almost subsumes Docker. Where Docker gives you a way to guarantee that the contents of an image will be the same across two machines, it does little to ensure that building that image from a given Dockerfile is a deterministic. One of Docker's neat tricks is using layers to try to save on disk util -- but even then, Nix beats Docker; if you start two different containers using Nix packages, the common packages are shared across both containers, whereas two different Docker images with an uncommon base would not share the common files.

Docker mostly looks like someone set out to answer two questions:

1. How can we work around all of the problems inherent in conventional package management so we can have a smidgen of determinism?

2. How can we have a relatively nice/cohesive UI around launching/inspecting containers and managing networking/bind-mounts?

#1 can be side-stepped entirely with a package manager that doesn't cause all of those problems in the first place (Nix/Guix).

#2 is still quite useful, but would have been better served as layering on top of something like Nix or Guix (not that I really approve of the "wannabe systemd" daemon approach that Docker employs (all while being, ironically, rather difficult to use with systemd: https://lwn.net/Articles/676831/ )).

Edit: grammar

Re: Nix as OS X Package Manager

#137

Post by technomancy »

jb55 wrote: post #83
lfam wrote: post #50

Earlier quoted context omitted.

In Guix, we address this problem with grafting. Rather than rebuild everything that depends on the fixed glibc, we build the fixed glibc, then rewrite all references to the old glibc to refer to the new one. That rewriting happens in new copies of the referring packages, of course, since the "store" is immutable. https://www.gnu.org/software/guix/manual/html_node/Security-... https://savannah.gnu.org/forum/forum.php?…

Nix has a way of doing this as well, just needs a better UX (like most of nix).

> just needs a better UX

Luckily guix is a better UX for nix. =)

Re: Nix as OS X Package Manager

#138

Post by ecnahc515 »

xyzzy_plugh wrote: post #109
girvo wrote: post #104

Earlier quoted context omitted.

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.

You solve it by signing the image. Sometimes you just won't be able to get a completely reproducible build processes that's fully deterministic, so Nix cannot fix this problem entirely. Additionally, sometimes you just don't have time, or experience to take another program/tool you didn't write and package it up such that it never downloads things from the internet.

It's a hard problem to solve, and Nix helps a lot, but it's not going to fix all the problems, which is why we should care more about trusting the packager to package something relatively reproducible and sign it so that we it can be vouched for.

Re: Nix as OS X Package Manager

#139

Post by aseipp »

didip wrote: post #119

Is there a way to install packages on user space without proot? Why does it need /nix?

You can install packages by installing nix into your homedir. But you will never get binary packages this way.

The reason is because when the software is compiled, it's stashed in the /nix directory, and might refer to other artifacts in /nix. For example, zlib.so exists in /nix/store/zlib-.../lib/zlib.so, and links to glibc.so, which exists in /nix/store/glibc-.../lib/libc.so.6. So if you want to install zlib and get binary packages, you need to first install glibc. And you need to put glibc in the place that zlib will expect it.

Post reply on HN