
Hosted by CCC media team · EN

It's been a while since I last talked about Zilch; and now with Lix's existence, it's time to take another look; what's the status of this mysterious project, and what lessons can we learn from it? Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/QFSZRU/

Nix does dependencies and distribution well, but has a controlling personality: it wants to build everything in the build graph. Buck2 delivers fast, user-friendly, and scalable project builds, but has an equally controlling personality and a lacking public dependency ecosystem. What if their build graphs touched ... and they were both girls? In this talk, I will demonstrate how we go from Nix to buck2 to Nix then deploy with containers: * Using Nix for dependencies in buck2 * Using buck2 in the project build: remote caching, fast builds, ~zero evaluation time * Importing store paths to Lix from buck2 output while correctly handling dependencies * Extending these techniques to build Docker images defined entirely in buck2, using nixpkgs `dockerTools` This talk focuses on buck2, but the techniques used apply to any powerful non-Nix build system. Hermetic build systems are hard to interoperate with, but there are cheat codes: by resolving their trust issues, you can combine their respective benefits. For the last year, my team and I have been working on a Buck2 migration for one of the largest Haskell codebases in industry to reduce build times from dozens of minutes to seconds and improve user experience. We use Nix to orchestrate hundreds of Haskell dependencies and hundreds more dependencies across the Rust, TypeScript, Python and C ecosystems. On top of that, we are running a much newer Haskell compiler than most of the industry due to active involvement in GHC development, which means a *heavily* patched nixpkgs Haskell dependency set to be able to incorporate these improvements. By building a Nix-Buck2-Nix sandwich, we were able to focus on rewriting our product build in buck2 while keeping both our Nix-based dependencies and our deployment pipelines to both NixOS and AWS ECS completely as-is. The novel contributions of this talk are: * Creating full-featured store paths *entirely* outside of Nix with Snowydeer: * Reference scanning outside of Nix using ripgrep * Using a new Lix CLI feature: output-addressed paths with references * Referencing those store paths from Nix language for further processing * Using Nix as a build step rather than a build driver to create an ergonomic Docker image builder with Snowydeer Container This talk builds on previous work, such as: - ["Integrating Nix and Buck2 for fun and profit"](https://www.youtube.com/watch?v=pDkFk7iggIE) by Claudio Bley - ["Haskell Builds at Scale: Comparing Bazel and Buck2"](https://www.youtube.com/watch?v=eA-3Gfr4epU) by Andreas Herrmann - ["Towards Dream Haskell Build Experience"](https://www.youtube.com/watch?v=WrdXUYFnRv4) by Ian-Woo Kim Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/Z3CRCM/

Taking a look at the `functional` test suite, pointing out its concepts and flaws to then take a look at its successor `functional2` Many curses and screams of frustration has the functional test suite brought forth in many - if not all - lix developers. Hence people wanted a successor. In this session, we will talk about all the pain, impurities and falkeyness of the functional suite, look at the features and non-features of functional2, and the pain of migrating tests. Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/KBFUXL/

The Nix expression language is challenging to evaluate due to non-strict semantics, dynamic scoping, a diverse collection of builtin operators, and tight integration with the Nix store. We give a progress report on Regiux, an interpreter for Nix which is narrowly focused on efficient evaluation of expressions. Regiux is yet another attempt at a fast Nix evaluator. Come learn about the ingredients that go into modern compilers and interpreters, particularly: * Lexing and parsing * Desugaring and expanding * Intermediate languages for lambda calculus * Using the RPython JIT toolkit * Bytecode for lazy graph evaluation Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/F83VYV/

This talk is about Elpe, a mixture of ideas from Nix, Docker and Ubuntu/Debian/RHEL, with a strong focus on performance and security. I'll talk about the design choices I've made, and demo the thing and about how choices that may seem purely technical can have extreme political consequences. I'll also explain how such choices can have deep and lasting consequences on the dynamics of growing organisations. Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/HVZTB9/

Lix plugins — a feature so esoteric none yet remember their existence. What power could they hold? What secrets could they unlock? Let's discover together! Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/PEDV9S/

Botanix is a new CI software that targets a native nix integration as it builds derivations as its pipeline. It integrates natively with both Gerrit and Forgejo currently but its genericity allows for even more diversity in the future! This talk will present the genesis of the Botanix project, worked on by students from ENS de Lyon, its philosophy and inner workings. Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/YZZKYT/

Welcome to LixCon! Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://pretalx.dgnum.eu/lixcon-2026/talk/38JNUB/

None Viele kennen es: Ein kleines Problem, ein "man müsste mal", und schon liegt ein kleines Stück Software irgendwo rum. Und natürlich wollen wir die Welt ein bisschen verbessern: Schnell ein Repo, ein Package und vielleicht ein wenig Dokumentation gebaut. Welche Möglichkeiten gibt es, dies dezentral zu lösen, ohne von einem Konzern abhängig zu sein? Wie kann das auch in Zukunft noch funktionieren? Und was passiert eigentlich, nachdem das kleine Stückchen Weltverbesserung in die Freiheit entlassen wurde? Dependencies wollen gepflegt, PRs bearbeitet & neue Versionen releast werden. Du hast deine Pipeline verbessert? Es wäre doch super, wenn alle deine Repos das mitbekommen! **In diesem Vortrag geht es darum, was mit forgejo, forgejo actions, renovate, copier & co. alles geht, und wie auch du mit wenig Aufwand dein Leben einfacher machen und die Welt ein klein wenig verbessern kannst!** Ganz im Sinne meines [GPN23-Vortrages "Baut bessere Infrastruktur - und redet darüber!"](https://media.ccc.de/v/gpn23-303-baut-bessere-infrastruktur-und-redet-darber-): Baut bessere Software - und redet darüber! Zunächst schauen wir uns die technischen und organisatorischen Grundlagen an: Was brauche ich, um CI-Pipelines zu verstehen und mit forgejo zu nutzen? Welche Aktivitäten sind wichtig? Wo kann ich mir manuelle Arbeit sparen? Wie kann Pflege und Contribution in kleinen Projekte funktionieren? Um all dies gut umzusetzen, hat sich für mich eine Sammlung von Tools ergeben, die miteinander Arbeiten, um meine FOSS-Skripte gut und sicher zu publishen. Das ganze natürlich (möglichst) dezentral, souverän und Self-/Community-Hosted. Die gemachten Erfahrungen möchte ich gerne mit euch Teilen, und euch zum Nachbauen und weiter entwickeln motivieren: Renovate kümmert sich nicht nur um aktuelle externe, sondern auch interne Dependencies. Copier sorgt dafür, dass ich sämtliche unterstützende Bausteine wie CI-Pipeline-Definitionen, Config Files etc. einfach wiederverwenden kann. Und um das ganze Laufen zu lassen, benötige ich den ein oder anderen Container: Wie baue ich diese eigentlich sicher, aktuell und dezentral? Zum Schluss kommt natürlich auch die wichtige Frage: Was fehlt noch, was kann man besser machen & welche Probleme gibt es? Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://pretalx.linuxtage.at/glt26/talk/XLUPFE/

None **So you're familiar with secure coding practices, and you've taken steps to secure your devices and protect your personal privacy. But what about the privacy leaks in your code?** ___ In this talk, we'll take a whirlwind tour of privacy issues at the code level: where they happen, how to prevent them, and how to privacy threat model to understand which privacy protections your users need from you. You'll learn how to protect privacy in your APIs and web applications, along with how to keep your systems both private *and* observable when using observability frameworks such as OpenTelemetry. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://pretalx.linuxtage.at/glt26/talk/9JUXWQ/