I can vouch for the immense improvement Nix has made to my software development process. I use NixOS on my desktop and laptop. At the OS-level, it gets a lot of things right: reproducible, immutable system configs; lightweight containers; devops with declarative configs. At a software project level, nix-shell is an indispensible tool. Compilers and interpreters aren't even part of my system-wide config; instead each project has it's own shell.nix file that installs all dependencies I need on the fly without polluting system state or virtualization. Nix is a god-send, and the developers that contribute to it are nothing short of awesome!<p>The area that needs improvement is the documentation. Once you learn the Nix language, reading the source code is pretty helpful, but it would be nice to make it more approachable. For example, the nixpkgs repo has a bunch of Nix helper functions that are useful to developers when writing their own packages, but these functions' documentation is either buried in a long manual, or non-existent.
That article on "What is Nix and .. " does not contain the words "Nix is a..." A quick read gave a vague sense that it was about installs and file paths so maybe something package-related? Nothing definite.<p>If you click through to <a href="https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-try.html" rel="nofollow">https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t...</a><p>you will see "Nix is a purely functional package manager and deployment system for POSIX"
My experience with Nix was a real pleasure, and a complete failure.<p>I set out with the goal of building a development environment for a software I was working on. I thought - Nix sounds like a better Docker, where it's possible to choose package versions independently of the rest of the system. It's perfect for testing!<p>I found the package description language refreshing - it was powerful without getting <i>too</i> complicated. Over the course of a couple of days I was able to adapt a few packages and create my own too, with the build environment.<p>It was almost finished, but the last problem remained: installing CUDA and the userspace portion of the Nvidia driver. It's not rocket science – I thought – all I need is a few .so's, it even works with Docker.<p>Alas, after battling Nix for another couple of days, trying to use generic GL, installing the Nvidia one, ignoring it altogether or trying to using the host version - I gave up. I found no way to build a package linked against OpenGL that would actually work.<p>Despite that, I hope to use Nix with a different project in the future.
I'm very excited about Nix and the possibilities that it opens.<p>If you want to learn more about Nix, I suggest starting with this excellent article on InfoQ: <a href="https://www.infoq.com/articles/configuration-management-with-nix" rel="nofollow">https://www.infoq.com/articles/configuration-management-with...</a><p>I also gave a talk about why I think Nix is so great: <a href="https://vimeo.com/album/4676161/video/223525975" rel="nofollow">https://vimeo.com/album/4676161/video/223525975</a><p>Finally, I highly recommend the PhD thesis that Nix is based on: <a href="https://nixos.org/~eelco/pubs/phd-thesis.pdf" rel="nofollow">https://nixos.org/~eelco/pubs/phd-thesis.pdf</a>
I recently wrote about my experience using NixOS on my VPS [1]; it's truly a very different way of approaching systems administration and Nix is at the heart of it. While I think the Nix expression language has a negative impact on usability, Nix still ends up being a net gain for not only entire OSs, but also reproducible environments for packages on many other OSs.<p>1: <a href="https://blog.jeaye.com/2017/07/30/nixos-revisited/" rel="nofollow">https://blog.jeaye.com/2017/07/30/nixos-revisited/</a>
On my macOS work machine, Nix has replaced Homebrew. The ability to switch between generations of your system state [1] when a new install goes awry is underrated, IMO.<p>[1] <a href="https://nixos.org/nix/manual/#sec-profiles" rel="nofollow">https://nixos.org/nix/manual/#sec-profiles</a>
We used Nix to vastly simplify the build process of Simula: <a href="https://github.com/SimulaVR/Simula" rel="nofollow">https://github.com/SimulaVR/Simula</a><p>Simula is a bleeding edge VR Desktop project for Linux; virtually all of its dependencies are highly novel and require building from source for almost any distro. Nix allowed us to reduce the effort to building our project from 1hr of sifting through build documentation to a single build command.<p>Nix's only issue is that it so far can't handle OpenGL dependencies very well. I'm not sure if this is something in principle it cannot handle, or if it just hasn't been done yet. I'm praying it's the latter.
I recently wrote a blog post about how we use Nix at Pinterest (just the package manager, not the OS). It helps us give all developers and CI an identical environment. On iOS, we run most build commands and other tools through the nix-shell. New engineers set up their environment by just running a script that installs nix and enters the shell.<p><a href="https://medium.com/@Pinterest_Engineering/continuous-integration-for-ios-with-nix-and-buildkite-ef5b36c5292d" rel="nofollow">https://medium.com/@Pinterest_Engineering/continuous-integra...</a>
I have recently started looking into Nix to solve the problem of dotfile deployment to new OSX workstations. When you get a new laptop, you clone your dotfiles, maybe symlink them to your home directory -- and then what? Nix solves this problem for me by coupling my dotfile deployment with the installation of the related software.<p>The learning curve has been absolutely tremendous, however. That said, the support on Freenode has been some of the best I've encountered in more than a decade.<p><a href="https://nixos.org/nix/manual/#chap-package-management" rel="nofollow">https://nixos.org/nix/manual/#chap-package-management</a>
<a href="https://rycee.net/posts/2017-07-02-manage-your-home-with-nix.html" rel="nofollow">https://rycee.net/posts/2017-07-02-manage-your-home-with-nix...</a>
I switched from Arch Linux to NixOS last year and it was a great experience <a href="https://ramsdenj.com/2017/06/19/switching-to-nixos-from-arch-linux.html" rel="nofollow">https://ramsdenj.com/2017/06/19/switching-to-nixos-from-arch...</a>. The community is relatively small and easy to get into, with lots of people ready to help out beginners.<p>It took a while to get used to, especially considering the way to learn how something works seems to always be to go and read source code on GitHub. There are good things and bad things about this approach but I fear it makes it difficult for your average user to use since it is a bit of a barrier to entry.<p>I loved how extensible the system was, and how easy it was to make modifications simply by modifying configuration.nix. It made it really feel as though my system was truly 'mine', in some ways being similar to the feeling I get from setting up an Arch machine. Being able to just recreate a machine by cloning your configuration onto the new machine, and running 'nixos-rebuild switch' is extremely powerful. Being able to roll back machine is also amazing. Something else that really impressed me was how great though ZFS support was. Setting up a ZFS system on Nix is one of the best experiences I've had using ZFS on Linux. It really feels as though ZFS is a first-class citizen on Nix, not something tacked on top. It's possible to set up ZFS without adding any sort of external repository like with Arch.<p>I ended up leaving NixOS after running into an issue that I would get related to UEFI, and at that point didn't have the time to track down the problem, but I'm really excited for where NixOS is going in the future, especially when declarative user environments <a href="https://github.com/NixOS/nixpkgs/pull/9250" rel="nofollow">https://github.com/NixOS/nixpkgs/pull/9250</a> (user configuration) with NixUP becomes a thing. I will definitely be coming back to it in the future.
I'm a big fan of Nix, but I really with there was a declarative way to define a user's environment similar to what NixOS has with /etc/nixos/configuration.nix.<p>It seems a little strange to me to have a functional package manager, but an imperative package install process. I think there are a few projects like NixUP and home-manager that are looking to address this, but I'm hoping Nix will provide an official way to do it.
For those new to NixOS, the default package installation method is through a concept called channels. It can be a bit confusing reconciling the nature of channels and the real strength of NixOS which is functional reproducibility. I wrote a blog post explaining what channels really are and an alternative which is to use Git commit hashes instead <a href="https://matrix.ai/2017/03/13/intro-to-nix-channels-and-reproducible-nixos-environment/" rel="nofollow">https://matrix.ai/2017/03/13/intro-to-nix-channels-and-repro...</a>
I do pretty much that using GNU Stow. Of course I then build packages and libraries on my own, in my $HOME, because I don't have root access on that machine.<p>I install any PACKAGE of version VERSION in:<p><pre><code> ~/stow/pkgs/PACKAGE/VERSION/
</code></pre>
So taking nim for example, I'd have:<p><pre><code> ~/stow/pkgs/nim/0.17.1/
</code></pre>
Under that, I'd have the whole FHS system for <i></i>just<i></i> nim 0.17.1:<p><pre><code> ~/stow/pkgs/nim/0.17.1/bin/
~/stow/pkgs/nim/0.17.1/lib/
~/stow/pkgs/nim/0.17.1/share/
</code></pre>
I set ~/stowed/ as my STOW_TARGET. So on running stow, symlinks to all:<p><pre><code> ~/stow/pkgs/PACKAGE/VERSION/{bin,lib,share,..}/..
</code></pre>
get created in:<p><pre><code> ~/stowed/{bin,lib,share,..}/..
</code></pre>
I then have aliases set up to do something like "unstow PKG/OLD_VER" and "restow PKG/NEW_VER" when I want to change the package version.<p>I skip the "restow" step if I just want to "soft uninstall" a package i.e. remove it from PATH, PKG_CONFIG_PATH, MAN_PATH, .. by removing it only from the STOW_TARGET ~/stowed.<p>"Hard uninstall" would be simply:<p><pre><code> \rm -rf ~/stow/pkgs/PACKAGE/VERSION_I_DONT_WANT/
</code></pre>
Or even:<p><pre><code> \rm -rf ~/stow/pkgs/PACKAGE_I_DONT_WANT/</code></pre>
A copy of what I commented on the blog:<p>Nice post, and I'm glad you're enjoying NixOS!<p>I'm a NixOS contributor/committer, and the principle author (and co-maintainer) of the Bundler-based packaging integration. If you or anyone reading this has any feedback and/or questions about NixOS and Ruby (or NixOS in general) feel free to shoot me a message. I idle on #nixos on Freenode (as cstrahan), and you can email me at charles {{at}} cstrahan.com.<p>Cheers!<p>-Charles Strahan (cstrahan)
Recently, I got the opportunity to play with Nix. To me, it felt to be a very nice way to bundle the dependencies along with the application. But there are few questions which always come to my mind were - how people run it in production. Can they achieve all the things (eg monitoring, debugging..) easily just like the app hosted on a linux machine ?
RhodeCode is one of projects that build their installer on top of nix package manager. Check out this blog post: <a href="https://rhodecode.com/blog/61/rhodecode-and-nix-package-manager" rel="nofollow">https://rhodecode.com/blog/61/rhodecode-and-nix-package-mana...</a>
Is there a way to install nix into home folder (suppose I don't have sudo on server). I spend some time recently trying to setup nix in such environment and failed. I ended up compiling recent versions of neovim and tmux myself.
<i>what would happen if we want to install, for example, two different versions of ruby at the same time?</i><p>This is treating the symptom instead of the root cause, that being ineptitude to design backward-compatible software. We as an industry should fight such band aids and take a stand. Yes, designing backwards compatible software is hard, but exactly that is the difference between engineering and amateurism. And if one is getting paid to program, I’m going so far as to argue that it’s one’s job to have their head hurt solving such difficult problems so that users of computers don’t have to.
Sounds like a similar solution to gentoo's slotted ebuilds [0]. Switching the 'default' implementation system wide or per user (eselect) has the same issues discussed. Not sure if there is an existing utility (beyond your standard shell script) that can produce sane per-shell environments.<p>0. <a href="https://devmanual.gentoo.org/general-concepts/slotting/index.html" rel="nofollow">https://devmanual.gentoo.org/general-concepts/slotting/index...</a>
Gobolinux does something similar, and has been around for years: <a href="https://www.gobolinux.org/" rel="nofollow">https://www.gobolinux.org/</a>
Just a heads-up in case anyone is confused as I was: Nix is not 100% bit-for-bit deterministic/reproducible yet, though they do deliver functional equivalence.
Software Collections (<a href="https://www.softwarecollections.org/en/" rel="nofollow">https://www.softwarecollections.org/en/</a>) give you the power to build, install, and use
multiple versions of software on the same system, without
affecting system-wide installed packages.
Is this what Nix OS is able to do? Install multiple versions of software and select which version to use before running?
I have used NixOS. It's fustrations led me to develop this.<p><a href="https://github.com/pauldotknopf/darch" rel="nofollow">https://github.com/pauldotknopf/darch</a><p>It is essentially Docker, but you can boot bare-metal with it. It even uses Docker under the hood.<p>Every boot is a fresh boot. You can read-write during boot, but all changes are made to ram. You mount with fstab things you want persisted, like home.
I'm gonna need a better reason to switch distros than that. I do think that is an improvement that needs to be adopted in the OS. But, I mean, it's not that much of a improvement over containers. I don't feel like it gives me, the user, that much more power over the OS and would be a feature that I would only use very rarely.
That's a bit too strong a statement to make based on a two-year-old still-open PR with an uncertain future.
<a href="https://socialworldblog.com/" rel="nofollow">https://socialworldblog.com/</a>
Nix the package manager is great. Poorly documented, but it works as expected. I've also had uneventful experiences using NixOS on a server.<p>On the other hand, trying to use NixOS on my laptop has been struggle after struggle. Every update breaks something. Many times updates cause the entire system to crash. Different combinations of display managers, window managers, and various system level daemons interact in complex ways.<p>None of this is the fault of NixOS, really it is the fault of the Unix philosophy scaled to the level of the desktop Linux ecosystem, combined with the traditional assurance on upstream developers that packagers in distros like Ubuntu will fix their shit.<p>What would be really great for NixOS would be a set of various well tested base configurations for the various DE/WM combos, like all the spinoff Ubuntu distros. These would fix the versions of all the fragile graphical components on some kind of release schedule, while probably still using nixos-unstable underneath for all the relatively reliable stuff like the kernel, emacs, vim, coreutils, etc.
Python solves this problem with "virtualenv", where the user creates a virtual environment and installs all programs and libraries into that environment. The user can have multiple virtual environments, and it is easy to switch between environments.
"To deal with this nix provides the nix-shell utility which constructs an environment on demand and runs a new shell based on that environment."<p>I'm sure nix is cool but this sort of sounds like something we just end up using docker for these days (for better or worse).