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

31–40 of 209 posts

Re: Nix as OS X Package Manager

#31

Post by colemickens »

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 bits placed in the container.

Re: Nix as OS X Package Manager

#33

Post by geocar »

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 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 management is like that: You make some changes, you commit often, fork your instance and try lots of different things. Eventually you find something that works and you tag it. You share your tags with other people. This is an extremely productive way to get work done.

Re: Nix as OS X Package Manager

#34

Post by mitchty »

schneidmaster wrote: post #4

Anyone who's used Nix for a while -- how does package availability compare to Homebrew or Macports? Other than the default.nix thing (which Homebrew also has a version of [1]) are there any other clear benefits to switching from Homebrew? [1]: https://robots.thoughtbot.com/brewfile-a-gemfile-but-for-hom...

The default.nix thing is nothing like what home-brew has. Not really kidding here, nix is like git is to svn. Very different in philosophy.

I can setup scripts that install and configure things for emacs to make sure it always runs in an environment that has all it needs. But with the benefit of not having to have everything installed globally.

I can have multiple versions of whatever installed into /nix at once. But still not have to worry about breaking things that need both versions.

As for package availability, I've not hit any issues. It has most of what I personally need.

What I hit more often is random breakage or having to update derivations that only ever got created or maintained from a linux perspective.

I'd say its in the "developer not afraid to fix broken build problems" category as a package manager. Its not bad, but it is really annoying when you have to revert back to a prior generation because some package you use got updated and now won't build because of its test suite failing.

Random stuff like that happens a few times a month, nothing huge though honestly.

Re: Nix as OS X Package Manager

#35

Post by grhmc »

nickysielicki wrote: post #18
vertex-four wrote: post #13

Earlier quoted context omitted.

The script doesn't run if it downloads. Go read it yourself. What attack vector would you actually be protecting against if you downloaded a .tar.gz full of binaries and extracted it to /, then started installing things with it?

Good point, I didn't look at the script. My point about half-downloads is bogus. Kind of a funny situation. If you look at the script first, you'll notice that it would have been okay for the download to be interrupted and so, assuming everything else is kosher with you, the '| sh' would have been "safe". And if you don't look at the script first, you'd never know that what you just did was "safe." Schroedinger's-pip…

I think this is just "good design," you expect tools to be designed to handle failure in a reasonable way.

Re: Nix as OS X Package Manager

#36

Post by hso1 »

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…

There's a post on building Docker images with Nix: https://news.ycombinator.com/item?id=11502989

Re: Nix as OS X Package Manager

#37

Post by __david__ »

nickysielicki wrote: post #24
oconnore wrote: post #19

Earlier quoted context omitted.

No [1]. If you are installing software from scratch, you must trust the https server that serves it to you. They could publish sha256 check sums to https://nixos.org/hashes , but you would have to trust the https server. They could publish their gpg key to https://nixos.org/gpg , but you would have to trust the https server. Things would be better if we had a reasonable certificate system for verifying open source so…

What do you find inadequate about PGP key-servers?

So you pull the package down and the signature checks out to some key on a pgp key server. How do you know it's the correct key?

Re: Nix as OS X Package Manager

#38

Post by oconnore »

nickysielicki wrote: post #24
oconnore wrote: post #19

Earlier quoted context omitted.

No [1]. If you are installing software from scratch, you must trust the https server that serves it to you. They could publish sha256 check sums to https://nixos.org/hashes , but you would have to trust the https server. They could publish their gpg key to https://nixos.org/gpg , but you would have to trust the https server. Things would be better if we had a reasonable certificate system for verifying open source so…

What do you find inadequate about PGP key-servers?

Where is the web of trust that lets me cryptographically verify that my install.sh file was published by some PhD student in the Netherlands? And unless I trust the https server, how do I know which PhD student in the Netherlands I'm supposed to trust?

If this were software that I had to install multiple times (say there are several updates a year), it might make sense to implement TOFU with a published GPG key -- each successive update would use the same key I imported the first time. However, the nix installer installs a package manager which is self updating, and therefore implements TOFU itself.

Re: Nix as OS X Package Manager

#39

Post by mitchty »

pmahoney wrote: post #29
bydo wrote: post #17

Earlier quoted context omitted.

On that note, is there some valid reason Nix absolutely needs access to / to create /nix? Why can't it live somewhere else? I believe some parts can go anywhere, but /nix is hard coded for the rest, which I'm not entirely comfortable with.

The pre-built binary packages available from the Nix project are all compiled for /nix; this choice is baked in to the binaries, which refer to shared libs via absolute paths for example. I understand this path is configurable, but you'll be compiling everything yourself, unable to use Nix's binary cache. You also risk running into unique problems since everyone else is using /nix

Yep, additionally, /nix is really no different than /usr/local here. Just in a different spot.

I'd recommend everyone try nixos out as well to see why everything (mostly) in /nix is a good idea.

nixos is easily the most un unix unix i've seen, and honestly i can't wait to get rid of apt/rpm/yum/zypper. Not dealing with /some/file/blah being version X or Y in general is so freeing.

Post reply on HN