Automatic Nix flake follows
If you have used Nix flakes, you likely encountered something like the following. 🤢
std.url = "github:divnix/std";
std.inputs.devshell.follows = "devshell";
std.inputs.nixago.follows = "nixago";
std.inputs.nixpkgs.follows = "nixpkgs";
hive.url = "github:divnix/hive";
hive.inputs.colmena.follows = "colmena";
hive.inputs.disko.follows = "disko";
hive.inputs.nixos-generators.follows = "nixos-generators";
hive.inputs.nixpkgs.follows = "nixpkgs";
Why is this follows necessary? 🤔
It’s in fact not necessary but it makes the Nix evaluation simpler and as a result faster. 🤓
Import but don't import your NixOS modules
This is a follow-up post to my prior one NixOS Option Inspection. Many thanks to @roberth who followed up on my issue and helped explain it. 🙏
If you are using NixOS, you’ve likely encountered the module system. It’s NixOS’s super-power and what makes it incredibly easy to share, reuse and configure systems based on Nix
{
imports = [ ./hello.nix ];
services.hello = {
enable = true;
greeter = "Bob";
};
}
In a prior post, I wrote about how it can be challenging to work backwards ⏪ from a NixOS option’s value to where it was defined.
Turns out, the answer in the post was relatively simple and Nixpkgs has a gesture for discovering the answer via definitionsWithLocations.
Turns out, in order to get definitionsWithLocations to play nice, you have to avoid a surprisingly common footgun 🥵.
NixOS Option Inspection
NixOS modules are great; and it’s one of the superpowers of NixOS. They’re so great, there was a working group to look into how to apply the concept to Nixpkgs itself.
For those uninitiated, there are plenty of guides online describing it’s value and purpose such as this one or on nix.dev.
My largest complaint thus far with it was that it’s hard to go backwards. ⏪
“Who and what defined a particular option?” 🕵️
Management Time
Note
This is the third (part1 & part2) installment on my series of improving ELF symbol relocation processing. Consider reading them if this post interests you. 📖
I have written previously about improvements to the dynamic linking process, specifically processing relocations for entries with symbols.
The key insight into the improvements, that have let the dynamic linking process scale to 1 million relocation entries and up to 22x speedup compared to the traditional methadology, is memoizing the relocation entries.
This memoization is possible since the linking order of the loader is deterministic and in store-based systems such as NixOS the libraries to be loaded are fixed & static.
Scaling past 1 million ELF symbol relocations
Note
This is a follow up to my previous post on speeding up elf relocations for store based systems.
I wrote earlier about some impressive speedups that can be achieved by foregoing the typical dynamic linking that can be applied to systems such as Nix where the dependencies for a given application are static.
Fish the bash way
I have been a big fan of the fish shell lately mostly because it delivers what it promises; works out of the box™️.
The obvious downside to fish is that it is non-standard POSIX sh – meaning some (not all!) of the 1-line scripts you find on the Internet may not work.
I use to be a pretty big zsh fan but I hit enough oddities with my setup that I gave up in anger one day. 😤
Nix secrets for dummies
Despite having used Nix for several years already, I feel secure in admitting that new concepts in Nix continue to be confusing at first glance.
I had avoided doing any secret management for Nix for a long time, largely because I ran Nix atop another Linux distribution, but now that I’m on NixOS my time hath come.
I wanted to write out my learnings here so that others may benefit from the ELI5 style of learning that we are missing in Nix.
Nix remote building with Yubikey
There isn’t that much Nix documentation for remote building with Nix.
I’m leaving my tiny module that I’m using to enable my Framework Laptop running NixOS to perform remote builds using the Nix Community builders, specifically that I use a Yubikey key as my SSH private key.
Actually some of the best documentation is courtesy of nixbuild.
Learn Nix the Fun Way
This is a post inspired by many talks I’ve given to engineering groups about Nix. You can see an example of one such talk Why I love Nix, and you should too
I’ve given a lot of Nix talks. I’ve given Nix talks internally at companies where I’ve introduced it, at local meetups and even at NixCon.
Giving a talk about Nix is hard. As engineers I find often we try to explain why or how Nix works but never show the end result.
Many of the talks I’ve given start explaining “Nix developed as part of Eelco’s PhD thesis in 2003” and immediately eyes roll.
Let’s do it different this time. Let’s learn Nix the fun way.
Reproducibility in Disguise: Bazel, Dependencies, and the Versioning Lie
Reproducibility has become a big deal. Whether it’s having higher confidence in one’s build or trying to better understand your supply chain for provenance, having an accurate view of your build graph is a must.
Tools such as Bazel have picked up mainstream usage from their advocacy by large companies that use it or via similar derivatives such as Buck. These companies write & proclaim how internally it’s solved many of their software development lifecycle problems. They’ve graciously open-sourced these tools for us to use so that we may also reap similar benefits. Sounds great right?
