Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Maybe I was just unlucky... But when I tried Nix, the first thing that happened was that it did not deliver what it promised. The package was not properly isolated, so it ended up depending on something from /usr//bin. This was pretty disappointing for a first try.

Also, while this is a minor cosmetic thing, I highly dislike the location of the nix-store. It doesn't belong in /

and*, long path names (due to the hashes) are very impractical to use. All in all, I hear a lot of good things about Nix, esp. from the Haskell community, but whenever I try it, I develop a deeply rooted dislike for the implementation of the concept.



> the package was not properly isolated, so it ended up depending on something from /usr/bin.

I don't know when you last used Nix, but Nix now enforces sandboxed builds by default so it should be better at catching these kind of things during packaging. But note that isolation in Nix is mostly a build time thing, and it does not prevent running programs from accessing filesystem paths in /usr. You could still fire up a bash prompt and enter "ls /usr/bin", there's nothing stopping you from doing so.

> I highly dislike the location of the nix-store. It doesn't belong in /

I see many people express this sentiment, but I'm not sure what's wrong with /nix/store when you've mostly[1] abandoned /usr. Nix is fundamentally incompatible with traditional Unix directory layouts.

> long path names (due to the hashes) are very impractical to use

That's why you never need to specify them directly. You could either install packages globally and get it symlinked into /run/current-system/sw/bin or ~/.nix-profile/bin, both of which are included in PATH, or use nix-shell and direnv to automatically add packages to PATH whenever you enter a specific directory.

[1]: "Mostly," because /usr/bin/env is kept for compatibility




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: