Skip to content
Tech AI Wire

TryNix ejecuta cualquier paquete de Nix en una pestaña

TryNix arranca un núcleo Linux compilado a WebAssembly y ejecuta cualquiera de 310.083 versiones de nixpkgs en una pestaña. Python 3 tarda 7,5 segundos la primera vez.

Por Tech AI Wire Team

3 min de lectura

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

Ya puedes ejecutar cualquier paquete de toda la historia de nixpkgs sin instalar nada. Farid Zakaria publicó TryNix el 4 de septiembre de 2026. Arranca un núcleo Linux compilado a WebAssembly dentro de una pestaña del navegador y luego ejecuta el paquete que le pidas.

"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", escribió Zakaria.

Nixpkgs es la colección de paquetes que hay detrás de Nix y NixOS. Su propiedad definitoria es que cada versión publicada sigue siendo direccionable, y eso es lo que hace posible una afirmación así.

Cómo funciona en realidad

Las piezas son todas tecnología existente, montada de forma poco habitual.

Un núcleo Linux compilado a WebAssembly mediante QEMU-WASM aporta la máquina. Ghostty, un emulador de terminal, aporta la interfaz. Un almacén Nix en memoria guarda la clausura del paquete, es decir, el paquete y todo aquello de lo que depende.

Los paquetes llegan por HTTP simple desde cachés binarias de Nix. Esa parte tiene un requisito, y Zakaria lo dice sin rodeos: "The only requirement is that the cache is served with access-control-allow-origin: *."

Esa cabecera es todo el truco. Las cachés de Nix ya son servidores públicos de ficheros por HTTP, así que con cabeceras cross-origin permisivas un navegador puede tirar de ellas directamente, sin servidor intermedio.

Lo que cuesta arrancar

Los arranques en frío se cuentan en segundos, no en minutos.

PaquetePrimera visitaVuelta
hello4,2 s1,5 s
ripgrep4,3 s1,7 s
python37,5 s3,5 s

La distancia entre columnas es la caché del navegador haciendo su trabajo. Una segunda ejecución del mismo paquete se ahorra casi toda la descarga.

Los límites son reales

Tres restricciones deciden si esto encaja en tu uso.

El tamaño de clausura se topa alrededor de 1,5 GB, frente a un techo duro de 4 GB en WebAssembly. Las cadenas de herramientas grandes y cualquier cosa que arrastre un entorno de ejecución pesado no caben.

Hay una consola serie y nada más, como señala el repositorio. Ni aplicaciones gráficas, ni ventanas, ni un navegador dentro del navegador.

Y todo se traduce de x86-64 a WebAssembly en tiempo de ejecución, lo que añade latencia. Este es un sitio para probar una herramienta, no para medirla.

Qué significa esto para los desarrolladores

El uso inmediato es la reproducción. Zakaria lo formula como una frase que vale la pena robar: "Works on my machine" is a URL now for reproduction. Un informe de fallo con un enlace que arranca la versión exacta del paquete tiene otra calidad que uno con una cadena de versión.

Para quien mantiene documentación o un repositorio docente, esto elimina el peor paso de cualquier tutorial. "Instala Nix primero" pierde lectores. Un enlace no.

Revisa las cabeceras de tu propia caché binaria si quieres que esto funcione con tus paquetes. La cabecera cross-origin es el requisito, y la mayoría de cachés privadas no la tienen puesta. Es un cambio de una línea y una decisión de seguridad que conviene tomar a conciencia, porque abre la caché a cualquier origen.

No planifiques trabajo pesado alrededor de esto. Entre el techo de clausura de 1,5 GB y el sobrecoste de traducción, es una superficie de demostración, no un entorno de desarrollo. El ecosistema Nix lleva unos meses duros. El equipo central de Nixpkgs se disolvió y un artículo coló una puerta trasera en el arranque de NixOS mediante strip. Un proyecto que hace más fácil enseñar la parte buena de Nix llega en buen momento.

Fuentes

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

Artículos relacionados

A process listing on a Kubernetes v1.37 node, showing containerd, kubelet and kube-proxy owned by the kube user while the systemd services still run as root.
Dev Stack

Kubernetes 1.37 pasa el modo rootless a beta

Kubernetes 1.37 pasa KubeletInUserNamespace a beta. El kubelet, los runtimes de contenedores, los plugins CNI y kube-proxy ya pueden ejecutarse como usuario corriente.