Questions about generally running NixOS

Help
1

I’m an experienced Linux user (as in, Gentoo & Arch behind my belt) but I’ve never used NixOS and I’ve researched it some but I’m not sure if it’s worthwhile to try. It just seems so hard and alien. I need some reassuring info about how typical tasks are handled.

  1. There are flakes and channels(?). I don’t want to spend time learning both, so since flakes are better and more modern, can I just use them for everything? Is there a good beginner tutorial for “flaking” the whole system?
  2. NixOS has releases every 6 months, right? So every half year I can run a command and all packages upgrade? Is that the same when running on flakes? Or are some of them pinned and won’t upgrade automatically?
  3. So a flake is basically a package.lock file. Now suppose I want to update that single package without changing any other flakes. How do I bump all the deps’ versions automatically? On a system like Debian, packages are updated as a snapshot, so I don’t need to know that e.g. GIMP 3.00 required libfoo >= 1.47 while GIMP 3.10 requires libfoo >= 1.52. How does it happen with Nix?
  4. How are flakes’ dependencies deduped? For example, libfoo is required by 10 flakes, one of them has libfoo 1.23, another libfoo 1.22, another 1.24 etc. I’d like to bump the dep versions in all flakes to 1.24 so I can test and garbage-collect versions 1.22 and 1.23. Can this be done automatically?
2

There are many people in the community who are happy to help if you decide to try. However, NixOS will always work best for those who have experienced the pain points that it is trying to solve. It offers configuration as code combined with deterministic build guarantees that try very hard to also be reproducible. If the benefits don’t seem clear to you, or worth the effort, don’t be peer pressured or FOMO’d by the bandwagon.

Having said that, easy ways to trynix are

  1. nix-shell (and family) on any distribution you are already running to get temporary access to programs
    • writing a shell.nix to create a reproducible toolchain that archives/pins the software used to create some project (think art file, analysis pipeline, etc)
  2. install NixOS on a VM
  3. use home-manager on any distribution you are already running

This is the most annoying and prevalent myth. Flakes are not opposite to channels. Flakes are a conventional schema that defines inputs (which often are channels) and outputs (which may be a nixosConfiguration defining a system), combined with a lockfile for pinning those inputs. It also comes with some tooling changeover, lock-in to git for source code management and pure evaluation by default which involves copying the project using flakes into the /nix/store before evaluation.

There are a ton of tutorials for flakes; they all work and you can just google one. In the context of a NixOS configuration, a flake configuration basically just involves adding a flake.nix file that ultimately wraps and imports the same configuration.nix that is used in the non-flakes workflow. You have to learn the same NixOS options to configure your system either way.

sidenote: there are many, many pinning methods such as npins, nixtamal, calling fetchTarball directly, etc

Yes, but your inferences from that fact don’t really hold up. NixOS is essentially a library of options that can be set to produce a bootable system image. Within a stable release, that library interface for setting options is supposed to not change. The NixOS “library” itself has a dependency on the nixpkgs “library”/package set which defines the actual software packages. These are de-facto tightly integrated as both are defined by branches within the github:NixOS/nixpkgs repo. Some packages and security backports still come into the stable channel and these can be pulled before 6 months.

Regardless of pinning strategy, if you don’t update your lockfile/path for fetchTarball, then no, nothing will update.

It isn’t clear to me what #3 is asking.

This is not a useful question to really answer because flakes can define so many different types of outputs. There is a follows mechanism for the inputs that may address some of your concerns.

2 Likes
3

I think questions 3 and 4 are related. Packages in Nixos (they call them derivations) don’t depend on shared libraries (you’ve probably noticed the emptiness of /usr/lib, for example) like pretty much every other distro. When you “install” a package with nix, all necessary specific dependencies are created and linked to for that package, so there are never library conflicts. And since you actually declare the package rather than installing it, you just stop declaring it and next time you rebuild everything related goes away. (Dependencies can be shared in a way if you use hard linking and multiple packages require the EXACT same dependency. This saves a lot of space without compromising package integrity, given the way hard linking works.)

You also might prefer following “unstable” instead of the main branch if 6 month updates are too long for you. It gets updated about once a week, and is quite stable in my experience.

1 Like
4

Stable is also updated often, but only with non-breaking or security-relevant changes.

2 Likes