NixCon 2022

Beneath NixOS, Nixpkgs, and the Nix expression language is the “Nix store” interface — a deceptively powerful interface that includes includes both storage itself and also building. Although we rarely use it directly, it’s at the heart of what makes Nix great. By understanding the semantics of the Nix store interface in isolation, intermediate and advanced Nix users can expand their intuition and problem solving skills while working with Nix. The ways we both use and implement the interface will keep evolving in myriad ways, but the interface itself, or at least the core ideas behind it, have remained remarkably stable, anchoring everything else we do.

A presentation of the cross-compilation infrastructure, and the troubles and successes using it for an embedded system.

In the data acquisition / instrumentation world, we often get to use embedded boards provided with a Buildroot or Yocto Linux OS. But, as the project tends to grow, these images tend to get unmaintained, which drove us to try to compile our own Linux images, using NixOS. We start with an introduction of the cross-compiling infrastructure of nixpkgs, and how you can cross-compile Nix packages, and NixOS images for embedded systems. We will then see how well it applied to our own use case, the troubles it gave us, and how different it is compared to your usual Buildroot or Yocto Linux images.

A few guidelines to not make people run away when talking about Nix.

We use Nix and love it, so we want to talk about it with people to whom it could be useful: our community has grown enough to demonstrate that some people can and have been convinced. However, most of the time, those people were interested enough by the few keywords on http://nixos.org to take the time to give a damn. I've practiced talking about Nix to my friends who don't care _at all_, and would like to share my findings.

Based on simple examples, this will showcase error reporting improvements implemented in the open https://github.com/NixOS/nix/pull/6204 PR.

For some errors, nix reports an odd, seemingly unrelated position. Or no position at all. Usually, the same location is used for several potential errors inside a given scope. This PR makes the relation between the error and the location more explicit. For example using "in the second argument of the function call" when the only available location is the function call itself. In some occasion, it adds error messages with no location, and an intermediate "context" trace for the closest known location.

In this lightning talk, I will present my port of Wayland 1.21.0 to macOS, as well as my epoll-shim setup hooks that make it easier to package cross-platform Wayland applications.

jupyterWith has made significant improvements this year towards maintainability and ease of use. This talk will discuss those improvements and how you can quickly start creating reproducible Jupyter notebooks.

JupyterLab is a popular web-based interactive development environment for notebooks, code, and data. However, it lacks the ability to lock dependencies and therefore lacks good reproducibility which jupyterWith overcomes by using Nix and Poetry. jupyterWith aims to be simple for researchers and developers and requires minimal understand of Nix and Jupyter to get started.

Big closure sizes bog down deploys by wasting time and space shipping around unnecessary bits, particularly with Docker containers. Nix provides tools to analyze closures, but both the graphical and textual methods leave something to be desired, especially when dealing with NixOS system closures with hundreds of derivations. I'll demonstrate debugging excessive closure size of a Docker image of an open source NodeJS application, bringing the image size down from 300MB to around 100MB. In this session, I'll introduce a new tool I've built that can show system closures graphically as network-graphs, making debugging the causes of excessive closure size easy, irrespective of the number of derivations involved.

Every Nix derivation, including NixOS system images, has a so-called closure. The closure includes every dependency and transitive dependency of the derivation. On your local development system, excessive closure size mostly just wastes disk space, but when deploying software built with Nix, every dependency, including ones that are not actually required to run, needs to be shipped to the target system in the deployment. Shuffling around these unnecessary bits can very quickly add up to significant slowdowns. It is very easy to accidentally introduce bugs in derivations that cause unnecessary runtime dependencies and add closure size. A runtime dependency in Nix is created by simply having a store path of some other derivation anywhere in the output, perhaps in a path to an interpreter for a script that is never called, or something else. Sometimes this isn't even your fault! Nixpkgs has closure size bugs too. Nix provides tools to view closure dependencies in a table, or to generate a graph with GraphViz. Unfortunately, the table is hard to divine the meaning of, while the built in graph output doesn't show sizes and runs into GraphViz performance and usability limitations on very large numbers of nodes such as appear in NixOS closures. My alternative graph viewer lets you have your cake and eat it too: it scales up to very large graphs and shows more details than either built-in option. I'll demonstrate debugging excessive closure size of a Docker image of an open source NodeJS application, bringing the image size down from 300MB to around 100MB.

High performance compute clusters in a scientific environment are rather specialized environments, that provide highly specialized software packages for scientists. Performance optimizations, specific to the given cluster, are an important part of the setup. In many places, these packages are still hand compiled, hand tested and made available via the "modules" system, which makes upgrading a package a difficult process. To the experienced Nix user, it may be obvious that Nix can solve problems with providing software to users while, at the same time, also providing a path to reproducibility of scientific results. We thus have developed the NixOS-QChem overlay to provide computational chemistry software packages in a reproducible, transferable, and customizable way. The overlay provides more than 30 chemistry related software packages, as well as optimized versions of upstream nixpkgs packages. In this talk, I will give an overview over the overlay and how we have adapted it for a scientific compute environment, as well as the challenges that we have faced while packaging some more exotic packages. The focus here will be mainly on the Nix related aspects and lessons learned that apply also to other scientific packages.

