3 ms·
Why would anyone use it versus its competitors? Here's why: 1. You can uninstall a thing and it will no longer affect your computer. 2. Your environment will
by GlennS 8y ago
Why would anyone use it versus its competitors? Here's why:
1. You can uninstall a thing and it will no longer affect your computer.
2. Your environment will work the same way on your colleague's computer.
3. Your environment will work the same way years down the line.
4. Your environment will probably work the same way years down the line, even after you've applied security updates. If it doesn't, it will probably be clear what's broken/different.
5. You can install many different environments on the same machine, and they will probably all work. On the rare occasions where they don't, it will be because they interact with system services or limited system resources, and it will be clearly defined how that happens.
6. All this is true across most programming languages, system services, and all sorts of tools.
7. You can combine this with direnv (or direnv-mode for Emacs) to make it so that you can just cd into a directory and magically get all the dependencies.
8. You can put the recipe for your environment in Git.
Other than Nix and Guix, I don't know of any tool where these things are true. Docker and Virtual Machines get sort of half way, but tend to rot over time.
But yes, it's difficult to learn and in many cases the usability is poor.
Final bonus point:
9. Nix is so good that it can even make Autotools work correctly.
- deleted 8y ago[deleted]
- r32a_ 8y agoI don't care about those features, I just wanted to download the packages and it's dependencies and in the end it never did that. Nix is probably good for many things, but it's not simple and to me it's trying to do too many things.
- nerdponx 8y agoThat is not what "overengineered garbage" means.
- adev_ 8y agoI'm using Nix to download packages and its dependencies to a cluster of 250 nodes around 10 times per week. And it always does that.
- sparkie 8y agoThe reason you can "download a package and its dependencies" with other package management systems, is not because they are technically superior, but because they've had countless man-hours of contributors making sure that their central repository contains packages which work well together. As soon as any assumption changes, like for example, adding a third-party application repository, then you need to concern yourself with all of the issues mentioned above, or you'll end up wasting your days on manually building and installing packages locally. The point of Nix is to do this once only. If you build and it runs, it should do the same for everyone, regardless of what other repositories they use. Package management becomes completely modular and does not depend on some centralized state like a central software repository, or the state of your machine at time of install. Nix isn't trying to do too many things. It's actually much, much simpler than using a bunch of semi-compatible tools which all attempt to do similar things in ad-hoc ways. Nix is just a dependency management system where dependencies are specified by their content hash. Your machine contains a content-addressable store of objects which can be precisely referenced by any other object. It takes the guesswork out of dependency management. Other dependency managers effectively run a search engine to try and find an appropriate dependency from some search terms.