Which is a poor choice! Picking yum or apt as the model would have been a saner choice! I feel the same way dealing with Arch Linux - being different (read "weird") isn't always better!
> being different (read "weird") isn't always better!
To go further, being different is almost always a bad idea. People are used to how current stuff works; you need a really good reason not to provide the same interface.
What makes Nix the future of package management? I'm not familiar with it so I don't know!
I looked at the web-site and didn't find it clear what it does that Homebrew doesn't, other than being cross-platform (although I recently started using Linuxbrew which has made Homebrew cross-platform-ish for me).
The power of Nix start when you start building your own ~/.nixpkgs/default.nix (but you don't really need to if you don't want to):
{
packageOverrides = pkgs: with pkgs; rec {
all = buildEnv {
name = "all";
paths = [
vim
fish
gitAndTools.gitFull
];
};
};
}
This is the Nix package collection. You can install this package with `nix-env -i all`. What does it do? Install vim, install fish, install git. Not much, and easily doable in Homebrew in much fewer keystrokes.
Now imagine you decided that you don't like vim and want to go with emacs. You change the paths to `paths = [ emacs fish gitAndTools.gitFull ]`. Run `nix-env -i all` again. What does it do now? It uninstall vim and install emacs.
Now that you decided you don't like emacs after all and want to go back to vim. You can just run `nix-env --rollback` and it will happily rollback the change it made to the filesystem made by latest nix-env call, as in, restoring vim at where you expect it to be.
This is the declarative nature of Nix. You declare the state you want the package to be (or the whole system, in case of NixOS) and Nix will figure out how to get to that state. default.nix can also do a lot more things, for example, adding custom packages, overriding versions, changing build flags and much more.
Let's say one day you need to clone the whole setup to other machine, you only need to copy this default.nix and run `nix-env -i all` on that machine and everything is reproduced in the way you expected. This default.nix can also be per-project, allowing collaborators to share the same packages (and custom packages).
If a package system is well designed, having the package for vim on my system shouldn't be doing any harm even if I'm not currently using it, so the system you are describing isn't really any better than just having a list of packages I want installed in a text file.
That is not the point I want to make. Having both Vim and Emacs doesn't really do any harm. You can even have multiple versions of Vim in the same machine, even with different and incompatible dependency version, and Nix will happily manage that. The point is that with Nix collection, it will try to build the system exactly as described without any kind of side effect.
Using Vim isn't the best example (why would someone want multiple Vim?) but the same apply to languages as well. For example if I want to use Python 3.2, but there are handful of utilities that require 3.3+. I can just install 3.2 to my profile and install those utilities with 3.5 without actually exposing 3.5 to my profile.
>I totally agree that nix is the future of package management.
Perhaps, if they clean it up significantly, I think that nix's principles are very sound, but the implementation isn't: it's fine when you are using it as a simple package manager but as soon as you want to do something a bit complex (say building gcc with a different kernel version) you're on your own:
1) half of the documentation makes reference to configuration files which aren't in my version of nix??
2) there is no real mail/news forum for support/help: no IRC isn't enough.
Also Guix switch challenge is incredible from a security perspective: https://www.gnu.org/software/guix/manual/html_node/Invoking-...
Nix should take those things back. Overall, it's a great package manager.