Live data from Hacker News

Nix as OS X Package Manager

ariya.ofilabs.com

71–80 of 209 posts

Re: Nix as OS X Package Manager

#71

Earlier quoted context omitted.

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?

Generally, the key already exists on your system, as it's coming through the official channels. If you decide to add the cert manually, you can inspect the key and see who has signed it, and decide your level of trust.

With HTTPS, you only ever have the choice of trusting the 1000+ CAs in your keyring.

Re: Nix as OS X Package Manager

#72
post #35

Earlier quoted context omitted.

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.

You might expect it, but if you're blindly running `curl > sh` (as recommended), you can't be certain.

Re: Nix as OS X Package Manager

#73
post #52

Earlier quoted context omitted.

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

> I understand this path is configurable, but you'll be compiling everything yourself, unable to use Nix's binary cache Not necessarily. Homebrew compiles stuff for a special prefix then substitutes your own prefix when you install the binary. It doesn’t work with everything (that’s why some compiled packages are available for /usr/local only) but it’s a start.

Nix uses rpaths on Linux (install names on OSX) to fix the precise location of dynamically linked dependencies, and it also patches the paths to executables (e.g. In string laterals or shebangs) needed at run time. To change the location of a binary, one would have to patch the dependents so that /nix/store is replaced with the new prefix, which is generally not possible to do, unless the new prefix has the same length as the old prefix - in which case you can just sed every file.

Homebrew just assumes that the needed executables will be available on $PATH and that the dynamic linker will find libs in /usr/lib or /usr/local/lib.

So yes, you really would need to recompile everything if change the prefix from /nix/store to something else.

Edits: fixed spelling and structure from originally typing via phone.

Re: Nix as OS X Package Manager

#74
post #60

Why use nix when pkg-src has been available on Darwin for over 15 years, boasts more packages, and has decades of support (plus Jonathan Perkin and the guys over at Joyent)? Why people assume the gross project known as homebrew (and the better macports, where homebrew gets all of their real package patches) are the only two package managers on OS X/Darwin is perplexing to me... Not to say nix is not interesting, but…

Does it allow you to install several versions of a package and use everything down to compiler version and compilation flags as dependencies?

Re: Nix as OS X Package Manager

#76

What happens when packages need to store data? For example, installing Datomic via Brew will result in databases being stored in: /usr/local/Cellar/datomic/0.9.5206/libexec/data How would that work with Nix? Would the data live under /nix? And most importantly, would that data get squashed because of some kind of idempotency assumptions that Nix might make?

/nix is mounted readonly, only the special nix user can write to it. Data goes in /var or similar.

Re: Nix as OS X Package Manager

#77

> curl https://nixos.org/nix/install | sh Stop doing this. Look, even if you are rolling your eyes and thinking, "it's https and I'm not Ed Snowden, I think I can afford the risk for the benefit of an easy install process", what happens if curl is interrupted? Are you excited at the prospect of a half-ran install script that you didn't even look at?

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…

> If you are installing software from scratch, you must trust the https server that serves it to you

This is incorrect - you are forced by `curl | sh` to trust all of the 1000+ CAs in your OS' keystore. And if you can't trust all of them (since some have given out Google certs before, you can't), how can you trust what you're getting over HTTPS?

With hashes, they are not typically served from the same domain. That's the minimum level of protection for the user.

Signing with a key is another level of protection; it lets the user (not the OS) decide the level of trust, and even verify the key with the author of the package via a completely separate channel.

Now the question really becomes, why doesn't the provider use the existing (secure) channels of software distribution? RPMs, DEBs, installer packages for Macs, MSAs for Windows?

Re: Nix as OS X Package Manager

#78

What happens when packages need to store data? For example, installing Datomic via Brew will result in databases being stored in: /usr/local/Cellar/datomic/0.9.5206/libexec/data How would that work with Nix? Would the data live under /nix? And most importantly, would that data get squashed because of some kind of idempotency assumptions that Nix might make?

>would that work with Nix?

Yes.

>Would the data live under /nix?

No, Datomic will be built with another default data directory.

>would that data get squashed because of some kind of idempotency assumptions that Nix might make?

No, since data is stored separately.

Re: Nix as OS X Package Manager

#79
post #49

I recently set up a new server for a toy project with nixos and it was a pleasurable experience, even if I did have to pull together several sources of somewhat thin documentation. Recommended. Next time I set up a new dev machine I'm going to give nix a try for dev environment management. Using nixops to push a closure from your local system up to ec2 is very pleasing. It feels like the future.

NixOS is pretty awesome :) For anyone trying to start with NixOS, I suggest trying it out on a small DigitalOcean server. Check out this[0] blog post on some hints how to install NixOS there. A big help is IMO to get a solid understanding about how nix itself works[1]. Also check out some existing `configuration.nix` files on GitHub. Just google for "github configuration.nix". This might give you some inspiration wha…

Is there a reason you suggest trying it on DO instead of a local VM?

Re: Nix as OS X Package Manager

#80
This sounds exactly like what homebrew does. It also installs under /usr/local and does not touch anything else. What does nix package manager provide that homebrew does not? (from a user point of view)
Post reply on HN