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!

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.

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

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

While Bash is a tried-and-true and highly well-known quantity, it's not particularly expressive and it has known "footguns" surrounding things like string parsing. Nushell is a recent entry into the world of shells. It's written in Rust and it offers robust data types and safety guarantees that have a lot to potentially offer to Nix. In this talk, I'll teach you not just about Nushell, how I built it, and how it works, but also about the realisation process itself.

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.

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.

Disko is a declarative disk partitioning tool that allows you to specify the layout of your disks using a simple Nix expression. It can create, resize, format, and mount partitions on any device that supports block operations. It also supports encryption, ZFS, RAID, and LVM.

Nixos-anywhere is a tool that can install NixOS on any cloud or bare-metal environment over SSH. It can detect whether the target machine has a NixOS installer; if not, it can use kexec to boot into one. It then uses disko to partition and format the disks according to your configuration, and installs NixOS with your desired packages and secrets.

With these tools, you can easily deploy NixOS on any machine without needing physical access or manual intervention. You can also reuse the same configuration for multiple machines, ensuring consistency and reproducibility.

In this talk, we will demonstrate how to use disko and nixos-anywhere to install NixOS on various scenarios, such as a virtual machine, laptops or bare-metal servers. We will also discuss some of the challenges and limitations of these tools, and how they can be improved in the future.

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.

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

Full virtualization suffers from overhead and performance degradation due to software emulation of real hardware. MicroVMs are optimized by replacing this emulation with interfaces that have been optimized for the virtual machine use-case: VirtIO.

microvm.nix helps you building and running NixOS on different virtual machine managers. You can use it in different use-cases, for example as a more isolated alternative to nixos-container.

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.

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

During this interactive session, board members will share their insights on the current state of Nix, discuss ongoing projects, and foundation plans for the upcoming year.

In addition to sharing the board's roadmap, this panel will also facilitate an open dialogue with the community in the form of Q&A.

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.

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.

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

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

Nix has various different store implementations. For example the daemon store, which provides store access to unprivileged users on multiuser systems.

Some caveats apply, but the new local-overlay store lets you combine an existing lower store with an upper layer, similar to the Linux Overlay Filesystem. Anything in the lower store will be accessible via the overlay store, while modifying the overlay store will only change the upper layer and leave the lower store untouched.

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.

There are a lot of tools and methods for getting documentation and finding things in Nix but they are often not well publicized and form peoples' private workflows. Substantial progress has been made on this, for instance, with nixd, but there are other methods that still have their place when more advanced tools don't have perfect code context. This talk introduces a novel NixOS-modules ctags implementation allowing finding option definitions nearly instantly. It also presents how to navigate nixpkgs using nix-doc for ctags and to get function documentation in the Nix repl, how to fall back on unsafeGetAttrPos, and how to use the Nix debugger.

I will briefly dive into the internals of NixOS to show the introspection capabilities it provides for where settings come from, and how to load a NixOS configuration into the repl for inspection in the first place.

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.

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

In this talk, I'll go into why and how you would set up a system with ephemeral root storage and how Impermanence can help you manage the state you want to keep between reboots.

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.

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

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.

This talk will give a status update on the current state of the project, and an outlook on the roadmap.

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.

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.

Links: https://github.com/ZilchOS/bootstrap-from-tcc, https://github.com/ZilchOS/core, http://bootstrappable.org

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

Since 2006 I've been helping friends and family run desktop Linux. This lightning talk reflects on the distributions I've used in the past and why I'm now using NixOS with Flathub enabled to make NixOS accessible to non-expert Linux users.

Opening ceremony for day 2!

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.

Examples of site-specific variations:

• timezone
• time server
• network share
• SSL/TLS certificate

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 lightning talk will offer a brief overview of languages that can compile to Nix. For instance, Dhall, PureScript and Nickel (even though it doesn't directly translate to Nix). What do the generated expressions look like? Can I use them to write a package definition or a NixOS configuration?

EDIT: I will not have the time to introduce an experimental toy project of mine: a Scheme dialect that compiles to Nix, featuring a static type system inspired by the contracts library. But I will be more than happy to discuss it while HackDay!

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.

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.

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.

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.

What you will learn:

• Setting up nix to work with argocd
• Deploying simple applications written purely in nix
• Utilizing the public helm charts in nix, with custom configuration and resource overriding without the chart forking
• Using nixpkgs' modules system for complicated muti-cluster deployments

Interesting things you can do using the proposed C API

Nix plugins have been a possibility for years, but haven't caught on. I'll talk about the proposed new C API and what you can do with it.

• Using Nix from your own tooling without wrapping the CLI
• Writing Nix plugins

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.

Organist is a Nickel library and tool aimed at serving as the entry point for all the development tools, and featuring in particular a Nickel frontend for Nix as an experiment in changing the surface language. Changing the frontend used was also an occasion of changing the way we declare, compose and override packages, with a framework based on merging records (a la module-system) rather than stacked wrapping functions and explicit fixpoints.

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

Nixpkgs and NixOS go a long way in stabilising a program's inherently random build and runtime behaviour. Meanwhile the scientific computing software, and the state of the art "AI" research code in particular, heavily rely on dynamic and "impure" deployment techniques. These include e.g. dynamic linkage using "dlopen", unenforced assumptions about paths, distribution of pre-built black-box binaries, largely facilitated by the use of dependency solvers, and more. Sometimes these "impurities" are necessary, as when using driver-aware libraries like OpenGL or CUDA. This seemingly makes it cheaper to relax the requirements to reproducibility set by Nix and embrace tools such as pip, conda, singularity (apptainer) and docker. 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.

P.S. This description is preliminary

.