5 ms·

> Main reason for leaving was that Nix package maintainers have to heavily patch all software. Any widely used distros do this. Plus, the statement that you ha

> Main reason for leaving was that Nix package maintainers have to heavily patch all software. Any widely used distros do this. Plus, the statement that you have to patch all packages is false. In many cases, all you have to do is set the right build flags and environment variables, which is handled by standard helpers in nixpkgs. I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen. > Packaging for nix is more like porting software to another operating system. Dramatic, but again, simply not the case. > note that they have automated tools for patching the most common problems, so the problem is even worse. This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros. > I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it. > Moreover, Nix breaks the chain of trust for the language packages. After a quick look, it seems like you can still use the unmodified erlang package manager? The patched version you've mentioned seems to be there for facilitating creation of Nix packages and it looks like the main intent was to remove the ability to download packages from the internet. If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed. > /nix directory is readable by all users, so you cannot use Nix to manage secrets Why not store secrets in a private location, just like you would on any other distros??? What is it that other distros have that Nix is missing? I'm not seeing your point here. With that being said, note that this feature is being worked on, and systemd very recently introduced a new feature for secrets management [1]. > You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities Matbe take a look at buildFHSEnv. > do you really need such degree of reproducibility for your very own dev machine? Yes, it saves me from having to do a clean install of my system every few months. I haven't done a clean install at all the last few years since I started using NixOS. [1]: https://github.com/NixOS/rfcs/pull/59#issuecomment-624723733 https://github.com/NixOS/rfcs/pull/59#issuecomment-624723733

k32 6y ago
> Any widely used distros do this. I've yet to encounter another distro that deliberately breaks 3rd party software the way Nix did it to rebar3 (before it was reverted). > Plus, the statement that you have to patch all packages is false. IIRC `patchShebangs' script runs for any package using stdenv. > I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen. Which distros? Can you share a comparison in number of tests/coverage? > Dramatic, but again, simply not the case. As other commenters mentioned, software written for GNU\Linux often assumes FHS. NixOS breaks FHS, and has to patch soft to work around that. > This is a good thing. How so? > This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros. Other major distros don't break FHS, therefore they don't need to patch trivial things like shebangs. > All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it. It depends on your threat model. Mine is stricter. > If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed. Once again, it breaks the cryptographic chain of custody set by the upstream. In my threat model that's not acceptable. I tend to trust the upstream more than the distro. > Why not store secrets in a private location, just like you would on any other distros??? Secret provisioning is by far the most difficult DevOps problem, and it can go catastrophically wrong for all too many reasons. Nix not only doesn't help, but also introduces additional footguns with world-readable configuration files. > What is it that other distros have that Nix is missing? Other distros have FHS. FHS accounts for secret management, among other things. > Yes, it saves me from having to do a clean install of my system every few months. Ok, though I never had to do a clean install of GNU\Linux either on my dev machine.
- aidenn0 6y ago
  The fact that they reverted the rebar change suggests that or wasn't intentional.
- soraminazuki 6y ago
  > I've yet to encounter another distro that deliberately breaks 3rd party software the way Nix did it to rebar3 Except that your anecdote is completely misleading given that the patched version was intended for creating Nix packages. You could've just used the unmodified version instead. Furthermore, upstream developers complain about how distros are breaking their software all[1] the[2] time[3]. Again not a Nix specific problem. Nix even alleviates some of the problems because you can use different versions of the same software, meaning that different packages don't have to share dependencies as aggressively as other distros do. > Which distros? Can you share a comparison in number of tests/coverage? Arch, Debian, CentOS, and Homebrew, though the last one isn't strictly a Linux distro. I can't possibly count the numbers given that the sheer number of packages available, so it's based on experiences at looking at package definitions. I tend to check package definitions across distros a lot to write packages fir Nix. > It depends on your threat model. Mine is stricter. If you have a problem with software projects accepting outside contributions even if they go through review, you have a problem with using free and open source software in general. It makes me wonder how you even manage to use the Linux kernel. > Once again, it breaks the cryptographic chain of custody set by the upstream. In my threat model that's not acceptable. Then use the unmodified rebar3 for your project instead. But anyways, if your threat model involves not trusting SHA256, you likely have a problem with your said cryptographic chain of custody too. > Nix not only doesn't help, but also introduces additional footguns with world-readable configuration files. > FHS accounts for secret management, among other things. That's an outright lie. NixOS doesn't prevent you from storing secrets in a file and applying your usual UNIX permissions. FHS has absolutely nothing to do with it. [1]: https://github.com/pypa/pip/issues/5599 https://github.com/pypa/pip/issues/5599 [2]: https://web.archive.org/web/20181021091049/https://github.com/heroku/homebrew-brew/issues/5 https://web.archive.org/web/20181021091049/https://github.co... [3]: https://twitter.com/videolan/status/1153963312981389312 https://twitter.com/videolan/status/1153963312981389312

