tvl-depot/users/flokli/presentations/2023-09-09-nixcon-tvix/presentation.md
Florian Klink b8ef3e5263 feat(users/flokli): add NixCon 2023 presentation
This adds the materials for the talk held at NixCon 2023, Darmstadt.

It seems it's not really possible to export a PDF out of this,
at least I couldn't get reveal-md to do it properly.

The video recordings live on
https://media.ccc.de/v/nixcon-2023-35254-tvix and
https://www.youtube.com/watch?v=j67prAPYScY .

Change-Id: Id27dc8c8637ffd455981141383c54d8d1484679e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/9750
Reviewed-by: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
2023-10-16 11:49:06 +00:00

9.2 KiB

author date title theme revealOptions
Florian Klink
2023-09-09 Tvix: Status update moon
transition
fade

Tvix: Status update

Tvix Logo

2023-09-09

Florian Klink


Whoami

  • flokli
  • nixpkgs contributor since 2018, maintaining systemd, nsncd and some more stuff
  • Freelance Nix/DevOps consultant
  • I spend too much time on computers :-)

What is Tvix?

  • A new implementation of Nix
  • modular
  • written in Rust
  • developed in the TVL monorepo
  • subtree exported to github:tvlfyi/tvix

Structure

  • strong separation between Evaluator, Store and Builder
  • Defined interfaces between different components (Protobuf/gRPC)
    • Allows adding to/combining with your own components
  • A lot of helper code for some of the Nix internals in the `nix-compat` crate

Note: Derivation types, serializers. NAR writers, nixbase32 enc/dec, Nix Hash function, stringparsing etc.


crate-deps.svg


Evaluator: Design

  • Nix code is parsed via rnix
  • AST traversal, generate bytecode (with some transformations)
  • Bytecode is executed by an abstract machine with a Nix-specific instruction set

Evaluator: Design

  • Builtins are separate from the "evaluator core"
    • inject your own builtins
    • this includes builtins.derivation!
  • IO is nicely abstracted away
    • We can run a Nixlang subset without IO in wasm (see tvixbolt), or parse Nix into a config struct with tvix-serde

Tvixbolt Demo


Evaluator: Current Work

  • Current goal: evaluate nixpkgs the same way as Nix does
  • Checked by comparing the calculated output paths, which checks correctness of all "parent" output paths too.
  • Required implementing a lot of Nix internals in nix-compat, and tvix-store (A-Term, hash modulo, NAR writer/hasher)

Note: Getting output hashing correct, and exposing this in a re-usable fashion took quite some iterations to get right.


Evaluator: Current Work (cont.)

  • 🎉 Already correct for (and continously checked by CI on every commit):
    stdenv, hello
    pkgsCross.aarch64-multiplatform.stdenv, pkgsCross.aarch64-multiplatform.hello
  • Some work left for more complicated expressions
  • Not too much performance finetuning until we're correct first.

Evaluator: Demo

asciicast


Store: Design

  • Uses a very different underlying data model:
    • Nix stores on a per- StorePath granularity
    • tvix-store uses a Merkle DAG of directories, similar to git trees, but with BLAKE3 digests as pointers.
    • Compat layer in front to still render/calculate NAR on demand where needed
    • Substitution, caching, ... possible to describe via composition/layering

tvix-store graph


Store: Advantages

  • Less downloading of data that didn't change
  • Less duplicate data on disk/storage
  • Inherently content-addressed, so P2P substitution possible
  • Allows doing verified blob streaming (BAO, bao-tree)
  • Protocol has some "smarter" methods to avoid roundtrips, but could all be statically pre-rendered
  • Very little data that needs to be fetched from a trusted party (or be signed)

Note: Our way of addressing blobs by their raw blake3 digest is natively compatible with iroh, the IPFS Re-implementation in Rust


Store: Status

  • Whole Merkle-based store implementation (and Nix NAR compat layer) is there
    • exercised by the output path CI tests, and a test suite.
    • three backends (Sled, in-memory, gRPC client)
    • more backends and more test suites planned.
  • FUSE filesystem to expose the store (to Tvix Builders, "appliances")

Note: backends: RocksDB, sqlite, s3. fuse: lazy fetching of build input files | think about a minimal initrd to bring up network and mount the store, then run any closure.


Store: Demo

asciicast


Store: Status (cont.)

  • More work on store composition needed (necessary for substition and caching)
  • More work on more granular blob substititon needed.
  • More work on bridges with Nix needed
    • Get Nix to talk to a tvix-store
    • Expose existing binary caches to tvix-store

Builder: Design

  • Build requests/Build protocol is less Nix-specific
    • allows reusing builders for other usages (non-sandboxed builds, other build systems, playing with other addressing mechanisms)
  • Distinction between a specific build attempt and the general build recipe
    • allows keeping metadata about failed builds
    • stats (memory/cpu consumption)
    • comparing different produced binary outputs (r11y)

Builder: Design

  • Invididual builds can be run in your desired container/virt engine/scheduler, as long as it speaks the same Build API
  • Build API composition/proxying, similar to Store composition
  • allows "unattended building" (evaluate nixpkgs locally and send all build requests to a remote builder)
  • allows tailing logs from currently/already running builds

Builder: Status

  • Dummy Builder implementation in go-nix (using OCI)
  • Some scribble notes on the Build Protocol
  • Glue code to trigger builds from inside builtins.derivation needs to be written
  • Builder implementation (using systemd-nspwan or some container engine needs to be written.
  • Web interface to visualize store contents and build graphs/builds/logs

Contributing

  • Join the IRC channel (#tvl on hackint), bridged to Matrix and XMPP
  • Check our issue tracker
  • Try to use it and tell us how you broke it!
  • Add various Nix bits to nix-compat

Note: or if you like what you seeing and want to sponsor parts, that's also cool :-)


Thanks to...

  • all TVL contributors (some drive-by, some long-term contributors)
  • countless Nix community members for their input on the architecture and rubberducking
  • NLNET and others to sponsor parts of this

Questions?

Florian Klink / flokli.de
Tvix / tvix.dev