Chaos Computer Club - archive feed

This talk will explore the ideas from Lennart's "Fitting Everything Together" blog post, particularly the A/B partitioning scheme and its bootloader design, comparing it with the approach used on the SteamDeck. Spoiler alert, we're not using sd-boot. We will focus on the requirements that drove us to the latter design, some implementation details, and hurdles we needed to overcome to achieve that project. Lastly, the idea of finding common ground will be entertained where audience participation is greatly encouraged. What features would be acceptable by the wider systemd community? Would those be enough for the SteamDeck to jump ship? about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/SMQPWM/

Modification of the kernel command line has historically been one of the easiest ways to customize system behavior. Bootloaders allow for persistent changes via config-files and on-the-fly changes interactively during system boot. System behavior changes made via the kernel command line are not limited to the kernel itself. Userspace applications from installers to init systems and beyond also take input from /proc/cmdline. It is clear that some kernel command line options are desirable (console=ttyS0 verbose) and possibly even necessary. Others, such as the cromulent 'init=/bin/sh', can allow circumvention of benefits that Secureboot and TPM provide. How to control access to kernel command line modification is a non-trivial subject. A recent pull request to systemd that added "command-line addons" garnered hundreds of comments. This talk will cover: * The stub loader 'stubby' and its allowed-list approach to kernel command line options. * Systemd-stub’s solution for command line customization * System changes that can be made through kernel command line. * Alternative channels such as smbios oem strings, or qemu 'fw_cfg' about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/T3QFGS/

