I will back this up by saying that all the banking apps (plural) I run on GrapheneOS run perfectly fine. I don't even have Google Play Services installed, either.
Wow, thanks a million for that link. My banking app was not working but I found "Exploit protection compatibility mode" in the relevant thread, and now it works again.
It is a powerful abstraction that ends up being a replacement for several kinds of tools depending on your use case.
It can be a way to declaratively configure a system similar to ansible.
It can be a way to isolate runtimes (e.g. ruby v2.8 and ruby v3.0) in different projects similar to rbenv / virtualenv.
It can be a way to define an application in a self-contained way so that the target platform needn't have needed software installed beforehand similar to docker.
It can be a way to install packages/software to your system in a well-defined way similar to many package managers.
I'm a consultant and jump around different stacks, or have to grok some new thing pretty quickly. Nix helps me with my personal dev environment. I also generally prefer functional style of doing things, declarative, immutable, etc.
Nix is so easy to share across machines (including Mac) that it ends up being pretty cool when you pair it with something like syncthing. I can jump around, get up to speed with something new, and have it everywhere without much setup now that my machines share some Nix code and data.
Mac support is pretty great with nix-darwin; I'm able to update my flake, run nix-build and my terminal/system level apps, Mac app store apps, homebrew apps, and dock shortcuts all get updated at once. My dock points to apps in the Nix store. Sure I could do that with some scripts, but Nix ends up being way more robust.
I also still use Emacs and the community emacs-overlay is pretty awesome.
But after you're up and running, Nix makes all this stuff generally seamless is my point. There have been times I can't update due to some upstream thing, but 80% of the time it's fixed for me in nixpkgs a few days later.
nixpkgs has like 80,000+ packages the last time I looked, and is growing.
I haven't had a use case to stray outside of Docker + terraform for my work related stuff, but it's amazing for sharing dev environments on a team. Flox is a new thing to check out
Lots of people have given benefits here so i'll give some of my unique use cases that haven't been mentioned. I use it for reasons mentioned, but also;
- I work at a big org and run 10+ dev services for a mobile app team. My team uses macOS because that is what we are familiar with. We are large enough to not be able to use Docker desktop. The alternatives (Rancher Desktop, Podman) consume between 2 + 8GB before you run your app and they have TERRIBLE file system I/O. Nix gives us isolated, reproducible environments + native i/o.
- Inside our iOS project we are using Nix Shell in the build phases for things like linting, code gen etc. Ensures everyone is on the same version across developers and CI machines. Updating versions is so simple. We can also share a network attached Nix store with all the binaries to save space on CI machines.
- Once you get everyone to install it, you can add new tooling + languages for free by adding nix-env instead of bash as the she bang in your shell scripts. Need to run some ruby thing? Well you know everyone has nix installed, just do nix-shell and add the ruby version you need - its guaranteed to work everywhere. More info here: https://gist.github.com/travisbhartwell/f972aab227306edfcfea
It is possible to “hash” a function so that the hash stays the same for as long as the function does the same thing (in which sense the language is similar to, e.g., Dhall), which is guaranteed because 1) function is pure, 2) the hash derives also from any other functions it may call and all the way down, and 3) everything is a function.
In the world of package management that gives you a superpower and/or curse of being able to say “I want dependency X” and mean “I want a dependency built in this exact way”. When applied thoroughly, the only inconsistencies in behavior that can arise in theory would be due to logic errors in external to Nix software or to hardware issues[0].
From provisioning deployed software runtime environments (in which sense Nix is more similar to, e.g., Docker) to automating your development machine configuration—basically anywhere you want consistency and hate surprises—in this sense Nix suffers from solving very different problems for different people, and as a result people being confused as to what is it for just by looking at articles and discussion threads about it.
[0] In practice, you might occasionally have to fight poorly behaved software that makes unwarranted assumptions about the system (can’t be installed into or look for dependencies under hash-paths), modifies itself (auto updates), etc.
I used to use Arch. I would always do a btrfs-snapshot before doing a system upgrade, then create another one after booting the new update (provided everything worked). In NixOS I don't have to because it has generations. The upgrade is entirely atomic and if it doesn't work I just use a previous generation.
Second I used to use pyenv and bunch of other tools to make sure I had the right development dependencies. Instead I just put the requirements in a shell.nix or flake.nix in the project directory, have those called with direnv. Now I can easily have python38 with clang_11 for one project and python311 with gcc48 for another.
Third the system of modules generally makes it easy to have my system setup in one place, and with the services I want. If I want zram, I just set `zramSwap.enable = true;` and that works. If I need ssh access: `services.openssh.enable = true;`, oh, but I have the firewall enabled (networking.firewall.enable = true;), that's okay because services.openssh.openFirewall defaults to true, so it handled automatically. And if I change services.openssh.ports to a better port, the firewall will be updated too.
You can use as much or as little of it as you want, which I know is not a satisfying answer.
I think the most common use case is as a build system, but in this context you aren't limited to building packages, you can also build "environments". By "environments" I mean a shell with certain packages available in `$PATH`. You would use Nix like other build systems in the sense that you specify the build requirements (which other packages, libraries, etc you need to build _your_ stuff), then you specify how exactly to build your stuff. Here "stuff" could be as little as a shell script or as much a huge monorepo.
There are ways to use Nix like you would use Ansible or Terraform, but I wouldn't say that's the mainstream use case of Nix.
I'll take a stab and say that I believe that nix's actual power is to efficiently materialize an exact tree of files (raw or generated) on any machine. By "exact", I mean in a fully reproducible way.
That capability turns out to be really powerful because you can materialize a program, a whole Unix tree, or even a script that converges the current host to a desired state.
Nix is a package manager. But it can weave together multiple package managers so it frees you from being locked in to any one particular language, OS, architecture. The proof of this that we also ended up making a full OS (NixOS). Then there are follow-on things one can do, such as using it to manage the configuration of things and people continue to build more tools for this.
Fundamentally the core technology is for it to be a correct and safe package manager. (eg: think about the engineering tradeoffs for memory-safety vs anything-goes) Once you have that basic primitive, lots of things can be "packages": software, data, configuration, dotfiles,......
I'm just using it as a reproducible version of homebrew for macOS. Brew is annoying to set up again on a new install, nix is just copy my config and build it.
It's like Ansible but with a proper language, declarative instead of imperative config, a lot less leaky and brittle, a huge amount of pre-made packages and config, and can manage the entire OS. Not really the same class as Ansible actually. I used Ansible at first and it felt super hacky and broke all the time. Nix is light years ahead in reliability and power.
Nix is not a tool, it's an ecosystem of various composable tools.
Personally I use it in complement with Ansible and systemd to deploy complex interdependent software without having to build and orchestrate containers.
The Nix ecosystem extends in many directions from a simple idea, which will make answers to questions like this often seem either too vague, or too expansive. But it's easy to trace the outlines of particular use cases concisely, so that's what I'll do here.
There are configuration management tools built on Nix that occupy some of the same space as Ansible, to focus on one of your examples. My favorite one is NixOS, so I'll refer to it as an example. But what I will write here about what distinguishes it from Ansible also applies to other configuration management and infrastructure-as-code tools based on Nix, such as Home Manager, Nix-Darwin, Disnix, devshell, and others.
In NixOS, IaC is achieved by using the Nix language to declare what resources must be made available on an operating system, from which Linux kernel and modules to use to what users must be present, which programs must be on the PATH, what services must be running, what ports on the firewall need to be open, and so on. This is of course very similar to Ansible, but with a different DSL.
What's different is that NixOS tries to take an approach which is, as far as possible, stateless. Whereas Ansible relies on careful management of idempotency in a series of operations to mutate the system towards the desired state, NixOS instead works by generating the desired system 'from scratch' every time you make a configuration change. To make this practical, NixOS uses some clever caching features built into Nix to avoid recreating configurations (be they config files or installed programs or anything else) that it has already created before. It does this with the same basic concepts as memoization and content-addressing.
The buzzwordy but very brief way to put this is that Ansible's approach is convergent and NixOS' approach is isomorphic. Reiterated one more way, Ansible promises that (if used correctly) it will push your configured systems in the right direction, while NixOS promises that it will create something for you whose structure is (hopefully) wholly and solely determined by the configuration you've given it.
This means, for example, that you never have to explicitly tell NixOS to remove something that you used to mention in your config file, but no longer do. Instead, when the new configuration is built, the old configuration of the system plays no role, and the software you've removed from your config file just doesn't appear in the new configuration.
I hope that illustrates the Nix approach a bit, and maybe also some of what makes it attractive for configuration management. Before I wrap up, I want to return to your last question, though:
> Where does [Nix] fit exactly?
Nix is the core of a diverse ecosystem that increasingly spans the entire devops space and the whole software lifecycle. There are tools built on Nix that integrate with or compete with popular tools from CMake to Packer to Jenkins to Docker to Bazel to Kubernetes.
At its heart, Nix itself is a DSL and software tool for managing files in a (quasi-)content-addressed store in a highly disciplined way. As a build tool and package manager, its main task is wrangling the output of the build toolchains we know and love (or not) into that big, write-once hashmap on disk. Everything else in the ecosystem is built either to leverage or enhance that basic functionality in some way.
Because it turns out that generating config files and program binaries can let you do almost anything on a Unix-like operating system, this means you can use Nix to bring determinism, rollbacks, atomicity, and other goodies to a ton of different IT and development domains. And everyone's needs and environments are different, so enterprising Nix users have grown the ecosystem in many different directions in order to integrate with their tools of choice over the years.
You might want to check this site out to see if your bank app works though: https://privsec.dev/posts/android/banking-applications-compa...
Even if your app isn't listed there, there's still a chance that it'll work. Mine isn't listed on that site, but it still works with no issues.