Resources: * Link to the overlay: https://github.com/markuskowa/NixOS-QChem * We have published a paper in a scientific journal, describing the approach: M. Kowalewski, P. Seeber, “Sustainable Packaging of Quantum Chemistry Software with the Nix Package Manager”, [Int. J. Quantum Chem., **122**, e26872](https://doi.org/10.1002/qua.26872) (2022).

Nix has introduced the world to store-based systems and ushered a new wave of reproducibility. These new systems however are built atop long established patterns and occasionally leverage them to band-aid over the problems Nix aims to solve. How much further can we leverage the store abstraction to rethink long valued established patterns in Unix based operating systems? This talk will introduce some of the simple improvements one can uncover starting at the linking phase of object building and process startup. The authors introduce Shrinkwrap which can greatly improve startup performance and further improve reproducibility for applications ported to Nix by making simple improvement to how libraries are discovered and leveraging the store further. Additional explorations for improvements during the linking phase will be discussed and explored. It's time we rethink everything.

Deep dive into Cachix deploy design decisions and demonstration of common developer workflows

Flakes are becoming the *de facto* standard way of packaging Nix-based projects. However, flakes have some major problems due to the way Nix enforces hermetic evaluation: flake inputs (such as Git repositories) are copied to the Nix store, which is slow for large repositories, massively wastes disk space, and leads to confusing error messages. I will discuss recent flake changes that not only solve these problems but provide a bunch of other benefits, such as the ability to apply patches to inputs. I will also talk about future directions for flakes.

NixOS is extremely versatile in terms of ways to get it onto machines! Let's explore: - How a Linux system boots - What a NixOS system consists of - How this enables deploying it to a wide variety of environments - Various examples environments into which a NixOS system can be deployed

[Nix2container](https://github.com/nlewo/nix2container) is an alternative implementation to our `nixpkgs.dockerTools`. Its main difference is to rely on Skopeo to actually build the image: this allows us to use the container image building logic of Skopeo and also provide opportunities to implement more aggressive layer caching and skipping.

In this presentation, we first take a look at our current `nixpkgs.dockerTools` functions and explain why they have been introduced. In the second part, we will see how nix2container differs from dockerTools functions: how it basically works and what are its unique features.

This talk will discuss one possible strategy for building and deploying small and efficient Nix containers. We will go through what has been tried before and then present a personal deployment of the proposed system which has been actively used and proven to work. We will also explore and explain why the current solutions available aren't suitable as shown by the lacking prevelance of Nix containers in the Nix community.

How we pull together to set the community and Nix up for decades of Success

We want to set Nix and the community up for success in the upcoming opportunity of igniting the inflection point that will lead Nix to be a household name in the industry's software developer life cycle. Through various companies' efforts and extreme external advocacy, more bits of the world are coming to be aware of Nix, the Nix community and of solutions provided through it. This is catalyzing the start of the inflection point. Talk through strategies, ideas and takeaways from other successful communities.

Making Nix follow the principle of least privilege by removing as much as possible the need to it to run as root

In multi-user mode, the Nix daemon is expected to run as root. This is quite annoying from a security point of view as the Nix codebase is (somewhat) large and not properly audited. Because of that it is also an adoption blocker in some places. I turns out that there's very few places where Nix actually needs to be root, and we can remove or isolate these, as done in https://github.com/NixOS/nix/pull/5380.

Signatures are annoying when you are trying build software reproducibly, especially when deeply embedded in the output artifact. Let's look at how we can tackle this problem elegantly with Nix.

Reproducibility means that someone else can independently recreate exactly the same binary artifact. This is very useful for confidently knowing what source code a binary artifact was built from. People are analyzing artifacts with tools like `diffoscope` to exactly locate differences between two artifacts built using the same build instructions. For complex projects even when looking at an exact difference in the output that way, it is not always easy to find the cause of that difference. In general using Nix to split the build instructions into smaller steps can help us make this process easier, because we can notice differences at the end of the intermediary step that introduced them, as long as we are `nix build --rebuild`ing the right build steps. Even then signatures are still a problem, because we can never really reproduce a signed artifact without access to the signing key and even with access to the key not all popular signing schemes produce signatures deterministically. We either have to substitute in the expected signatures or keep track of those expected differences. There is a nice pattern that we can use for always substituting the correct signatures with Nix, which makes it easy to verify embedded signatures as part of such an independent recreation process even for a large and complicated artifact. The same pattern also takes advantage of Nix's binary caches to automatically obtain all the required signatures, which are ideally the only thing we cannot reproduce.

Systemd 250 introduced a way to manage encrypted "credentials" (secrets, reallly) in a way that I think NixOS could benefit from. We're not using it anywhere yet, but we should. This describes briefly how systemd wants to manage credentials and how to integrate that in a NixOS setup.

This talk is supposed to demonstrate a nice side-effect of being able to build old Nix expressions and even having a binary cache with the build artifacts available: for the data migration from a legacy project we had to debug a flash-based component. Even in 2021 where the Flash player is dead and unavailable it was trivial to revive this piece of old software with Nix (and web.archive.org).

My laptop environment is the staging ground for my life as a developer. In this talk, I’ll tell the story of how a Nix flake I call Nome, my “Nix home,” provides not just a fully declarative and easily reproducible global environment on my laptop but also a variety of templates and other helpers that have supercharged my per-project environments as well.

Years ago, I defined my laptop environment using a pretty standard janky jumble of dotfiles and shell scripts. Years after first encountering Nix, Home Manager gave me my first taste of using declarative logic to define my system, and I continue to tweak my Home Manager config every day. But now I’ve gone several steps further and created a Nix flake that I call Nome—my “Nix home”—which defines my global environment using Home Manager but also provides a set of NixOS configurations, flake templates, Nix-built scripts, Nix helper functions, Nix-defined Docker containers, and other goodies that have markedly improved my productivity and eliminated a whole class of paper cuts from my daily work life. In this talk, I want to provide a basic overview of Nome’s flake outputs and provide a brief demo of how I use it to get up and going in a new project.

Jitsi Meet is one of the most widely used options for open source video conferencing. In addition to basic video conferences, it also supports a substantial ecosystem of additional components and features, and while these add important functionality they also increase substantially the complexity of a deployment. As part of Summer of Nix 2021 and 2022 we have been working on dramatically simplifying the process of doing more complex, featureful deployments of Jitsi Meet by using the powerful packaging and configuration tools of NixOS. This talk will cover what we have done so far on this project, the work that still remains, and what this means more broadly for packaging and deploying large server-side open source projects on NixOS.

flox, a quick run through of bringing Nix to work, making it simple and scalable

In this talk, we will address the different existing strategies to package an arbitrary Rust crate. Our goals are to try to minimize the amount of Nix code required to quick start, discussing how to deal with overlays, and finally demonstrating why Nix offers a greater cross-compilation developer experience than Cargo.

Existing solutions that will be compared are [`nixpkgs`](https://nixos.org/manual/nixpkgs/stable/#compiling-rust-applications-with-cargo), [`naersk`](https://github.com/nix-community/naersk), [`crate2nix`](https://github.com/kolloch/crate2nix), [`cargo2nix`](https://github.com/cargo2nix/cargo2nix) and [`crane`](https://github.com/ipetkov/crane) (used by [`dream2nix`](https://github.com/nix-community/dream2nix)). We will analyze what are the derivations produced for each of those and inspect how IFDs are used.

Nix and Nix users tend to see a little nugget of Nix and crystalize everything around it. Nix is very "viral" in that way. Sometimes you find imperfections in the system and it breaks everything: it is very difficult or impossible to finish the "Nixifying" or Ice-Nineing of your project. How frustrating! We also tend to be "Nix Maximalists", pushing Nix to the very edge of our domain. Building as much as possible as close to the final deliverable as we can. This has extraordinary benefits and can present a really fun puzzle. But in some cases it has real costs around performance, usability, and adoption. Let's talk about software which disrupts the crystal: software which is hard to "nixify." Let's also talk about amazing user experiences that become possible by taking one step back from the edge.

An overview on how we make use of NixOS in our satellite payloads as the backbone of our wildfire detection services.

At OroraTech our mission is to provide a holistic wildfire intelligence service; for which we design, construct, and deploy custom satellite payloads in order to help achieve that goal. For its reliable and reproducible nature, we've decided to make use of NixOS as the underlying operating system of our future payloads. In this presentation, we want to briefly show you a real world example of how Nix and NixOS have made software deployment a breeze, even in extreme scenarios such as outer space

Documentation has always been a sore point for Nix, and the 2022 community survey results have clearly shown demand for improvement. This talk reports on this year's proceedings in better documenting the Nix ecosystem.

The talk outlines - what the problems with learning Nix have been in the past - what we have done this year to address them - a vision for the near-to-mid-term future - what you can do to help.

A beginner-oriented improvised QA-style lecture on Nix, where you can bring your questions and we'll answer them with more context, examples, alternatives, tradeoffs and related topics.

A beginner-oriented improvised QA-style lecture on Nix, where you can bring your questions and we'll answer them with more context, examples, alternatives, tradeoffs and related topics.