My Nix(OS) notes

There are a couple of places where community members are gathering. The three most prominent ones are:

• GitHub, hosts all the NixOS official repositories.
• The NixOS Discource is the official forum. Announcements is the section where news and new projects are announced and the help category is useful if you want to ask questions regarding Nix.
• The Matrix space is a collection of Matrix rooms, where discussions are taking place in real time or async and covers different topics.

There are also some unofficial places, like the /r/NixOS subreddit and an unofficial Discord instance, but I don't follow those so can't comment on what's going on there.

The official and most up to date wiki is available at wiki.nixos.org. There's also an unofficial wiki that was used in the past and still comes up in search engine searches at nixos.wiki, but the content there isn't updated by the community anymore.

Infinisil hosts a weekly session called The Nix Hour, where they discuss various Nix related topics over multiple sessions (81 so far!). I have watched a few and they are a great resource to learn something new about Nix.

Multiple in person events take place every year about Nix and NixOS. These are announced in the Discource Events category. The big one is Nixcon, which happens yearly in Europe.

Smaller community organized sprints for people to hack on Nix are:

• Ocean Sprint, a week long gathering for people to work on Nix from the Canary islands.
• Thaiger Sprint, similar to Ocean Sprint but based on Thailand.
• ZHF sprint in Zürich, a weekend sprint in Zürich around the Zero Hydra Failures initiative.

GitHub is the forge that's currently used to host the NixOS repositories. There's a lot of automated actions taking place via GitHub Actions and other software outside of GitHub, so I don't think moving to a different forge is an easy task if there's ever the need.

Parallel to the foundation owned repositories, there is Nix Community, a separate GitHub org that functions as a project incubator for community spawned software. When a project gets traction and is used more widely, people might "donate" the projects to the Nix community so that it becomes more communal, new maintainers are added, etc.

Projects might also be "promoted" into the foundation org if they become mission critical for running NixOS in theory, but I haven't seen this happen outside of some discussions.

Of course, there are a lot of Nix(OS)-adjacent projects outside of GitHub. Most notably, the Lix project have their own Forgejo instance.

Besides Nixcpp, there are two other software implementations of the Nix language. One is Tvix, written in Rust, and the other is Lix, a fork of Nixcpp.

When CVE-2024-45593 was discovered by people in the Lix community, I switched to using Lix on my systems as it gave me more confidence in their practices. I haven't interacted much with either Nixccp or Lix developers, but I think that the Lix community is more welcoming and seem to be more responsive on issues.

I haven't tried Tvix, so I can't comment on it, but I'm curious to see what will come out of it.

A core concept of Nix is the Nix store. The Nix store is a directory in the filesystem where the Nix daemon saves all the packages and artifacts it needs and uses. By default, it resides at /nix/store/. The contents of the store are meant to be immutable, which is achieved by mounting the store as read-only for all users except for the Nix daemon. More info here.

In order to search for packages and module options, I have found that the best option is to use search.nixos.org. This is a service that runs an ElasticSearch instance together with nixos-search to display packages and options.

Nixpkgs is quite the beast of a repo. At the time of writing (Feb 2025), it contains ~38 thousand .nix files, has ~760 thousand commits, includes contributions from eight thousand people and ~6.6 thousand open pull requests.

pkgs
└── by-name
      ├─ zi
      ┊  ├─ zizmor
      ┊  ┊   └─ package.nix

pkgs
└── development
      ├─ python-modules
      ┊  ├─ requests
      ┊  ┊   └─ default.nix

There are a lot of heated discussions online about this specific topic, about how flakes are good or how they're bad, about the advantages of one solution or the other. Flakes seemed like the easiest option when I got started, since most examples I found online were built around them. Their git model aligns with how I expect a project to be structured, so I still use them today.

However, I don't have strong opinions on them and I wish there was a clear page that showed all the pros and cons of each option and how a project would be structured with each one. If there's such a page, please let me know ;).

In typical Nix fashion, there are multiple ways to deploy your NixOS systems. I'm currently using what I consider to be the simplest option, nixos-rebuild --flake with a --target-host hostname to update remote hosts.

I've only read the documentation of colmena, nixops, deploy-rs. Colmena and deploy-rs are the two tools that I see mentioned most often.

To bootstrap remote hosts when I don't have the option to use a NixOS iso image to boot the installer (for example in weird/old cloud providers), I've used nixos-anywhere with great results. Nixos-anywhere connects over SSH to any linux host that supports kexec, downloads the NixOS installer, kexec into it and takes over the current system transforming it into a NixOS system. It's one of those things that you know that in theory could work, but when you actually see it work for the first time it feels like magic.

Nix, by default, uses cache.nixos.org which is a binary cache with prebuilt packages. It's the equivalent of an APT cache for .deb packages. As far as I know, only hydra.nixos.org can upload packages to cache.nixos.org. These binaries are signed with a key to verify their authenticity. Based on this comment, I understand that this key hasn't been rotated since 2015 (!), which to me, is one of the scariest parts about using NixOS.

You can self-host your own binary cache in multiple ways, but attic is a complete solution to this problem which supports multi-tenancy, S3 as a storage backend, deduplication, signing on the fly and other cool features.

There are also some efforts about tracking and making NixOS reproducible. There's a label on GitHub to track issues relates to reproducibility.

As a personal project, I want to combine buildbot-nix with attic to have my own cache containing packages built from source. The plan is to track if they're reproducible as well, to help with upstream efforts.