It's very important for us to get such feedback. This allows us to improve and move forward.
In Nix defense I think it's not worth comparing stability yet, although that is the most important aspect for users.
What matters currently is how many smart people grasp the idea why we're fundamentally better by architecturing the language and packaging problem itself and any help we get to move us forward.
For fair comparison you should note that we have ~800 contributors, probably more than 90% are on Linux. Meanwhile Homebrew packages have almost 6000 contributors.
We have recently added 4 macs to our build farm at http://hydra.nixos.org/machines, but we desperately need more developers that care. Not 6000, just a few more.
I played around with it and ended up getting rid of it for basically the same reasons, but I have to say that I was impressed by how easy it was to remove. When I got rid of Homebrew I had to run a script that did a bunch of non-obvious things, when I got rid of Nix I did rm -rf /nix && rm -rf ~/nix-* and removed a line from my zshrc.
My main complaint with Nix itself was that Vim was built without python support so Youcompleteme didn't work and it wasn't obvious how to recompile it to have python support, but the experience was nice enough that I'll give it another go later on.
I've never used Nix for OS X, but I can confirm that the UI can definitely use some work, and the proposed changed which are in the pipe look fantastic.
But, comparing Nix on the simple operations is like reviewing a sports car after only driving it in a school zone. There is so much more that Nix provides that homebrew doesn't even come close to.
Nix has made managing of my servers way easier then anything I have tried before and I have no intentions of changing away any time soon.
I tried Nix on OS X after a recent HN topic suggested it. I hate Homebrew with a passion (it's fine initially but, over time, it's always created a hard-to-clean-up mess for me), so I was looking for something that could replace it for most unixy things I need to install.
I immediately ran into a showstopper bug that they've had for some time now. Apparently, they've focused on NixOS and the CA certificate configuration is borked on other platforms. This means Git, Curl and anything else that tries to use the standard OS certificate store will fail certificate validation. I know it's only one issue, but it was pernicious enough for me to nuke my Nix install and move onto something else.
At the moment, the best I can find for OS X is Rudix. The selection of available software is pathetic compared to Homebrew and Nix, but a lot of the core stuff is there and it's all packaged as a .pkg, which makes it really easy to cleanly erase installed software.
> At the moment, the best I can find for OS X is Rudix. The selection of available software is pathetic compared to Homebrew and Nix, but a lot of the core stuff is there and it's all packaged as a .pkg, which makes it really easy to cleanly erase installed software.
Apologies for hijacking a Nix thread, but I'd love your views on our OS X binary package sets[0]. We currently ship over 14,000 pre-built signed packages, all self-contained under /opt/pkg, and easy to search/install/remove using pkgin which has a familiar feel to anyone used to apt-get/yum/etc.
The packages are continuously built from pkgsrc trunk so should be reasonably up-to-date, and we try to be responsive when users need newer versions or packages built with different options.
So far the feedback has been positive, but I'd love to see more use-cases so we can improve the experience for everybody. Thanks.
> packaged as a .pkg, which makes it really easy to cleanly erase installed software.
In theory, but there's no package uninstaller and OS X installer packages are neither pure nor idempotent.
While you can remove the files installed by one, there's no straightforward or platform-provided way to undo the changes made by their (generally unknowable) install scripts.
Incidentally, Apple shipped an Xcode uninstaller; written in perl, it used lsbom and pkgutil to collect and subsequently remove the files owned by all the com.apple.dt packages complement the system-owned files or files installed by other packages.
Yes, it's not as clean as Nix when it comes to uninstall, but using piping pkgutil to rm has never gotten my machine in as borked of a state as Homebrew inevitably does. Also, many .pkg files provide an uninstall script of their own which is almost always reliable.
There's many variations of this issue open. See https://github.com/NixOS/nixpkgs/issues/3382 for an example. Most are still not closed and have been open for long enough that it doesn't seem hopeful that they'll be fixed soon.
I haven't used Nix much on the desktop as a "user" so I'll just say some things about development.
It basically boils down to one thing: isolation.
Everything you use will be described by Nix, no system libraries or commands. The only think you rely on is the kernel of the host.
Not only is my environment almost exactly the same from development to CI to deployment but I can actually copy the program exactly as it was built between them (assuming compatible kernel and architecture). For example when I push to my master branch CI automatically runs a build, tests the code with the exact versions of the libraries it will be using in production then uploads them to a binary cache (which is essentially the nix equivalent of a package server), Now I can just install the program on my production servers and it will use the exact versions of the libraries that I tested it with with almost no reliance on the underlying system.
And NixOps makes this even more awesome: after a build it can automatically push it onto your servers. Or it can automatically set up Virtualbox VMs for each machine, if you want to set the build locally. Or AWS instances, if you have too many for it to be practical locally.
I'm guessing one of the major reasons more packages are "broken" for macos is there is a CI system running for linux/nixos (travis) and not one for macos. So macos breakages can slip in easily.
If a passionate mac advocate wanted to take on the responsibility of setting up & running a CI machine and hooking it up to the github PRs, I can only imagine it being a good thing...
The real solution is we need to use our CI, Hydra, to build all PRs.
Now Travis doing this is interesting because last time people looked there was no hosting for OS X that wasn't ridiculously expensive, so we've literally had people donate Mac Minis.
I've started looking at this. Part of the problem is that nix wants (reasonably) to do "everything itself", including (for example) bundling the OS X SDKs itself.
At the moment that's broken (the 10.9 SDK is installed in 10.11, then links against some 10.11 libraries, which is blocking mplayer). I don't have the knowledge to fix it.
homebrew and fink have had the same problem (deciding when to link against system libraries and when to try to rebuild) -- hopefully nix will get over this hurdle.
The correct answer for Nix is to never link against a library provided by the system. Nix provides its own bootstrap binaries and it must be done that way for the sake of reproducibility.
well, there's xcode-select to chose the SDK you want which kinda implies the availability of multiple – currently for example swift 2.2 and 3.0.
I'm tempted by the "1-environment" idea but homebrew has done such an excellent job in comparison to fink/port, I';; stay loyal. Also wondering if those two projects couldn't profit from some code sharing?
Out of interest, how'd you get your OS X builds set up? I had to do quite a lot of searching before I found a company [2] willing to lend PureDarwin [1] a box for a while.
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.
Sure, now, but was that the case 10 years ago? I'm not arguing its the best choice but more that you need to take into account the age of things. Being exposed to it just now doesn't mean it was created in that situation. I'd say 10 years ago rpm based distributions were the more dominant and emulating rpm was a fine choice.
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.
Nix is not great for casual Linux desktop usage - I tried installing the Atom editor, and cancelled when I saw X11 being downloaded. You might as well run NixOS in a VM.
It's hard to say what caused this without more information, but the flip side is that it demonstrates the power of Nix. Everything required to get Atom working--all the way down to something as basic as the display server--is explicitly declared in the configuration and can be downloaded and installed with one command. So although this wasn't what you intended, Nix was actually doing what it is supposed to do: acquire every necessary component (as per the specification) for your application to work.
This is true, literally, of every package manager that came before Nix and every one that will come after. It's fundamentally what a package manager is and does. This isn't the power of Nix -- it's table stakes.
Isn't generating and installing a dependencies tree one of the most basic tasks of a package manager, at least since apt and similar came about in the late 90s?
This is a feature. Nix is completely isolated from the host system. It manages its own dependency tree. Using libs and other things from the host system would be both brittle and nondeterministic, negating the reason why Nix is so novel in the first place.
Ah, I can understand the concern on OSX (or other Linux distros). Earlier in the chain, you wrote "Linux desktop" -- which, to me, implied using NixOS :).
Wayland and Weston work and there's also non-Weston compositors (window managers) like sway, kwin, gnome and more that actually work decently enough with Xwayland integration for running legacy (X11) apps.
What do people do about packages being old? Many of their front facing server packages are not being updated. Presumably, they have quite a few security issues in them
Updating packages is generally easy and takes 10 minutes of your time (including sending a pull request) once you've figured out how it works. Please do so if you're a NixOS user - NixOS has far, far fewer people working on it than, say, Debian.
Nix looks cool on OSX, but trying to install something like elixir from scratch involves my macbook air compiling packages for at least 40+ minutes before I ctrl-break which is a no go.
I thought Gentoo was cool in the early 2000s when I didn't do sysadmin work for my job. I'm not waiting an hour or two to install a package anymore.
I'm sure this will improve when more precompiled packages are released for OSX when it is more popular.
It's very important for us to get such feedback. This allows us to improve and move forward.
In Nix defense I think it's not worth comparing stability yet, although that is the most important aspect for users.
What matters currently is how many smart people grasp the idea why we're fundamentally better by architecturing the language and packaging problem itself and any help we get to move us forward.
For fair comparison you should note that we have ~800 contributors, probably more than 90% are on Linux. Meanwhile Homebrew packages have almost 6000 contributors.
We have recently added 4 macs to our build farm at http://hydra.nixos.org/machines, but we desperately need more developers that care. Not 6000, just a few more.