Chaos Computer Club - archive feed

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/

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

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

Opening ceremony for day 2! about this event: https://talks.nixcon.org/nixcon-2023/talk/DS3REV/

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

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

The [Impermanence](https://github.com/nix-community/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. about this event: https://talks.nixcon.org/nixcon-2023/talk/UPNSQD/

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

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](https://github.com/replit/nixmodules) 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! about this event: https://talks.nixcon.org/nixcon-2023/talk/3FSNG9/

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

A rundown of what the Nix documentation team has done since last NixCon about this event: https://talks.nixcon.org/nixcon-2023/talk/G8NDHE/

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](https://github.com/nickel-lang/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](https://github.com/tweag/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. about this event: https://talks.nixcon.org/nixcon-2023/talk/7LPHTK/

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](https://dhall-lang.org/), [PureScript](https://hackage.haskell.org/package/purenix) and [Nickel](https://nickel-lang.org/) (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](https://github.com/yvan-sraka/contracts) library. But I will be more than happy to discuss it while HackDay! about this event: https://talks.nixcon.org/nixcon-2023/talk/7WYFPW/

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

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

For [almost 20 years now](https://github.com/nixos/nixpkgs/commit/1894a8b86c4f5233f4f28af3b93156aaaee44af1#diff-e55bb1f00549f56ee8b5e3a6977467543b29e7ddb51bd6df23bea76713fc972c), 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](https://github.com/NixOS/rfcs/pull/140), originally designed by the new [Nixpkgs Architecture Team](https://nixos.org/community/teams/nixpkgs-architecture.html). 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. about this event: https://talks.nixcon.org/nixcon-2023/talk/HRWDVC/

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

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

Du hast dich entschieden einen Hackerspace zu besuchen - das ist großartig! In diesem Petit Foo gibt sirgoofy Tipps für deinen ersten Besuch im Hackerspace. Was kannst du erwarten? Was solltest du machen? Was ist vielleicht keine gute Idee? Und auch für uns langjährige Hackerspace-Besucher ist dieses Video vielleicht ein guter Anreiz darüber nachzudenken, wie der eigene erste Besuch damals war - und wie man neuen Besuchern eine gute erste Erfahrung ermöglicht. about this event: https://chaospott.de/

Es geht los about this event: https://talks.mrmcd.net/2023/talk/9GQT8A/

Große Social Media Netzwerke wie X, Instagram und TikTok sind einfach nur noch pervers und ballern einen unablässig mit Werbung, Triggern und Hass zu. Hate sells I guess. Ich hatte letztlich keine Lust mehr darauf und mit dem Fediverse und dezentralen Social Media angeboten die Erfahrung gemacht: Social Media muss gar nicht Grau, Hass und Bots - es kann auch Bunt, Liebe und Menschen. Ich plaudere aus dem Bitkästchen zu darmstadt.social, wer ich bin, wo ich herkomme und wie ich auf die ~~Dumme~~hervorragende Idee kam ein öffentliches Mastodon im fediverse zu betreiben. Ich möchte von meiner anfänglichen Motivation erzählen, dem Tief und der Enttäuschung während Covid19 und wie sich meine Motivation dadurch verändert hat. Rund um das fediverse und dessen Software hat sich eine engagierte Community aus Admins und Moderator*innen gebildet, die sich über Meetups, ActivityPub und Matrix selbst organisieren um Wissen auszutauschen und sich in Krisen beizustehen. Wie betreibt man eigentlich einen Teil des Fediverse? Mit wie viel Last und Kosten kann man rechnen? Moderation ist nicht einfach, wie geht darmstadt.social damit um? Nicht zuletzt stellen sich ab einer gewissen Größe auch rechtliche Fragen. Wie sieht es also mit darmstadt.social e.V. aus? about this event: https://talks.mrmcd.net/2023/talk/HCD88L/