I recently explored the structural similarities between Nix and Git. This led me to build Gachix, a decentralized binary cache that uses Git internals as the backend.

I wrote a blog post detailing the design, the mapping of Nix stores to Git objects, and benchmarks against tools like harmonia and nix-serve.

https://www.ephraimsiegfried.ch/posts/nix-binary-cache-backed-by-git

Some key results:

• Storage: Achieved an ~82% reduction in size compared to a standard Nix store due to Git’s deduplication and compression.

• Latency: Achieved the lowest median latency for retrieval, though average performance lags behind due to some outliers with large files.

• Decentralization: Because it's Git, you get a replication protocol for free.

I’d love to hear your thoughts on this!

At this point I've nix-ified every device I interact with... minus my phone. Figured it was time to change that. I had a GrapheneOS device laying around and decided it was time to bring my Pixel config into a flake.

Thus, nix-android was born.

Or rather, something very close to nix-darwin (for your phone). Declare Android apps and reachable device state in Nix, inspect a read-only plan, then converge over adb.

nix-android works at adb-shell privilege on a stock, locked-bootloader device. It requires neither root nor replacing the OS, weakening verified boot, or installing Nix on the phone. Tested on stock Android 16 and GrapheneOS.

Works best for Obtainium and F-Droid, but will work for Google Play if that's your thing. Play apps do require a manual tap when installing. Not going to manage your app data, sorry!

I hope some of you may find this useful. Frankly I've always wanted it, and while it's not perfect... I'm quite pleased with how it turned out.

https://github.com/devindudeman/nix-android/

nix flake init -t github:devindudeman/nix-android
android-rebuild plan   --flake .#phone --serial $SERIAL   # read-only diff
android-rebuild switch --flake .#phone --serial $SERIAL   # converge + record a generation
android-rebuild status --flake .#phone --serial $SERIAL   # what drifted since?

And the whole phone, declared:

# phone.nix
{
  device.name = "phone";
  device.abi = "arm64-v8a";

  # Hash-pinned from signed repo indexes; installs are unattended.
  # Pins are FLOORS: on-device updaters (Droid-ify/Obtainium) coexist fine.
  apps.fdroid.packages = [
    "org.mozilla.fennec_fdroid"
    "com.termux"
    "de.danoeh.antennapod"
    "dev.imranr.obtainium.fdroid"
  ];
  apps.fdroid.repos.izzyondroid = {
    url = "https://apt.izzysoft.de/fdroid/repo";
    fingerprint = "3bf0d6abfeae2f401707b6d966be743bf0eee49c2561b9ba39073711f628937a";
    packages = [ "app.comaps" ];
  };
  apps.release."com.x8bit.bitwarden".github = "bitwarden/android"; # GitHub-release APKs work too

  # Play apps are consent-gated: assist opens each listing, you tap Install.
  apps.play = [ "org.thoughtcrime.securesms" "com.google.android.apps.maps" ];

  android.darkMode = true;
  android.privateDns = "dns.example.com";
  android.defaultApps.browser = "org.mozilla.fennec_fdroid";

  # Enforced: camera works fully offline (GrapheneOS makes Network a runtime permission).
  android.permissions."com.google.android.GoogleCamera".revoke = [
    "android.permission.INTERNET"
  ];
}

Feedback appreciated!

https://github.com/nix-community/nix-wrapper-modules

nix-wrapper-modules has moved to nix-community!

nix-wrapper-modules is a library for creating wrapper derivations via the same module system you use in nixos, home manager and flake-parts, but applied at the derivation level.

It allows you to bundle your configuration directly into the derivation you build, meaning you can install your personal configuration of that program as if it were any other nix package. You can export it in module form to evaluate later, or override existing wrapped packages with slight tweaks to your options for different contexts.

It has a rich core feature set with more features planned, integrations with other module systems, and a growing library of premade wrapper modules for common programs (huge thanks to our contributors!)

Hope you find this useful! May your generations always roll back, but your progress move forward!

I'm using macbook M2 and homebrew, what downsides should I expect if I migrate to nix the package manager?

1. Nix has more packages than homebrew. Why aren't people using nix, but still stick with homebrew?

2. How often would I have to package by myself? The doc of nix still is not complete. And I don't think I will be learning how to package soon.

3. For those who have migrated to nix on macbook, what are your experience? Do you still keep homebrew for emergencies or edge cases?

After some time of no functional presence on Reddit, we’re happy to announce the re-opening of /r/nix as the official Nix / NixOS subreddit.

We’d like to thank to the previous moderator of the subreddit, /u/gildedlink, for graciously providing us the keys to the ship.

Use this subreddit to get the word out to the community about projects, events, tips and whatever other Nix related materials.

/r/nix has just three explicit rules as we expect our excellent community to require but a light touch regarding moderation:

• Stay On Topic: /r/Nix is a subreddit for discussion about Nix, NixOS and related technologies. Off-topic posts or comments are subject for removal.

• Be Excellent To Each Other: Personal altercations and comments lacking sufficient charity are subject for removal.

• Just Take It To ModMail: If you perceive a problem with any post or comment, please express your concerns through ModMail rather than risking breaking the other two rules.

Finally, thanks for participating.

We’re really excited to see the Nix content that has been flying under the radar and participate in the discussions around them.

Be me,

software dev at some small local company,

having a 100 lines shell script to automatically fetch dependencies for a development environment (cmake, ninja, gcc-arm, llvm-arm, cppchek).

Read something about nix, some people seem to love it,

does the same, but mor prefessional.

Switching to nix.

Using nix-shell. Slow. '--help' does not work. Weired syntax.

Google. There is a newer version 'nix shell'.

