nix-misconceptions.org

* Nix / NixOS misconceptions

** False: If I use Docker or Kubernetes, I need to change how I deploy to use nix

False.  If you can push to a docker registry such as docker.io, you can deploy
software using nix.

If your CI can build and run docker images, you can also do so without
modifying your CI environment.

** False: You shouldn't use a shell.nix because flake.nix is a thing

False.  If all you want is a developer environment, a shell.nix will suffice.
If you want to also build your application and package it, a flake.nix can
serve you better.

** False: I need to use git

False.  Flakes do not need git to work.  A source code manager (SCM) like git
is best practice.

** False: Flakes replace Nix channels

False.  I made a wiki edit documenting a community-perceived deprecation of
nix-channels.  This article was reverted within a day.

** I don't need to learn to code to use nix

False.  You should know how to code because nix is written in a programming
language called Nix.  If you do not know how to code, you won't get very far
with nix.  Keep this in mind when pushing for adoption within your
organization.  If you are unwilling to train your team to code with Nix, you
shouldn't adopt it, period.

** NixOS works well on low resource systems

False.  Nix takes a lot of CPU cycles to get anywhere.  Worse, it needs quite a
bit of memory.  And the most terrible - it will try to build derivations in a
tmpfs that competes with your applications for physical memory.

*** NixOS is viable for x86 systems

False, because you will have to build all the derivations and the above bad defaults.

** I need to use home-manager, age-nix, and additional packages to use NixOS

False.  You can use Nix or NixOS without any additional software support
packages.  In fact, you should start with less - keeps it simple and lets you
focus on what's important - getting up to speed with Nix without incurring
a massive time investment that is taking you away from getting your primary
computing tasks done.

** You need to run NixOS to deploy nix software

False.  Nix works fine with Docker as outlined above.

You could also consider a hybrid approach:  Ship the software in a nix
closure - so it'll live in =/nix/store=, but manage the daemons or applications
using OS native subsystems such as systemd units or launchd definitions.

*** Doesn't this negate the benefit of Nix?

You can still have your reproducible builds and easy to maintain packages with
this workflow.  I think this would be less work than shipping =.deb= packages.

** My workplace should adopt nix

Why?  What's the business use case?  Will you save the business a bunch of
money through freeing up your time?  Or will it have demonstrate-able cases
where it will prevent downtime?  (N.B. if you don't already, your infra should
have self healing logic - i.e. monitor an endpoint then start it again if it
crashes, or use systemd units, etc etc).

** Nix is a cohesive solution

Absolutely false.  Nix is like x11 - it provides mechanism but no policy.  This
means if you want to do something weird, Nix will let you.  It also means you
have to do a lot of research to determine which software support packages to
pair with Nix.  You will also spend time finding best practices, since there is
no cohesive community guidance around the core NixOS system - you need to draw
your own conclusions.