Reflections on NixOS

> It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work.

This could almost be the subtitle for "Functional Languages: Those Things Your Manager Won't Allow You To Use Yet"

I think that a day will come when everyone will realize, and we'll have the tools to do, "functional" all the way to the metal. I like to quote John Carmack from http://www.gamasutra.com/view/news/169296/Indepth_Functional...,

"A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible... No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."

I think this paradigm applies at the OS and filesystem levels as well (ideally). The better control you (and your code) have over the states of everything in your system, the more deterministic your system behaves, the fewer unexpected bugs you have to chase down, the better you can reason about the computing you're doing and the programming you're responsible for making work.

I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution.

Yeah, thanks. To add to that, the Nixpkgs "standard library" includes lots of convenient tools for patching like this, and much of the common stuff is done automatically by the standard package function. The #nixos IRC channel is a good place to ask if you run into trouble when packaging something.

Generally, making NixOS packages is really delightful. Even the patching stuff is straightforward and easy to use. Now that I've learned the basics, I routinely make small packages.

With many typical packages the only thing you need to do is specify how to fetch the source, plus the list of build dependencies, and there are built-in functions for fetching from HTTPS or Git.

I agree that the endless Nix vs Guix discussions are getting tiring.

As a contributor to both, I'll try to explain why Guix won't make Nix obsolete any time soon:

Guix is an official GNU project, meaning they won't ever support any proprietary code. The Linux kernel is "Linux-libre", which is a Linux fork with all proprietary drivers removed, so it probably won't run well (if at all) on your laptop. Whereas on NixOS you'll have things like Steam working out of the box.

Guix also has an unfair advantage in that they started "from scratch", while Nix contains a lot of legacy cruft from "paving the way". The `guix` tool/frontend is a lot better than the various "nix-*" commands, but there is work underway for a similar unified interface to Nix.

Finally, the language: Scheme is more pleasant to work with, but I find system configuration a lot more intuitive in Nix. NixOS also uses systemd/udev which is more familiar for most people than the maturing Shepherd service manager in GuixSD.

TL;DR: Nix and Guix serve different purposes through similar means. They are both excellent distributions and clearly represents a new era of operating systems. Most people would want to go with NixOS if they want a minimal-hassle functional operating system; but if you are just looking for a decent package manager for your favourite distro then Guix may be a better choice (as long as you can live without any non-free software).

We're not running a startup here Ok? It's not "grow or die". Priority #1 is make sure all the proper abstractions are in place: foundations before furnature. And while we're pretty good on that front, there are a few things left.

That's said we've got some CLI stuff being rewritten and other work that will help new users.

Your first sentence is very close to something I've said to others. NixOS is the first time I've been excited about an OS since first discovering Linux back in 2003.

The OP mentions "the ability to do controlled per-user changes in an ad-hoc fashion". I assume they are referring to the use of "nix-env", which some members of the community frown upon. I've adopted the policy of not using it. My system is defined entirely by various ".nix" files, and for launching simple applications, such as firefox, I just have my xmonad configuration bind "C-SHIFT-F" to "nix-shell -p firefox --run firefox".

For programs where I have more complicated environments, I have a "shell.nix" file in $HOME which contains a bunch of derivations that I commonly use, and I use "nix-shell -A" to enter them.

For development, all of my projects now include a "default.nix" file. Typing "nix-shell" in the project directory then brings in my project's dependencies as well as the tools I want when developing on that project, such as a suitable Emacs with the appropriate packages already installed.

I find I move these move ".nix" files frequently between different machines, and I really appreciate that I am put into reproducible development environments wherever they are.

To reiterate what others have said below: the Nix package manager makes sure to share build inputs. If I start a new project and include a bunch of stuff in my "default.nix" that I use elsewhere, it costs nothing to enter the new environment.