Opening notes, shoutout to sponsors, running through the agenda, thanking everyone, kicking off, rules/guidelines

Cover the dynamic landscape of Nix's growth, innovation, and future possibilities. This session will provide a comprehensive overview of the major milestones Nix has achieved over the past year, the challenges we've faced, and the exciting developments on the horizon.

Flakes are a format for distributing Nix-based assets such as Nix packages, development shells, CI jobs and NixOS modules. The flake specification doesn't impose any restrictions on the contents ("outputs") of a flake, and these can be arbitrary Nix values. While this makes flakes very flexible, it means that there is no generic way to find out what a flake provides, or to check its correctness. To work around this, tools such as nix flake show and nix flake check have built-in support for a fixed set of flake output types such as packages and devShells. Unfortunately, this set cannot be extended by users to handle new flake output types.

In this talk, I propose flake schemas, which are essentially Nix functions that enumerate the contents of a flake output, including documentation, checks and options. Flake schemas do not impose a type system on flake outputs - it is entirely up to the schema function how it checks the flake output. Flake schemas allow us to remove all output-specific code from commands like nix flake {show, check, search}, making it easier for developers to introduce new output types.

Flakes is seeing widespread and increasing adoption, but some people and projects are still hesitant to move to them because they have requirements that are cumbersome or impossible to address with Nix Flakes in their current incarnation (there are also other reasons, but I will be focusing on the technical ones).

I will talk about the gaps I see in the current design of Flakes, and how these gaps could be filled in the future without compromising the core goals of Flakes. I will also explore the implications that this will have for the broad range of projects already using Flakes as it exists today.

For almost 20 years now, adding a new package to Nixpkgs required editing the all-packages.nix file, which grew to over 40000 barely-sorted lines this year. In addition, an appropriate place for your package definition had to be found in the loosely-categorised pkgs hierarchy. Especially with the recent growth of Nix, this has been a frequent cause of confusion for new contributors.

However, in the months leading up to NixCon, this is all changing with the acceptance of RFC 140, originally designed by the new Nixpkgs Architecture Team. This proposal allows most new packages to be added by simply creating a new directory in the right place with a name matching the desired attribute name.

In this talk I will go over the new package contribution process, along with its limitations, historical context, interesting implementation details and future work.

The question of how to more manage the project has come up once again. How do we structure ourselves to maximize participation, be effective and enjoy ourselves doing so?

This talk will describe our experience shipping a product as a NixOS appliance that supports site-specific customization after deployment.

NixOS' declarative model is a good match when one can write down the complete system configuration. How can we handle dynamic aspects of the configuration? That is, anything we expect to vary such that we cannot specify it fully at build time.

We will share the mechanisms used to achieve this and our assessment of the trade-offs involved.

Creating a NixOS workstation configuration for non-Linux experts using Flathub with a graphical storefront so they can install the apps they want.

What are the languages that target Nix? Why might someone choose not to write an expression directly in Nix? How do these languages differ from one another?

This talk hints at how defining Nix packages (and development shells in particular) with another language than Nix influences the way we think about them, and discuss whether there are lessons to be learned from here for Nixpkgs or Nix itself.

A rundown of what the Nix documentation team has done since last NixCon

An interactive session with the NixOS Foundation Board, going through the past year and looking into the next.

The underlying machinery of the NixOS module system, evalModules, is useful for more than just declaring Operating Systems. At Replit, we use it to declare IDE plugins for language runtimes, code intelligence (LSP), runners, packagers, and debuggers. Learn how you can use evalModules for your own applications and how we use it to declare an IDE. During the hackday, let's adapt the IDE plugins to emacs, vim, or vscode!

The NixOS virtual machine testing framework is very powerful, and allows for convenient testing of entire NixOS machines. However, some capabilities can only be tested by booting a physical machine with a given NixOS closure. This talk describes some work done toward the goal of enabling testing NixOS closures on physical machines, with an example of testing NVIDIA Jetson devices using the "jetpack-nixos" project.

The Impermanence project aims to make it easy to build systems where the root storage is erased on every boot.

Interesting things you can do using the proposed C API

Congratulations, you’ve convinced your friends / peers / coworkers to give Nix a try. Now the hard work starts: you have to actually teach it to them! Nix might be hard to learn, but it sure can be a fun journey! In this talk, Rok Garbas from flox will share the tools and techniques you need to teach Nix to your friends and colleagues…and, most importantly, what NOT to teach.

Opening ceremony for day 2!

Even with recent improvements in documentation, sometimes the most expedient way to understand nixpkgs and NixOS is to read the source code. However, that's not trivial: there are now 2.9 million lines of Nix source in nixpkgs. This talk shows several methods of finding the sources behind things in nixpkgs and NixOS from using ctags to various lesser-known tricks in the repl.

After this talk, getting around in nixpkgs should be familiar and quick.

If you ask three NixOS users what their favorite NixOS deployment tool to update a NixOS system is, you might get four answers. However, installing NixOS on a machine can be a tedious and manual process, especially if the machine is not physically accessible or does not have a NixOS installer. In this talk, we will introduce two tools that can simplify and automate the installation of NixOS on any machine with Linux and SSH access: disko and nixos-anywhere.

Nuenv is an alternative builder for Nix derivations that uses Nushell rather than Bash. It offers enhanced expressiveness and type safety to Nix.

Rust is a programming language with a knack for ergonomics in a space where robustness, correctness, and speed often come at the cost of many papercuts. Nix is a project focused on building software in a robust, correct, and deterministic way. These two projects should be best friends, right? In this talk Zach Mitchell from flox and the Documentation Team will give an experience report writing Rust bindings for Nix. What makes bindings difficult? Which bindings can be autogenerated? Which can (or should) be written by hand? Tune in to find out what went well, what was painful, and what didn't work at all.

2nd session

In this quick talk, tomberek will introduce an upcoming experimental feature that has been in development for several years: dynamic derivations (RFC92). The talk will describe the motivation, the current status, implementation details, and a teaser of user-facing value they provide.

References:

• https://github.com/NixOS/rfcs/blob/master/rfcs/0092-plan-dynamism.md
• https://github.com/NixOS/rfcs/pull/92
• https://github.com/NixOS/nix/issues/6316

We should briefly see (or recap) what effort it takes today to provision via Nix a typical stack that includes Pytorch and CUDA, see when Nix could still be the better choice, and when Nix may seem to hinder progress. We should try to argue that the obstacles we observe can be eliminated at the nixpkgs level

A new Nix store implementation — local-overlay — that lets you create a writable layer over another underlying store.

In this lightening talk, we'll walk through process of creating a virtual machine using NixOS which will start Firefox and visit a pre-configured website. We'll work-around the performance issue of building multiple VMs when there are many configured websites. To do so, we'll employ flake outputs for caching and QEMU's ability to forward configuration options to the VM. At the end, we'll have a browser setup with improved isolation and alternative UX.

The team at flox has been producing a series of Nix in the Wild articles that showcase users and organizations doing innovative things with Nix. I’d like to take a quick few minutes to share some of these stories and invite others to participate.

.

Building every operating system starts from something. I'm not as hardcore as the stage0 project folks going from assembly to Guix, but a shorter path from a ~320 KB TinyCC binary to Nix to a proof-of-concept Linux distribution also proved to be a story worth telling.

We'll begin our journey by executing a -nostdlib C program with TinyCC, compile our way out towards a libc and a shell, work through older compilers to modern compilers and build Nix. Then we'll walk the same path again once over, but this time, we'll use Nix. Finally, in a different flake, we'll reimplement some of the founding nixpkgs patterns, work our way from toolchain to Linux and arrive at a bootable .iso. Corners will be cut, hacks will run amock, Nix will be both praised and complained about, reproducibility will be earned hard, and some patches will get upstreamed.

It's been twenty years since Nix was unleashed upon this world, and yet, the only real alternative is Guix‽ Well, not on my watch! I've been working on Zilch for a while now, and it's starting to be ready to be released to the wild. This talk will describe what this fresh new Nix-compatible alternative is, how it came into being, and what the wider Nix community could learn from it.

Tvix is a modern design and implementation of the Nix package manager (GPLv3). It brings a modular architecture in which components such as the build environment or package store are replaceable, which enables new use-cases and platforms.

I've been using a Librem 5 running NixOS for a few months now as my daily driver. Here are the challenges I've faced, what works and what doesn't.

Nix is an amazing build tool not only for applications, but also for the infamous "yaml engineering". Join Volodymyr to learn about the journey of using nix along with argocd to deploy payloads into kubernetes.

microvm.nix builds NixOS for a few virtual machine managers in a few different use-cases

Closing, thank yous, sponsors, what's next, anything else

Hackday governance session

Join us at nixcon 2023 for a free short training on Nix flakes! Learn the basics of Nix, including installation, command usage, and writing your own flake. Discover how to build flakes in GitHub CI and familiarize yourself with key terms in the Nix ecosystem. Don't miss this opportunity to enhance your Nix skills and expand your knowledge of declarative package management.