asciinema CLI 3.0, reescrito en Rust, ofrece streaming en vivo y una actualización del formato de archivo

• La herramienta de grabación de terminal asciinema CLI 3.0 fue reescrita por completo en Rust, añadiendo una actualización del formato de archivo y la función de streaming en vivo de terminal
• La adopción de Rust permite ofrecer binarios estáticos, tiempos de arranque rápidos y, con la integración de AVT, facilita el manejo de concurrencia y llamadas al sistema, además de sentar la base para implementar nuevas funciones
• El nuevo formato asciicast v3 introduce temporización basada en intervalos (delta) para los eventos, estructura los metadatos bajo term, añade el evento de salida "x" y comentarios de línea con #, mejorando la edición y la expresividad
• El streaming en vivo de terminal se ofrece en dos modos: servidor local integrado y relay remoto (self-hosted o servidor oficial), con buffering adaptativo según las condiciones de red para una experiencia de visualización fluida
• La filosofía base se reajustó a Local-first: rec ahora requiere nombre de archivo y separa la subida (upload <archivo>), mientras que el prompt para elegir servidor propio refuerza la afinidad con el self-hosting y la prevención de filtraciones accidentales de datos

---

Lanzamiento de 3.0: asciinema CLI reescrito en Rust y sus principales mejoras

• asciinema CLI 3.0 ya fue lanzado oficialmente
• En esta versión, todo el código fue reescrito en Rust al mismo tiempo que se actualizó el formato de archivo de grabación
• También se añadieron y mejoraron varias funciones, incluido el streaming en vivo de sesiones de terminal

Reescritura en Rust y mejoras generales

• El CLI fue reescrito por completo en Rust para mejorar la experiencia de desarrollo y la mantenibilidad; además, la distribución de binarios estáticos simplifica la instalación, mejora la velocidad de arranque y amplía la capacidad de extender funciones
  • Según la experiencia del autor, fue elegido porque las llamadas al sistema y el manejo de concurrencia resultan más sencillos que en Python, y la integración de asciinema virtual terminal (AVT) en el CLI hizo posible implementar nuevas funciones
• Como resultado, se estableció una base para futuras funciones en términos de rendimiento, distribución y arquitectura

Formato de archivo asciicast v3