The build system should get out of the way to let us focus on our tasks, not be distracted by slow or unreliable builds, get fast feedback on changes, and let us know what’s in the software we’re shipping to our users. But, what does it take for a build system to be really fast and reliable? What does it take to know what’s in the software? It requires aggressive parallelism and distributed caching to avoid redundant work between colleagues. And it requires complete knowledge and control of dependencies, build isolation to identify mistakes, and reproducible builds to verify results across machines and strengthen supply-chain security. In this talk you will learn how [Google’s open source build system Bazel](https://bazel.build/) and the [purely functional package manager Nix](https://nixos.org/) join forces to provide fast, correct, and reproducible builds. In this talk I will explain what we mean by correct builds, and will motivate why fast and correct builds are important and why you would care about reproducible and isolated builds. We will see how many common build systems fail to provide these desirable properties. You will be introduced to [Google’s open source build system Bazel](https://bazel.build/) and will learn how it provides fast builds, how correctness and reproducibility is relevant, and how Bazel tries to ensure correctness. But, we will also see where Bazel falls short in ensuring correctness and reproducibility. You will learn about the [purely functional package manager Nix](https://nixos.org/) and how it approaches correctness and build isolation. And we will see where Bazel has an advantage over Nix when it comes to providing fast feedback during development. I will share how you can get the best of both worlds and combine Nix and Bazel and how you can get started with these tools. But, we will also touch on potential caveats and shortcomings of this approach. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/77YDZ8/

This talk will be a whirlwind overview of NixOS modules and the lessons I've learned with maintaining and writing new ones. Nix modules are the core of how you organize configuration and service config, but there's a lot of "draw the rest of the owl" subtext as to how you actually go about writing them. This talk covers some best practices for how to write and organize your NixOS modules so that you can have fun and hopefully profit from it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/DP3JXQ/

openSUSE is a general purpose, rpm based distribution. One of it's unique features is the use of btrfs snapshots to offer rollback of the root file system of both traditional as well as transactional systems. This talk explains the challenges faced to integrate systemd-boot into openSUSE. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/E9NVZE/

The Talos Linux distribution is built from scratch with the goal of providing a secure, verified, and minimal-footprint operating system for running Kubernetes clusters. Talos is designed to be immutable, minimal, and secure. Talos includes only the bare minimum required to run Kubernetes. This talk will cover how Talos uses Unified Kernel Images (UKIs) to provide immutable, verified, and secure booting. We will also cover how Talos partially conforms to the Linux Userspace API Group specification (UAPI) to implement some of the best practices with regards to fully verifiable TrustedBoot extending to the userspace. With the upcoming Talos 1.5 release, Talos ships with custom ISO and metal images that are UKI compliant. This means that the kernel, initramfs, and the root filesystem are all signed and verified by the bootloader. This allows Talos to provide a fully verified boot process from the bootloader to the userspace attested by TPM. This talk will cover the following topics: - Building UKI (ukify.py implementation in Go) - Issues with reproducibility - sd-boot - sd-stub - Upgrades/Rollbacks - systemd-measure and systemd-cryptenroll partial implementation in Go Future work: - IMA attestations for userspace runtime binaries (etcd, kubelet, containerd, etc) - Talos system extensions as sd-stub compatible sysexts - Kexec with Secureboot (how can we verify the TPM PCR values are populated correctly with values from new UKI) about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/Q9YBUZ/

The talk wants to provide a brief introduction into Confidential Containers Project. We'll discuss the rationale behind Confidential Computing and how concepts like Trusted Computing or Remote Attestation can be leveraged by end-users to guard their workloads not only from malicious actors but also their cloud service provider. Confidential Containers, an open-source CNCF project, aims to extend the experience of deploying cloud-native software on Kubernetes with the option to move sensitive workloads into confidential enclaves with minimal friction to the user experience. We'll introduce the components and container technologies we are using to achieve that, hint at some conceptual problems we are facing and provide a simple example of how confidential containers work in practice today. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/GFDUHW/

The Linux Userspace team at Meta aims to make significant contributions to upstream userspace projects, while also ensuring that Meta is able to leverage those improvements. In this talk we'll give an overview of the team and brief history of how it was formalized. Then we'll dive deeper into some of the efforts we've worked on with the open source community and features we've adopted internally. Come if you enjoy hearing about systemd, BPF, distributions, and more! about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/YAHVZG/

Confidential compute is a new compute and programming paradigm to run an application in enclave, a run-time encrypted and authenticated trusted execution environment. We give an overview of the current technologies provided by AMD, Intel and ARM. We also give an overview of open source tools to leverage compute along a tutorial to enclave any applications with few command lines. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/7LVG99/

All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/8P7XKH/

All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/AKNDS3/

All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/VAY88J/

The journey of developing a Linux platform to require very little in the way of configuration management, and how to virtually eliminate the need to modify code to change configuration. From configuration via scripts and evolving through a couple of configuration management products, we have used the idea of matching actions to timescales to transform how we do configuration management. We now do very little of it, and we have dramatically reduced its complexity. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/PVJQTH/

A quick overview of the work in progress to plumb PID FDs through Linux userspace, to achieve resilience and security improvements Process ID File Descriptors were introduced in Linux v5.3. They allow tracking a process reliably, without risking races and reuse attacks, as they always refer to one single process regardless of the actual PID, so if the process goes away the file descriptor will become invalid, even if a new process with the same PID reappears at the same time. Tracking processes in userspace is needed for various purposes, for example to authenticate actions via Polkit. This has been historically fragile, and various workarounds such as tracking a PID plus a UID plus a start time were put in place. D-Bus implementations also have methods to query a D-Bus' endpoint's PID, UID and GIDs. Recently work has been done to plumb PID FDs through all these components - systemd is able to receive queries asking for the session information or unit information via a PID FD, D-Bus implementations return the PID FD of a D-Bus endpoint via GetConnectionCredentials()/GetConnectionUnixProcessFD() (and they track processes via FD rather than PID), and Polkit allows writing rules authorizing by the systemd service name, which is possible to do safely thanks to using FDs all the way through. This lightning talk will quickly go through these improvements, showing how PID FDs can be used to improve userspace and provide concrete benefits. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/T3LJAM/

Image based OS updates are the future. One way to handle updates is via content-addressable synchronisation software, like casync and desync. This talk with give a presentation about the two - their overall design, feature set and strengths and weaknesses. It will also demonstrate a real world use-case of them. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/9MVYFU/

Some quick numbers and maybe curiousities from our work on evaluating which libraries need to be rebuilt for 64-bit time_t on armhf in Ubuntu using abi-compliance-checker. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/R3SWBQ/

The utmp implementation of glibc uses on quite some 64bit architectures a 32bit time variable, which leads to an overflow on 03:14:07 UTC on 19 January 2038. This talk will explain the current work on replacing utmp with logind. The year 2038 problem (also known as Y2038) is a time formatting bug on Unix systems with representing times after 03:14:07 UTC on 19 January 2038. This happens with a 32bit time_t, not with a 64bit time_t. The general statement so far has always been that on 64bit systems with a 64bit time_t you are safe with respect to the Y2038 problem. But this isn't correct: on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries) glibc defines __WORDSIZE_TIME64_COMPAT32, which leads to the fact, that struct utmp (used for utmp, wtmp and btmp) and struct lastlog uses int32_t instead of time_t. So we have a Y2038 problem, which is not easy fixable, as this would require ABI and on disk format changes. In this talk I will speak about the background, which tools are affected and a radical solution: drop utmp, wtmp, btmp and lastlog completely and make use of systemd-logind and other tools instead. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/3Z7XEE/

A walkthrough of an interesting use case for the `FICLONE` ioctl: cloning file data into a tar archive, and cloning files out of it again. "Free" archiving and unarchiving at zero-copy speeds! Topics: - Copy-on-write and the `FICLONE` ioctl - The ancient `tar` format - A trick for adding arbitrary padding to the `tar` format in order to force file system page alignment - How to avoid symlink attacks and other TOCTOU issues, using the fairly recently introduced (linux 5.6) `openat2` system call. - An interesting bug in GNU tar At the end you'll receive a free autographed copy of [deduptar](https://git.sr.ht/~nullenenenen/deduptar/tree/master/item/README.md) to use for party tricks. 🥳 about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/99PZDY/

In light of the climate crises, and despite hardware getting faster and faster, fully powering down systems and back on on demand – the obvious choice – is still inconvenient, as boot times are still very long. Even ChromeOS still has not lowered its limit from ten seconds since years. Show the current status of the hobby project on x86 hardware, and give an overview of recent Linux kernel developments getting rid some of the delays. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HZY3K8/

A short case study on where we are with sandboxing APT; what gaps there are and what technologies we looked at. Downloading packages, verifying packages, installing packages, protecting user data from snoopy or broken maintainer scripts. A package manager has a lot of places that can need some sort of sandboxing. APT currently employs a minimal sandbox using a separate user for downloading, and optionally seccomp. This talk will explore that, the caveats and some more avenues like landlock, running apt in systemd isolation (useful for our apt-based .service units), file descriptor passing into sandbox. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/8CGF9L/

Despite being ordinary computers with an ASIC for switching, in reality network hardware must still be treated differently from normal servers. In recent years a lot has improved, and vendors offer white box switches, allowing users to install a (network) operating system of their choice. Of course, the NOS needs to support the firmware interface for the particular ASIC, and this is not standardized: swtitchdev, DSA, SAI – none of them supporting all devices. Due to SONiC dominance, a lot of vendors seem to support SAI (Switch Abstraction Interface). But SAI requires a proprietary external Linux kernel module. On the NOS side, Open Network Linux was abandoned, and Azure’s SONiC is the new popular kid on the block, running a Docker daemon. There are other differences in the network hardware ecosystem: For example ONIE as the bootloader environment. Also working with upstream and using established software developing practices are lacking, resulting in a maintenance burden. Projects like DENT or OpenWrt go one step further by only supporting upstream Linux kernel interfaces, but now dentOS is also going to support SAI. This talk gives a short introduction into the network operating systems, and then focuses on DENT with the ONL fork dentOS, and shares experiences. Curiously, problems how to treat firmware blobs and discussions about what distribution to use as a base, are not unknown to these projects either. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/JVGVHG/

The TPM event log contains a history of all measurements made with the TPM. Complete with some context information for each measurement it is intended to help with recreating the current PCR contents. What was meant as a debugging tool turns out to be of vital importance when trying to remotely attest real life systems. This is mostly because of the overuse of certain PCR and the general mess that is x86 firmware. Sadly, there are many event logs. UEFI keeps one for its measurements and those done by EFI applications like GRUB and shim. If a system is booted in an MLE using tboot the ACM firmware code also maintains an event log that can be accessed via a pointer in an ACPI table. Now, systemd also has an event log that is mixed into the general journal log. Finally Linux IMA maintains it's own event log -- an append-only, in-kernel data structure. On top of that every bootloader or userspace application that wants to measure something into the TPM will also need to maintain an event log. How about we fix that? The talk will sketch out a solution that maintains a unified, global event log of the whole system on disk and exposes an interface for other applications that wish to measure things into the TPM. We'll also fix a race conditions in IMA as well as correctly handle S3 resume w.r.t measured boot while we're at it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HGMV9U/

This talk will discuss new features provided by the new kernel mount API interface about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/NYLYDK/

Let's get you up to speed on Trusted Platform Modules (TPM 2.0) and Linux. Specifically, the various additions to basic Linux userspace, i.e. systemd in our goal to make measured boot a default on Linux. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HSEJY9/

systemd v254 introduced a new reboot type: soft-reboot. It shortcuts the reboot process by not restarting the kernel, and instead shutting down userspace, followed by re-exec'ing systemd from the new rootfs, starting everything up again. Not only this allows to save time by virtue of doing less work, but it also allow select resources (File Descriptor Store) and select services that do not use the rootfs (Portable Services) to survive the reboot and continue uninterrupted. This talk will explore the details of this new feature, how it works, why it's useful, what are the shortcomings and how to make full use of it. In many environments where image-based Linux is used, service interruption intervals are key metrics that need to be minimized as much as possible. On a traditional package-based distributions, the rootfs can be updated piecemeal and userspace services can be restarted one by one - assuming a perfect running dependency tracking system and perfect reliability (need to restart D-Bus? Good luck!). On an image-based system this is obviously not possible, so a typical approach is relying on 'kexec', which loads a new kernel + initrd + rootfs, saving some time from a full reboot by avoiding giving back control to the firmware. But it turns out, it's not fast enough. systemd v254 introduced a new reboot type: soft-reboot. This follows in the kexec footsteps by shortcutting the reboot process, and brings it ever further: the kernel is not restarted at all, and instead userspace is shut down and then systemd is re-exec'ed from the new rootfs, starting up again. Not only this allows to save time by virtue of doing less work, but it also allow resources (File Descriptor Store) and select services that do not use the rootfs (Portable Services) to survive the reboot and continue uninterrupted. This talk will explore the details of this new feature, how it works, why it's useful, what are the shortcomings and how to make full use of it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/XVV9QY/

Let's discuss about `bpfilter`, a userspace daemon that empowers services to create efficient packet-filtering BPF programs using a high-level representation of filtering rules. For a significant period, `bpfilter` wasn't more than an empty [usermode helper](https://cateee.net/lkddb/web-lkddb/STATIC_USERMODEHELPER.html) and an [abandoned patch series](https://lore.kernel.org/bpf/[email protected]). However, it has recently undergone active development as a userspace daemon, which can be found on GitHub at [https://github.com/facebook/bpfilter](https://github.com/facebook/bpfilter). This daemon now offers userspace services a swift and user-friendly interface to generate packet-filtering BPF programs dynamically. This discussion aims to provide further insights into `bpfilter`, including its current capabilities, performance, and ongoing development efforts. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/BKLNWP/

Stopping the old and starting a new service afresh -- that is what service restart is roughly about. We will look what it comprises in more detail from service manager perspective and also from the service's client end. Thus we will look at how FDSTORE API can be used to smooth service restart. Furthermore, we will review how unit instances may provide further distinction between the stopped and the restarted service. Finally, we go through options that the existing service have to adopt these methods. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/FYHCNJ/

strace is a traditional userspace tracer utility for Linux, implemented using ptrace API. Despite of the abundance of various kernel tracing interfaces nowadays, there are certain classes of tasks that are still better served by strace. In this talk the maintainer of strace will provide examples of such tasks. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/GUVYJ7/

Using an image-based OS brings advantages and challenges. One challenge is the customization of a read-only image with additional host-level software and configuration, and how to manage this customization through the lifetime of a machine. For deeper changes in /usr, users might build their own images instead of following the official image updates. For common scenarios, the vendor may choose to offer multiple image flavors. Simpler user customization can live outside of the read-only /usr, scattered as config files and binaries in /etc and /opt. Configuration management tools struggle with reliable (re)configuration because tracking filesystem state is hard. The systemd project now supports a mechanism for extension images. There are two types; system extensions create an overlay for /usr or /opt and configuration extensions create an overlay for /etc. Through the overlay, users can thus change the read-only /usr without building custom OS images. Vendors can also offer their supported flavors as extensions instead of different OS images, even as composable stack where the user can choose optional parts. Users can manage their configuration by replacing the extension images atomically. Since the images bundle all files, this prevents old files lingering around or a system in a half-finished state. The read-only extension images help with setting up attestation and integrity enforcement for their contents. For distributions providing prebuilt initrds (e.g., the Fedora mkosi-initrd proposal), extensions allow initrd customization provided by the distribution or user. The presentation will give an overview, share use cases and examples, and discuss future improvements for extension images. A recent addition to the systemd toolbox was systemd-sysext for system extensions through overlay images mounted on /usr. Even newer is systemd-confext for configuration extensions through overlay images mounted on /etc. The main use case for systemd-sysext is the customization or deployment of additional software on an image-based OS where /usr is read-only. The use of single images that contain all files allows to reliably manage the changes compared to unpacking files to the root filesystem. Optional dm-verity protection ensures the integrity of the extensions. A simple version matching scheme allows to either couple the extension to the OS version or not. The first case is useful for officially released OS extensions or dynamic linking, the second for static linking and only few assumptions about the host. For systemd-confext the use case is similar as with systemd-sysext but it focuses on configuration in /etc. Here again, the use of single image files makes configuration changes more reliable. Ideally the use of configuration images should allow to have /etc read-only at runtime, following the idea of immutable infra. However, not all software and workflows are prepared for that, and the goal is to introduce different modes for the overlay to, e.g., support ephemeral or persistent changes. Other plans are to set up the overlay mount from the initrd already to have all configuration in place as early as possible, and to improve the live reload behavior through atomic mount operations and system reload actions. The presentation will show how to use systemd-sysext/confext and share some examples from Flatcar Container Linux and an embedded Linux platform for both coupled and decoupled extensions. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/XLQNDJ/

With the introduction of "Forensic Container Checkpointing" in Kubernetes 1.25 it is possible to checkpoint containers. The ability to checkpoint containers opens up many new use cases. Containers can be migrated without loosing the state of the container, fast startup from existing checkpoints, using spot instances more effective. The primary use case, based on the title of the Kubernetes enhancement proposal, is the forensic analysis of the checkpointed containers. In this session I want to introduce the different possible use cases of "Forensic Container Checkpointing" with a focus on how to perform forensic analysis on the checkpointed containers. The presented use cases and especially the forensic analysis will be done as a live demo giving the audience a hands on experience. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/FZNLRT/

In this presentation, we introduce Inspektor Gadget, a tool designed for the creation, deployment, and execution of eBPF programs (gadgets) across Kubernetes and Linux environments. Inspektor Gadget encapsulates eBPF programs into OCI containers, providing well-understood and easily distributable units. We'll delve into Inspektor Gadget's automatic data enrichment process, transforming complex kernel information into high-level, understandable concepts tied to Kubernetes, container runtimes, systemd, etc. This feature bridges the knowledge gap between raw, low-level data and more interpretable information, improving the understanding of system behavior. We will illustrate how to use a simple configuration file to set up a data collection pipeline with Inspektor Gadget, resulting in a Prometheus endpoint or an exposed API. Throughout the talk, we'll demonstrate Inspektor Gadget's features, support across various environments, discuss its operational mechanics, and share insights into the future direction of the project. By presenting at ASG!, our aim is not just to inform the audience of Inspektor Gadget, but also to encourage feedback and stimulate discussions within the eBPF and Linux community. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/ZSTFTF/

At Meta, we've been working to add encryption support to btrfs, with exciting implications for per-container security. Traditionally encryption has either dealt with whole disks, with LUKS, or with a few filesystems: ext4, f2fs, ubifs, and ceph, lacking in advanced volume management. Btrfs has several features these filesystems don't: deduplicating/reflinking identical data, subvolume/snapshot management, and integrated checksumming. These features allow giving containers their own encrypted subvolume with a key only loaded when the container is running, preventing container storage from being read while turned off, and making deletion of expired containers' storage secure. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/ZJDHRA/

UKIs are a fundamental building block of modern measured and trusted boot chains. Let's have a look at what happened in the area and discuss recently added new concepts, such as "add-ons", new PE sections, build tools and more. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/ZEVAWH/

A welcome session for All Systems Go! about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/X89KG9/

A conversation about digital EU politics in the present and future A conversation about EU digital policy now and in the future. The event will be a structured AMA (ask me anything). So we need your questions! We will structure the questions to ensure a smooth conversation. Questions we touched on in conversation: - Can you briefly explain the difference between Europe and the EU? - Do you represent the "Danish people" or the whole EU? - What is your opinion about the EU "chat control"? What can we do to stop it? What are you going to do? - What is your personal utopia for Europe? What positive changes would you like to see in the next few years? "EU digital legislation in the 2020's: The Good, the Bad and the Ugly" https://media.ccc.de/v/bornhack2022-4200-eu-digital-legislation about this event: https://c3voc.de

Closing, thank yous, sponsors, what's next, anything else about this event: https://talks.nixcon.org/nixcon-2023/talk/NRSXHT/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/RNTYJF/

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 about this event: https://talks.nixcon.org/nixcon-2023/talk/CYEPCX/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/Q3YYMR/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/Z897S3/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/DDVFVZ/

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 about this event: https://talks.nixcon.org/nixcon-2023/talk/DDQRWQ/

. about this event: https://talks.nixcon.org/nixcon-2023/talk/DHXKNW/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/8ENEKM/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/SERXWP/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/GXW3EX/

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 about this event: https://talks.nixcon.org/nixcon-2023/talk/T3FZ8A/

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 about this event: https://talks.nixcon.org/nixcon-2023/talk/BABWGG/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/CQVAZU/

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. about this event: https://talks.nixcon.org/nixcon-2023/talk/KAYMMA/