k32 6y ago

> Any widely used distros do this. I've yet to encounter another distro that deliberately breaks 3rd party software the way Nix did it to rebar3 (before it was reverted). > Plus, the statement that you have to patch all packages is false. IIRC `patchShebangs' script runs for any package using stdenv. > I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen. Which distros? Can you share a comparison in number of tests/coverage? > Dramatic, but again, simply not the case. As other commenters mentioned, software written for GNU\Linux often assumes FHS. NixOS breaks FHS, and has to patch soft to work around that. > This is a good thing. How so? > This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros. Other major distros don't break FHS, therefore they don't need to patch trivial things like shebangs. > All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it. It depends on your threat model. Mine is stricter. > If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed. Once again, it breaks the cryptographic chain of custody set by the upstream. In my threat model that's not acceptable. I tend to trust the upstream more than the distro. > Why not store secrets in a private location, just like you would on any other distros??? Secret provisioning is by far the most difficult DevOps problem, and it can go catastrophically wrong for all too many reasons. Nix not only doesn't help, but also introduces additional footguns with world-readable configuration files. > What is it that other distros have that Nix is missing? Other distros have FHS. FHS accounts for secret management, among other things. > Yes, it saves me from having to do a clean install of my system every few months. Ok, though I never had to do a clean install of GNU\Linux either on my dev machine.

aidenn0 6y ago
The fact that they reverted the rebar change suggests that or wasn't intentional.
soraminazuki 6y ago
> I've yet to encounter another distro that deliberately breaks 3rd party software the way Nix did it to rebar3 Except that your anecdote is completely misleading given that the patched version was intended for creating Nix packages. You could've just used the unmodified version instead. Furthermore, upstream developers complain about how distros are breaking their software all[1] the[2] time[3]. Again not a Nix specific problem. Nix even alleviates some of the problems because you can use different versions of the same software, meaning that different packages don't have to share dependencies as aggressively as other distros do. > Which distros? Can you share a comparison in number of tests/coverage? Arch, Debian, CentOS, and Homebrew, though the last one isn't strictly a Linux distro. I can't possibly count the numbers given that the sheer number of packages available, so it's based on experiences at looking at package definitions. I tend to check package definitions across distros a lot to write packages fir Nix. > It depends on your threat model. Mine is stricter. If you have a problem with software projects accepting outside contributions even if they go through review, you have a problem with using free and open source software in general. It makes me wonder how you even manage to use the Linux kernel. > Once again, it breaks the cryptographic chain of custody set by the upstream. In my threat model that's not acceptable. Then use the unmodified rebar3 for your project instead. But anyways, if your threat model involves not trusting SHA256, you likely have a problem with your said cryptographic chain of custody too. > Nix not only doesn't help, but also introduces additional footguns with world-readable configuration files. > FHS accounts for secret management, among other things. That's an outright lie. NixOS doesn't prevent you from storing secrets in a file and applying your usual UNIX permissions. FHS has absolutely nothing to do with it. [1]: https://github.com/pypa/pip/issues/5599 https://github.com/pypa/pip/issues/5599 [2]: https://web.archive.org/web/20181021091049/https://github.com/heroku/homebrew-brew/issues/5 https://web.archive.org/web/20181021091049/https://github.co... [3]: https://twitter.com/videolan/status/1153963312981389312 https://twitter.com/videolan/status/1153963312981389312