• El formato de archivo asciicast v3 evoluciona para corregir varias limitaciones que se habían hecho evidentes en v2
• Sustituye las marcas de tiempo absolutas de v2 por temporización basada en intervalos (delta), resolviendo el problema de tener que ajustar en bloque las marcas de tiempo posteriores al insertar o eliminar eventos
• Reorganiza el encabezado para agrupar los metadatos relacionados con la terminal bajo la clave term y admite el evento de salida "x" (exit) para guardar el estado de cierre de la sesión
• Permite comentarios de línea (#) dentro del archivo, mejorando la legibilidad y la facilidad de mantenimiento
• Se ofrece un snippet de ejemplo que presenta de forma intuitiva la estructura y la composición del stream de eventos
• El nuevo formato ya es compatible con asciinema server y asciinema player

Streaming en vivo de terminal

• Modo local: ofrece un stream visible dentro de la misma red mediante un servidor HTTP integrado, en un modo de privacidad primero donde los datos solo se envían al navegador del espectador
  • El CLI incluye la versión más reciente de asciinema player para reproducción inmediata, aunque puede ser necesario abrir puertos en el firewall
• Modo remoto: usa asciinema server (oficial o self-hosted) como relay para distribuir el stream mediante una URL compartible
  • Ambos modos pueden usarse al mismo tiempo, lo que permite ajustar la distribución según la situación
• El player equilibra baja latencia y prevención de buffer underrun mediante buffering adaptativo basado en la medición en tiempo real de la latencia de red
• El servidor admite grabación automática del stream; actualmente, el servidor operado en asciinema.org tiene la grabación desactivada y aplica una política de límite de 1 stream simultáneo
  • En self-hosting, la grabación está activada por defecto y no hay límite de streams simultáneos

Regreso a Local-first

• En el pasado, asciinema rec incluía la subida como parte del flujo predeterminado, lo que implicaba riesgo de publicación involuntaria o filtración de información
  • En la versión 2.4 se introdujo un prompt de selección antes de subir como preparación para este cambio; en 3.0 ahora se requiere nombre de archivo, se eliminó la función de subida de rec y se separó en el comando explícito upload <archivo>
• La filosofía base se redefine claramente como local primero, rediseñando el flujo para que el usuario decida publicar o compartir de forma intencional
  • El uso exclusivamente local está totalmente soportado, y solo se publica explícitamente cuando hace falta

Refuerzo de la afinidad con el self-hosting

• Al usar upload, stream o auth por primera vez, se muestra un prompt para elegir la URL del servidor; el valor predeterminado es asciinema.org, pero se guarda la instancia elegida según la intención del usuario
  • Ya era posible configurarlo mediante archivo de configuración o variables de entorno, pero ahora resulta más fácil en entornos interactivos (VM nuevas, contenedores Dev, etc.)
• Esto mejora la usabilidad del self-hosting y al mismo tiempo funciona como una medida adicional de seguridad para evitar subidas externas no deseadas

Distribución y guía de uso

• Puede tomar tiempo hasta que el paquete se refleje en los repositorios de cada distribución
• Mientras tanto, se pueden descargar binarios precompilados para GNU/Linux y macOS desde los lanzamientos de GitHub, o bien compilar desde el código fuente
• Las notas de lanzamiento y el historial detallado de cambios pueden consultarse en los documentos de release notes y CHANGELOG de GitHub

[xguru]

¿No había salido ya la 3.0? Busqué y resulta que era una publicación de 2021 en la que anunciaban que, al reescribir Player en Rust, sería 4 veces más pequeño y 50 veces más rápido.

Asciinema - Graba y comparte la pantalla de tu terminal
Asciinema 3.0 - 4 veces más pequeño y 50 veces más rápido

[GN⁺]

Opiniones en Hacker News

• Asciinema es una herramienta realmente genial; yo la uso para capturar todos los demos de TerminalTextEffects. Asciinema GIF Generator (AGG) convierte archivos asciicast en GIFs de terminal de alta calidad, así que es fácil subir demos al repositorio o a la documentación de TerminalTextEffects.
  La salida en archivos raw o métodos tipo termsvg no van bien con TTE porque imprimen una cantidad enorme de datos en stdout.
  Vale la pena revisar la documentación de AGG y el repositorio de TerminalTextEffects

  • Me la paso decorando el motd del servidor o los mensajes de arranque con un TTE aleatorio cada vez, y siempre me saca una sonrisa.
    Se puede ver un ejemplo que hice aquí

  • Este efecto para el prompt es una verdadera belleza; tenga utilidad o no, ojalá sigan haciendo más porque me quedo hipnotizado viéndolo.
    TTE se siente como si aquellos efectos fantásticos del gestor de ventanas Compiz, que hace mucho me hicieron usar Linux por primera vez, hubieran sido llevados a la terminal.
    Me da curiosidad cómo aplicar TTE de forma intermitente a tmux o vim, como si fuera un salvapantallas en la terminal; no sé si habría que conectarlo por pipe, usar un alias o algo por el estilo.
    Me interesa saber cómo lo usa normalmente la gente, para qué se pensó originalmente al crearlo y cómo lo están aprovechando ahora.
    Ojalá siga evolucionando

  • t-rec también es una herramienta muy útil; puede grabar la ventana que quieras y convertirla en video o gif.
    No es exactamente lo mismo, pero si solo quieres compartir rápido un gif de terminal, a veces t-rec resulta más sencillo

  • Un archivo GIF de 15 MB es simplemente inaceptable.
    No se puede navegar, no se puede seleccionar texto, y además hay que soportar un desperdicio de ancho de banda de 15 veces.
    Da pena tomar texto, que se comprime bien, es fácil de recorrer y accesible, y pasarlo al formato de video más horrible que existe.
    Como mínimo estaría bien incluir también el archivo raw de asciinema o un enlace al visor web, porque así carga rápido y permite pausar, navegar y copiar/pegar.
    Un GIF que solo da vueltas rápidamente casi nunca transmite la intención de quien lo hizo a nadie más

• El sitio asciinema.org se volvió tan popular que ahora mismo está sufriendo una avalancha de tráfico; el servidor conectado al stream de btop está usando nada menos que 95% de CPU.
  Ese stream se puede ver aquí.
  Aun así, el servidor Elixir/Phoenix montado sobre BEAM sigue atendiendo bien pese a la gran cantidad de solicitudes y uso de CPU — ese es el poder de BEAM.
  Por ahora aguanta con solo dos VM de 2 GB de RAM, pero ya se siente que pronto habrá que escalar

  • En una época en la que toda la infraestructura se va a la nube, sorprende ver que un servicio tan conocido funcione de forma estable con solo dos VM de 2 GB.
    Eso es menos RAM de la que trae hoy una laptop de gama media, y aun así corre sin problema

  • Después de escalar la infraestructura de inmediato, volvió a estar estable y responder bien

  • Ahora mismo el stream de btop se entrecorta muchísimo y el uso de CPU sigue saltando entre 0% y 100%.
    Me pregunto si el servicio está crasheando y reiniciando una y otra vez

  • ¡Larga vida a BEAM!

  • Como tip, creo que convendría bajar el intervalo de refresco de btop; si lo tienes en 100 ms, btop termina consumiendo bastante CPU

• El cliente de Asciinema ha ido cambiando de Python → Golang → Python → Rust.
  También se pueden revisar el documento de historia y el blog relacionado

  • En un proyecto así, parece que realmente no importa mucho en qué lenguaje esté implementado, porque todos van a dar un rendimiento parecido.
    Como la base de código es pequeña, moverla a otro lenguaje casi no cambia nada funcionalmente, así que me parece válido seguir reescribiéndola en el lenguaje que más motive al desarrollador

  • Es interesante.
    Creo que la mayoría de los problemas de Go deberían poder identificarse antes siquiera de escribir código; con una investigación básica, temas como los problemas de packaging ya eran quejas válidas en 2016, aunque quedaron resueltos después con los módulos de Go.
    Después de eso, seguir reescribiéndolo en ClojureScript, Elixir y Rust da una sensación difícil de separar de ir persiguiendo tendencias tecnológicas.
    Este tipo de cambios frecuentes de lenguaje reduce la confianza en la ingeniería

• Le tengo mucho cariño a Asciinema y apoyo el proyecto con pequeñas contribuciones y donaciones.
  También recomiendo revisar la guía de donaciones y cómo se ve Asciinema al resolver problemas de sistemas Linux (replay de SadServers)

• Asciinema es, por mucho, lo mejor entre todas las herramientas y productos que he usado.
  El flujo de autenticación/subida desde el CLI es limpio e intuitivo, así que aunque haya que pasar por varios pasos, jamás se siente incómodo.
  Hay otros CLI con diseños parecidos, pero con Asciinema nunca sentí que me estorbara

• Felicidades por un logro realmente genial.
  Eso sí, me gustaría que asciinema incluyera una función integrada para guardar directamente como SVG o GIF.
  Así se podría insertar en archivos Markdown sin depender de una app de conversión aparte, y sería todavía más útil

• Como fan total de Asciinema, me parece increíble este trabajo.
  Sobre la función de live streaming, alguna vez hackeé algo parecido sobre el stream de s2.dev, donde soy cofundador, y con una arquitectura así parece que podría hacerse incluso sin un relay intermedio.
  En lo personal, me encantó ver btop en tiempo real.
  Para entender la arquitectura del live streaming, ayuda este documento

• Ahora que existe el streaming en vivo de terminal, sería divertido que alguien pusiera encima un avatar vtuber en ASCII art como overlay sobre la terminal

  • Me hace pensar en Max Headroom v0.2

• Mi proyecto favorito de Elixir, asciinema, ahora también fue reescrito en Rust.
  Me gusta muchísimo esta evolución.
  Me pregunto si también agregaron alguna función para detectar o depurar automáticamente información sensible como secretos o keys en los comandos; hoy en día, con tantos LLM ligeros, parecería más fácil que antes

  • El CLI fue reescrito en Rust, pero el servidor sigue siendo Elixir/Phoenix; esa parte encaja muy bien con funciones como el filtrado de información sensible

  • ¿No había sido creado primero en Python antes?

  • Me pregunto si la consulta sobre filtrar automáticamente secretos/keys en comandos no era una broma

• Los streamers de Twitch suelen transmitir con dos computadoras: una para mostrar la imagen del stream y otra para correr OBS y la captura por HDMI.
  Si se aprovecha la nueva función de live streaming de Asciinema, un desarrollador que trabaje solo en consola (terminal) podría transmitir directamente la pantalla de la terminal de su máquina de desarrollo a la máquina con OBS, sin necesidad de capturadora HDMI.
  Para un grupo muy pequeño de streamers de programación, Asciinema 3 podría ser una alternativa real

  • Con el streaming de Asciinema, el impacto en el rendimiento es casi nulo, así que no hace falta una configuración dual de ese tipo.
    La configuración de 2 PC nació por la carga de CPU del encoding con x264, pero hoy en día, al codificar con GPU (Nvidia NVENC), la carga casi desaparece.
    OBS con x264 ya no hace falta salvo para grabación offline, como videos para YouTube

  • Los streamers de Twitch usan 2 PC para evitar conflictos de recursos cuando transmiten juegos que consumen mucha GPU.
    Además, así previenen que un crash del driver durante el juego afecte al stream

  • La mayoría de estas configuraciones de equipo para streaming existen para repartir la carga del encoding de video, así que si eres un streamer de programación que trabaja solo en consola, no creo que realmente las necesites