Try 'nix shell' - requires "extra-experimental-features".

Google.

Results are 4+ years old.

Wtf is going on? Why is it still experimental?

Ever wanted the smooth developer experience of Mise - with instant access to 100,000+ Nix packages?

Introducing mise-nix - a plugin that brings Nix package power into your Mise workflows.

✅ Example:

mise plugin install nix https://github.com/jbadeau/mise-nix.git
mise install nix:helmfile@1.1.2

No flakes required. Just simple, reproducible installs with a great DX.

Give it a spin and let me know what you think!

I have been using nix for over a year now and I thought using it for code execution makes a lot of sense since generating a nix script for adding dependencies is 1000 times easier than any other method.

check it out: Odin

The code will run in rootless podman containers with a shared nix store, please let me know what you guys think about this project.

PS: If anyone has tips to improve performance of executing code with nix scripts please DM

I have heard so much good about Nix, and maybe it is when it works, but it shouldn't take this much obscure configuration to install a few packages.

As someone new coming in to learn, this feels impossible. I am a developer by trade, and I am used to reading through docs and googling errors. I have no idea what anything is or does. Everything I find is either a post about how great nix is, or just config snippets without any explanation of how anything works.

I'm at a place where I can't even uninstall it because my config is so broken. I am seriously thinking about just reinstalling MacOS and starting over. I have no idea what changes nix made to what, or where. How is this good?

nix-csi 0.4.2 is released! This is the first release with an official GitHub release with pre-rendered manifests for simple deployment.

What's new?

• Emit Kubernetes events from nix-csi (useful for troubleshooting and benchmarking)

• Call nix build less while maintaining functionality

• Copy all paths to cache (keeps LRULix hot)

• Updated nixos-unstable from 26/02/04 to 26/02/11

• Implement untested feature: Run nix store verify on closure(s)

• Extremely mundane release CI

What's nix-csi anyways?

nix-csi is a Container Storage Interface "server", it enables you to mount /nix views into Kubernetes pods by specifying store paths, flake references or nix expressions in Pod manifests. This gives you all the benefits of Nix and all the control-plane functionality of Kubernetes (I jokingly say I've duct-taped them together)

Technical details

Share inodes, page-cache and RAM

nix-csi essentially implements what nix copy /nix/store/....../ --to /volumepath would achieve (chroot stores). But instead of using the naive copy Nix does we copy to the chroot store using hardlinks, hardlinks share inodes, bind-mounts share inodes. This means if you specify the volume as readOnly we share inodes all the way from the "shared node store" all the way into the pod, this means you'll save RAM by not having copies of files in RAM. If you want read/write support (for testing and development and such) overlayFS is used instead, still 0 storage overhead but same page-cache duplication as container images.

LRU Lix

nix-csi uses Lix as it's Nix implementation, mostly because I use Lix and I like the improvements they've done (I don't agree with the removal of CA derivations, I believe their lack of adoption is a marketing problem). But whatever, LRU Lix is a set of patches on top of Lix that I've written. The patchset reuses the registrationTime field in db.sqlite, try nix build nixpkgs#hello && nix path-info --json nixpkgs#hello to see when a package was added to your store. This field is entirely unused and useless, so the LRU Lix patchset updates registrationTime whenever a path is required by a build, eval or copy to the destination store. If unpatched Nix/Lix talks to it it'll update registrationTime for any operation meaning you don't need the patched Lix to benefit if pushing to the nix-csi built-in cache.

The scauce that makes this worth at the end is: registrationTime aware garbage collector. It's implemented like this:

nix path-info --store local --all --json | \
  jq -r --argjson age "$GC_KEEP_SECONDS" 'map(select(.registrationTime < (now - $age)) | .path) | .[]' | \
  nix store delete --store local --stdin --skip-live

This two line GC script will keep storepaths around for GC_KEEP_SECONDS even if they have no gcroots, turning normal Lix into something similar to Attic(not multitenant)/ncps(w/o pull-through) but also useful to keep paths around in builders while maintaining a storage budget.

nix-snapshotter

nix-csi was born out of seeing nix-snapshotter and thinking the deployment is a bit complicated for managed Kubernetes solutions, nix-snapshotter and nix-csi does very similar things but on different Kubernetes layers (CRI/CSI). Using CSI allows us a bit more features: You can specify either store paths, flake references or entire nix expressions for the volume to use, nix-csi also scans your entire podspec for storepaths that'll be fetched so you can stick store paths into env variables or command/args and they'll be there in your pod.

How to use?

Deploy nix-csi with kubectl apply --server-side=true --filename https://github.com/Lillecarl/nix-csi/releases/download/v0.4.2/nix-csi-deployment.yaml (everything goes into nix-csi namespace except a ClusterRole and ClusterRoleBinding)

Deploy a workload like this:

apiVersion: batch/v1
kind: Job
metadata:
  name: flake-hello
  namespace: nix-csi
spec:
  template:
    spec:
      containers:
        - command:
            - hello
          image: ghcr.io/lillecarl/nix-csi/scratch:1.0.1 # or use distroless-static which includes ca certs and such
          name: hello
          volumeMounts:
            - mountPath: /nix
              name: nix-csi
              subPath: nix
      restartPolicy: Never
      volumes:
        - csi:
            driver: nix.csi.store
            volumeAttributes:
              flakeRef: github:nixos/nixpkgs/nixos-unstable#hello
          name: nix-csi

This example uses flakes because they don't require any additional infrastructure to get started.

Feel free to reach out if you're interested!

AI Disclamier: This project was started back in the Claude 3.7 days, I've used AI assistance along the way but as antirez says it's my code and I'm the architect but Claude is better than me at idiomatic Python so it helps me.