I don't understand what problem it solves
What Is Nix?
241–250 of 344 posts
Re: What Is Nix?
#242Earlier quoted context omitted.
Unfortunately, the security updates introduced in MacOS Catalina have made installing Nix on the latest version of MacOS a fairly involved process.[1] I looked at using it when I rebuilt my computer recently and decided to wait until it was more baked. [1] Catalina restricts which directories can be added to the root dir. Nix uses /nix.
There is a way to deal with the latest round of developer-hostile changes from Apple: https://github.com/NixOS/nix/issues/2925#issuecomment-604501... documents the workaround but if you don't have a direct link it's almost impossible to find because GitHub's UI is terrible.
The problem here really seems to be with nix. The /nix path shouldn't be hard coded. (Security concerns aside, I don't want a package manager to clutter up my root directory.)
Re: What Is Nix?
#243This article is a good explanation of how nix works at a high level, and I'm excited to see nix getting some really prominent support, but for some reason it never tells you what the point of all of this is, so I think many folks might feel turned off by it. In other words, I don't believe it ever compellingly answers the question that constitutes its title. The word "package" doesn't even appear until near the end o…
Isn’t that the same goal as Docker? I’m surprised there’s still no Docker base image for NixOS...
A Docker base image with NixOS doesn't really make sense, since with Nix you wouldn't use Docker for building Docker images, but let Nix make images from scratch.
That's the approach my team is taking, anyways.
https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools
(and as others have noted, you don't need an OS in your Docker image)
Re: What Is Nix?
#244Earlier quoted context omitted.
So... statically compiled executables? Wasn't that tried long ago and it was determined that the user should be able to choose when to upgrade dependencies, such as if a dependency needs an out-of-band update to work on the localhost OS?
Your criticism misses the mark because nix users have the ability to update a dependency and rebuild all of the dependees. With nix, I can update openssl in one place and be sure that everything that depends on it gets re-evaluated. How can I be confident that everything is linking the patched openssl I want when I'm using aptitude, pip, npm, docker, etc?
But what if they're using different versions of OpenSSL?
Re: What Is Nix?
#245Earlier quoted context omitted.
So I understand correctly from this that nix has no binary packages? If so, why not? To me, compiling from source is not strictly necessary to get reproduceability guarantees. It might actually be harmful if you're not carefully checksumming the build products (e.g. cosmic rays messing with complex builds).
You do not understand correctly. Nix users use binary caches[0] instead of building everything from source. You can use the binary cache provided by NixOS, or Cachix[1], or something you set up and host yourself, or all of the above. [0]: https://nixos.wiki/wiki/Binary_Cache [1]: https://cachix.org/
Then why would a build take so long as GP describes?
Re: What Is Nix?
#246Earlier quoted context omitted.
There is a way to deal with the latest round of developer-hostile changes from Apple: https://github.com/NixOS/nix/issues/2925#issuecomment-604501... documents the workaround but if you don't have a direct link it's almost impossible to find because GitHub's UI is terrible.
The problem here really seems to be with nix. The /nix path shouldn't be hard coded. (Security concerns aside, I don't want a package manager to clutter up my root directory.)
It's necessary to hardcode paths in order to ensure that the exact version of a dependency is linked into the executable.
Without this mechanism, nix packages would not be reproducible and self-contained.
Also, the path isn't really hardcoded. You can use a custom path, but that means you can't use binary caches.
Re: What Is Nix?
#247Is Nix only handling the build part (with configure flags etc.) or is it also used to configure services, for example?
I'm not versed in devops/provisioning etc., but say, I had a NixOS system with some server software (mail server, DNS server, whatever).
Would I still want to use Chef/Puppet/Ansible, or is that included in the Nix ecosystem?
Re: What Is Nix?
#248Earlier quoted context omitted.
I mean, if you count the compiler/interpreter (which nix does), realistically that's a bare minimum of two.
Nix comes with its own glibc, so that's 3, although I guess while it is not the default you could compile statically.
If you compile statically, you've got musl, which is still a (build-time) dependency.
Re: What Is Nix?
#249Earlier quoted context omitted.
You do not understand correctly. Nix users use binary caches[0] instead of building everything from source. You can use the binary cache provided by NixOS, or Cachix[1], or something you set up and host yourself, or all of the above. [0]: https://nixos.wiki/wiki/Binary_Cache [1]: https://cachix.org/
Then why would a build take so long as GP describes?
I can't imagine why some unknown people encountered difficulty building some unknown project.
We use Nix to build and deploy our big Haskell monolith along with the operating system itself, and all system dependencies, e.g., PostgreSQL, Redis, Grafana, collectd, influxdb, openssh, ejabberd, Elm applications, etc, and it works fabulously.
Re: What Is Nix?
#250is there still relevance for this way of building in the world of Docker - especially with Packer and LinuxKit ? Packer allows us to create highly repeatable OS builds with all the right configuration and packaging. For example, this is AWS official Packer build for their EKS AMIs - https://github.com/awslabs/amazon-eks-ami
Docker kind of sucks for development though, because you need to reinstall all your devtools into the container and have to wire up your IDE to support docker. With nix, you just write a shell.nix, run nix-shell and can then use your regular tools in that environment.
Also, nix builds are far more reproducible than packer builds. With nix, you get an environment that is guaranteed to be identical down to the hash of every single file as long as you use the same version of nixpkgs. Packer and similar imperative tools typically install whatever version is the latest in the distro repo, and building the image 2 months apart will grant you different artifacts without investing a lot of effort into pinning everything.