Skip to content
Tech AI Wire

TryNix führt jedes Nix-Paket im Browser-Tab aus

TryNix bootet einen zu WebAssembly kompilierten Linux-Kernel und führt jede von 310.083 nixpkgs-Versionen im Tab aus. Python 3 braucht beim ersten Besuch 7,5 Sekunden.

Von Tech AI Wire Team

3 Min. Lesezeit

XLinkedIn
The TryNix page in a browser tab, with the hello package entered and an embedded terminal showing a nix-shell prompt.

Sie können jetzt jedes Paket aus der gesamten Geschichte von nixpkgs ausführen, ohne etwas zu installieren. Farid Zakaria veröffentlichte TryNix am 4. September 2026. Es bootet einen zu WebAssembly kompilierten Linux-Kernel in einem Browser-Tab und führt dann das gewünschte Paket aus.

"You can browse the complete history of nixpkgs, over 310,083 package versions, and run any of them in a Linux machine that boots in your tab", schrieb Zakaria.

Nixpkgs ist die Paketsammlung hinter Nix und NixOS. Ihre bestimmende Eigenschaft ist, dass jede je veröffentlichte Version adressierbar bleibt, und genau das macht eine solche Aussage möglich.

Wie es tatsächlich funktioniert

Die Bausteine sind alle vorhandene Technik, nur ungewöhnlich zusammengesetzt.

Ein über QEMU-WASM zu WebAssembly kompilierter Linux-Kernel liefert die Maschine. Ghostty, ein Terminal-Emulator, liefert die Oberfläche. Ein Nix-Store im Arbeitsspeicher hält die Closure des Pakets, also das Paket plus alles, wovon es abhängt.

Die Pakete selbst kommen über einfaches HTTP aus Nix-Binärcaches. Dieser Teil hat eine Bedingung, und Zakaria nennt sie klar: "The only requirement is that the cache is served with access-control-allow-origin: *."

Dieser Header ist der ganze Trick. Nix-Caches sind ohnehin öffentliche HTTP-Dateiserver. Mit freizügigen Cross-Origin-Headern kann ein Browser direkt von ihnen laden, ohne Server dazwischen.

Was der Start kostet

Kaltstarts dauern Sekunden, nicht Minuten.

PaketErster BesuchErneuter Besuch
hello4,2 s1,5 s
ripgrep4,3 s1,7 s
python37,5 s3,5 s

Der Abstand zwischen den Spalten ist der Browser-Cache bei der Arbeit. Ein zweiter Lauf desselben Pakets spart den größten Teil des Downloads.

Die Grenzen sind real

Drei Einschränkungen entscheiden, ob das zu Ihrem Einsatz passt.

Die Closure-Größe endet bei rund 1,5 GB, gegen eine harte WebAssembly-Grenze von 4 GB. Große Toolchains und alles, was eine umfangreiche Sprachlaufzeit mitzieht, passen nicht.

Es gibt eine serielle Konsole und sonst nichts, wie das Repository festhält. Keine grafischen Anwendungen, kein Fenstersystem, kein Browser im Browser.

Und alles wird zur Laufzeit von x86-64 nach WebAssembly übersetzt, was Latenz kostet. Das ist ein Ort, um ein Werkzeug auszuprobieren, nicht um es zu vermessen.

Was das für Entwickler bedeutet

Der unmittelbare Nutzen ist Reproduktion. Zakaria formuliert es als Satz, den man klauen sollte: "Works on my machine" is a URL now for reproduction. Ein Fehlerbericht mit einem Link, der genau diese Paketversion bootet, hat eine andere Qualität als einer mit einer Versionsnummer.

Wer Dokumentation oder ein Lehr-Repository pflegt, verliert damit den schlimmsten Schritt jeder Anleitung. "Installieren Sie zuerst Nix" kostet Leser. Ein Link nicht.

Prüfen Sie die Header Ihres eigenen Binärcaches, wenn das mit Ihren Paketen funktionieren soll. Der Cross-Origin-Header ist die Bedingung, und die meisten privaten Caches haben ihn nicht gesetzt. Das ist eine Zeile Änderung und eine Sicherheitsentscheidung, die bewusst fallen sollte, denn sie öffnet den Cache für jede Herkunft.

Planen Sie nichts Schweres darum herum. Zwischen der Obergrenze von 1,5 GB und dem Übersetzungsaufwand ist das eine Vorführfläche, keine Entwicklungsumgebung. Das Nix-Ökosystem hatte harte Monate. Das Nixpkgs-Kernteam löste sich auf, und eine Arbeit hinterlegte über strip eine Hintertür im NixOS-Bootstrap. Ein Projekt, das den guten Teil von Nix leichter zeigbar macht, kommt gerade recht.

Quellen

  1. Any Nix package, live in your browser - Farid Zakaria
  2. fzakaria/trynix - GitHub

Ähnliche Artikel