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

> A lot of Nix-based package builds will burn Nix store paths directly into the binary

I didn't know that, sounds like a bug. Maybe something can be done to make it easier to know that this is the case for your build.

I'd still think that by refusing to build things with unspecified inputs, nix prunes a whole category of problems away which then don't bite the distro maintainers, but maybe that's wishful thinking.

I'll continue to use it because it's nice to come to a project I haven't worked on in a few years and not have to think about whether it's going to now work on this machine or figure out what the underlying language-specific commands are--but if there were ways to tweak things so that others have this feeling also, I'd like to know them.



I didn't know that, sounds like a bug. Maybe something can be done to make it easier to know that this is the case for your build.

It's a feature. E.g. if a binary needs to load data files, it needs to know the full path, or you are back to an FHS filesystem layout (which has a lot of issues that Nix tries to solve).

I'd still think that by refusing to build things with unspecified inputs,

I haven't followed development of traditional Linux distributions, but I am pretty sure that they also build in minimal sandboxes that only contain specified dependencies. See e.g. Mock: https://github.com/rpm-software-management/mock


Oh I'm sure they do build in sandboxes... my point is that those builds are more likely to succeed on the first try if the app dev also built in a sandbox. If you let nix scold you for tempting fate and relying on the output of an unchecked curl, that's one fewer headache for whoever later tries to sandbox your stuff.




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

Search: