Chaos Computer Club - recent events feed

Leveraging age and agenix, this project makes it easy to inject secret-containing environment variables into your flake-based devShells. It simplifies onboarding for new developers by enabling secure secret sharing, and helps make projects more self-contained by removing the need for external secrets managers. https://github.com/aciceri/agenix-shell about this event: https://talks.nixcon.org/nixcon-2025/talk/BABGSX/

I bought a receipt printer on eBay for $50, and it is one of the best purchases I've ever made. Here's how I packaged the drivers for Nix, how I legitimately use it in my every day life, and some significantly sillier Nix-related uses. about this event: https://talks.nixcon.org/nixcon-2025/talk/WNQEA8/

Running a production grade kubernetes cluster is a non trivial task. Although many commercial and non-commercial solutions are available, each comes with its own limitations. Some are primarily meant to set up a single node development cluster, others have hardly any flexibility. Here NixOS comes to the rescue, allowing us to build our cluster the way we want. However, because of the complexity of such a multi host setup, this is a bit more work than a services.kubernetes.enable = true;. We will look into the Kubernetes modules in NixOS, and how we can use them to set up a production grade cluster. For this we will consider what certificates we need, and how we can utilize a secret management solution like agenix to deploy them. We will also analyze how we can utilize Nix and the kubernetes addon-manager to configure our cluster from nix. Being able to install tools like ingress or the cert-manager is the final piece to describe the entire cluster in our nix config. about this event: https://talks.nixcon.org/nixcon-2025/talk/AZF8PR/

In this demo I will demo https://nix-ci.com/ to showcase how Nix can give us zero-config locally reproducible CI. about this event: https://talks.nixcon.org/nixcon-2025/talk/FHMLKZ/

The ssh-ng store implementation allows connecting to remote daemons over ssh. However, between server management, key exchanges, and device discovery, SSH is not the most user friendly. Unfortunately ssh-ng is also the only store implementation for active remotes built into nix. Let's ignore that fact and forward a remote daemon via P2P instead. Why would you do this? Does this work? And what can we learn from it? This talk might answer any or all of that. about this event: https://talks.nixcon.org/nixcon-2025/talk/FBZBUS/

When we think of reproducibility, we often focus on software builds, but what about the logos and visuals that represent our projects? In this talk, I’ll share how I approached logo design for the NixOS project with the same rigor we apply to software: deterministic outputs, minimal storage overhead, and fully free tooling. I’ll discuss the journey of building my own FOSS tooling to generate NixOS logos as SVGs from source code. Existing tools like Inkscape or Blender were either not parametric enough or not designed for clean, annotated vector outputs. By combining principles of CAD, typography, and color theory, I created a pipeline for reproducible, fixed-output derivations (FODs) that ensure all branding assets are versioned, verifiable, and easy to regenerate. This talk will cover: 1. The challenges of finding FOSS tools for parametric logo design. 2. Deep dives into fonts, kerning, and color spaces to build a consistent design language. 3. How I integrated FODs with verification tooling to ensure logo correctness. 4. Lessons learned about repository hygiene and why developers should expose overlays and NixOS modules rather than forcing consumers to hack around flake outputs. about this event: https://talks.nixcon.org/nixcon-2025/talk/HWQRXK/

Nix has got so many bells and whistles to meet most of the requirements, staying declarative with modularised setup to allow code reuse. However, this comes with a bit of a challenge for those who are starting the Nix journey -- it can be quite complex, or at least so does it seem. This talk focuses on some simpler approaches to use separate non-Nix files such as JSON, YAML and/or TOML for the configuration management. There are some gotchas around using file content, file as path, and potentially mixing and matching with Nix managed configs. The integration with other tools such as SOPS Nix will also be an interesting mix, where it is simpler to create a separate config file and substitute secret information with SOPS. Once you know the tools and solutions of not using Nix to get started, the Nix journey will be an easier one to get started with, and perhaps actually lead you to further Nix usage for areas where Nix language makes it easier. about this event: https://talks.nixcon.org/nixcon-2025/talk/CPF8EH/

Nix offers an unparalleled collection of readily packaged C/C++ libraries, with the added benefits of cross-compilation support and a declarative configuration language. That's why we chose it to manage third-party dependencies for our Bazel-built monorepo. This not-too-common use of Nix as a polyglot build system for external libraries and tools led us to approach Nix in a different way, both in how we think about it and how we used it. Our usage scenarios seemed rarely exercised an we found several opportunities for optimization in Nix code itself. At the core of the problem, we had 300+ packages that we needed to evaluate and build on demand. These evaluation times quickly added up, and we had to rethink the design to get some optimizations. This task set is embarrassingly parallel as each package evaluation is independent. But we realized along the way that full parallelism wasn’t the best we could do. We will explain how we leveraged nix evaluation caches (plural!), flakes, manually crafted store paths and parallel execution to reduce evaluation time from 5 minutes to 5 seconds, and bring other less quantifiable improvements. The work led to a few interesting scripts and two main PRs to nix itself (see below), one of which is already merged and released while the second is subject to discussion because of its impact on other cached operations. We will use that discussion to illustrate the tradeoffs of caching parallel evaluation. about this event: https://talks.nixcon.org/nixcon-2025/talk/FZNRLC/

NixOS is a remarkably flexible and powerful operating system, but its stability and scale can make it a challenging environment for exploring unconventional ideas. finix is an experimental Nix-based OS I built to break free from some of the constraints of upstream NixOS — a fully functional, Nix-built system that embraces rapid and bold experimentation over stability. This talk will walk through how I built finix, how I reuse much of NixOS’s scaffolding, and why I chose to try a different init system, finit. But more than the implementation details, I want to share how having a small, purpose-built codebase has created space to rapidly prototype ideas — like alternative service frameworks or minimal module sets — and see what works. finix isn’t meant to replace anything, but it could serve as a useful place to explore concepts that might one day feed back into the broader NixOS ecosystem, or at least help us think differently about how it’s designed. Beyond finix itself, I’d like to use this talk to advocate for a more diverse ecosystem of sibling projects in the Nix community — especially to better support efforts like the Nix-based BSD project. Valuable ideas don’t always need to go upstream to have an impact. Though built for experimentation, I run finix as my daily driver — and on my laptop, it’s just as smooth and capable as NixOS. That reliability makes it a practical foundation for trying out new ideas in real-world use, and it’s convinced me that we need more room for experiments like this — and more space for alternative perspectives in our community. about this event: https://talks.nixcon.org/nixcon-2025/talk/Q8VUKL/

In this most remarkable presentation, I chronicle my extensive explorations through the untamed wilderness of enterprise landscape and the experiences of applying Nix within said corporate domain. The audience shall discover the arcane rituals of cargo cults development, learn to navigate the treacherous waters of organisational silos and master the craft of sanctifying Nix usage. Like a seasoned naturalist cataloging the flora and fauna of some newly discovered archipelago, I have meticulously documented the peculiar behaviors of people unfamiliar with Nix, the resistance patterns towards making the effort to learn it, and the curious customs of playing the responsibility ping-pong. This tongue-in-cheek talk aims to share a collection of arguments and concrete actions one can make, to convince others to use Nix at their workplace. The rebuttal of frequent misconceptions (Docker makes nix not needed) included. about this event: https://talks.nixcon.org/nixcon-2025/talk/3RHWND/

Let's follow the lifecycle of a change in Nixpkgs; from opening the Pull Request until the change makes it our local /nix/store. We'll explore all the CI systems involved in this process, how they interact, where and how they're defined in our codebases, and finally the security implications of each step. about this event: https://talks.nixcon.org/nixcon-2025/talk/RF93ZE/

In this talk we go over how we leveraged Nix to build our new Katla synthesizer. We go through setting up development environment, CICD, Linux kernel optimizations, cross-platform compilation and other steps that make Nix a standout solution when building hardware products with a team distributed around the globe. about this event: https://talks.nixcon.org/nixcon-2025/talk/YGL3MV/

Nix is a powerful tool, but it also comes with some well-known problems: a steep learning curve, bad error messages, and slow evaluation. What if we could solve these three problems in one stroke? garn is an experiment in doing just that. With garn, you define derivations with TypeScript instead of in the Nix language. TypeScript is familiar to most developers, well-documented, and supported by rich editor tooling - thus lowering the learning barrier. And instead of stack traces, you mostly get (much nicer) type errors. garn also rethinks the CLI, clarifying the core user-facing concepts in Nix, and how they relate to one another. What exactly is a devshell? A check? A NixOS configuration? What operations make sense with them? By thinking of these as first-class objects instead of "just derivations", garn makes the UX more approachable, and more powerful. The currently-released version of garn generates Nix code, which means we still incur the cost of (often slow) Nix evaluation. But we are working on a second version which ditches Nix evaluation altogether, and uses Nix only to build .drv files. This opens the door to substantial speed improvements, with techniques such as pre-evaluating Nix (FFI) code, caching evaluation in a finer-grained way, async IFD, and even using WASM as an alternative to IFD. This talk will show how garn works both above and under the hood. It's aimed at anyone interested in making Nix faster and more accessible. about this event: https://talks.nixcon.org/nixcon-2025/talk/RJSMCA/

When working on a software project, it can often be useful to spin up local development versions of services that run in production. This can be as simple as running a database to run your tests against, or as complicated as spinning up dozens of machines that talk to each other, while allowing you to observe and debug complex interactions. In some non-Nix projects, docker-compose is used for this successfully, but it requires a lot of manual configuration. In projects where production machines are declared as NixOS configurations, the Nix ecosystem provides a lot of powerful building blocks for running VMs. But existing tools require a lot of manual configuration in order to run networks of VMs locally. They also have unintuitive interfaces and poor documentation, making it hard to use them (and, often, even to know about them!). nixos-compose addresses these problems. It's a polished CLI tool that makes it remarkably easy to: Start one or more VMs from a flake file, SSH into them for debugging, enable network communication between them, and access VMs from the host. In this talk, we’ll tour through the features and implementation of nixos-compose. nixos-compose is an open-source tool built by garnix: https://github.com/garnix-io/nixos-compose about this event: https://talks.nixcon.org/nixcon-2025/talk/BRJ8XS/

This talk will be in the format of an experience report. We will go over how to use the module system to declaratively manage BGP sessions, set up routing policies to manage traffic between hosts using addresses within advertised prefixes using systemd-networkd and nftables in a multi-upstream setup, and how to run a primitive anycast CDN. The talk will also include hiccups encountered while experimenting with the BIRD Internet Routing Daemon, Tailscale, and improvement plans. GitHub: https://github.com/stepbrobd/router about this event: https://talks.nixcon.org/nixcon-2025/talk/7YWTUC/

Discussion & Q&A about this event: https://talks.nixcon.org/nixcon-2025/talk/RZPTFK/

There is a broad range of possibilities when packaging Python with Nix. The amount of Python formats alone can be overwhelming: requirements.txt, setup.py & pyproject.toml, not to mention Conda! This talk aims to explain Python packaging with Nix, focusing on pyproject.nix & uv2nix, but I will also talk about other approaches and their trade-offs. We'll start off with a short primer on the different Python packaging formats & methods while explaining a few of the things that make Python packaging particularly murky & difficult. Then we'll go through a range of Nix packaging possibilities, starting with using plain nixpkgs & culminating in pyproject.nix & uv2nix. Along the way the pros and cons of each will be explored and what approach to use when and where. about this event: https://talks.nixcon.org/nixcon-2025/talk/Y8TSAW/

The most subtle part of Nix's store layer is the exact logic used to sandbox derivations. Mess up the daemon protocol, Local Store SQLite usage, drv file parsing, or other such things, and things should blow up immediately. Fail Fast helps a lot! Mess up the sandboxing logic, however, and you might not notice for a while until you try to build just the right sort of derivation. For most of Nix's history, the sandboxing logic has been embedded within the build scheduling logic (which builds or downloades dependencies) thus entangling it with hefty other machinery that makes all sorts of assumption about how IO, concurrency, etc. should work. In other words, it was not written in a way that made it easy to use from any other program but Nix itself. In the last few months, however, we've finally untangled it and moved it into its own component, and then reworked it to give it a simple interface for FFI. In this talk, we'll briefly go over that work, and then demonstrate its use a simple example executable written in a friendlier language than C++. about this event: https://talks.nixcon.org/nixcon-2025/talk/ZAHLMN/

The history of how the official Nix formatter was successfully established, along with its struggles and lessons. We go over: - How Nix didn't have a formatter for its first 15 years before the first ones were written - How an RFC to standardise the formatter took 3 years, 50 meetings and 600 comments to get accepted - How one of the most active codebases with 40k Nix files and 15k monthly commits got fully reformatted - What problems still exist and what the future of Nix formatting holds about this event: https://talks.nixcon.org/nixcon-2025/talk/GCGE7K/

Explain the current state of the LoongArch64 ecosystem, issues encountered with the Nixpkgs/NixOS port, and what to expect next about this event: https://talks.nixcon.org/nixcon-2025/talk/BMXTFW/

Opening day 2 about this event: https://talks.nixcon.org/nixcon-2025/talk/XVBSXD/

Given the amount of software written in memory unsafe languages, and the rise in supply chain attacks, I prefer to run as much software as possible within some kind of security boundary (mostly using bubblewrap and qemu). Bubblewrap is the sandboxing tool at the core of Flatpak, but it is intentionally designed to be very low level. Using bubblewrap, one can write wrappers for every package on their system, but getting the flags right can be error prone, and often lead to annoying debug cycles to get a program to run correctly. jail.nix is a nix library I have been working on to make wrapping Nix derivations in bubblewrap jails more ergonomic by using higher level combinators to achieve concrete objectives (like giving a program access to the network, or allowing it to render to a Wayland compositor). The library is open source, the source can be found here: https://git.sr.ht/~alexdavid/jail.nix This talk will give a tour of the features of jail.nix and how to integrate it with a NixOS configuration. about this event: https://talks.nixcon.org/nixcon-2025/talk/3QH3PZ/

I made a thing to manage the Linux machines of my friends and family: https://sraka.xyz/posts/ricochets.html, it's a hack with a custom NixOS default channel :) about this event: https://talks.nixcon.org/nixcon-2025/talk/RDSBZN/

Nix's package composition model makes developer environments a natural extension of its core abstractions. A simple shell.nix declaration combined with nix develop provides native tooling access and IDE integration that other build systems struggle to achieve without significant engineering investment. At LinkedIn, I experienced this contrast firsthand while migrating Go repositories to Bazel. I spent six months reverse-engineering Bazel's sandbox internals, writing custom rules to extract SDK paths, generate direnv configurations, and create LSP settings files. This enabled developers to use native Go commands via shell and IDE within Bazel workspaces, which proved crucial for broader adoption (Bazelcon 2024 talk on this topic). In this talk, I'll contrast months of custom engineering against Nix's declarative approach - just a few lines of config that solve the same problem in a manner that's harmonious with the build system. about this event: https://talks.nixcon.org/nixcon-2025/talk/HMKXYP/

Kubernetes is good for many machines with complex networking setups, but not that good for a 2-machine one, especially when there's only one maintainer and zero documentation. At GeekPie, I've migrated our mirror infrastructure to NixOS and in this talk I want to show how Nix helps us achieve more with less code & maintenance. about this event: https://talks.nixcon.org/nixcon-2025/talk/MKJPLZ/