asciinema CLI 3.0, réécrit en Rust, apporte le live streaming et une mise à niveau du format de fichier
(blog.asciinema.org)- L’outil d’enregistrement de terminal asciinema CLI 3.0 a été entièrement réécrit en Rust, avec l’ajout d’une mise à niveau du format de fichier et du live streaming de terminal
- L’adoption de Rust permet la fourniture de binaires statiques, un démarrage rapide, et grâce à l’intégration d’AVT, facilite la concurrence et la gestion des appels système, tout en posant les bases de nouvelles fonctionnalités
- Le nouveau format asciicast v3 introduit un timing basé sur les intervalles (delta) des événements, une structuration des sous-métadonnées sous
term, un événement de fin"x", ainsi que des commentaires de ligne#, ce qui améliore l’éditabilité et l’expressivité - Le live streaming de terminal est proposé en deux modes, avec serveur local intégré et relais distant (auto-hébergé/serveur officiel), et offre une expérience de visionnage fluide grâce à un buffering adaptatif selon l’état du réseau
- La philosophie de base a été réorganisée autour du Local-first :
recexige désormais un nom de fichier et l’upload est séparé (upload <fichier>), tandis qu’une invite de choix du serveur renforce la compatibilité avec l’auto-hébergement et la prévention des fuites de données involontaires
Sortie de la 3.0 : asciinema CLI réécrit en Rust et principales améliorations
- asciinema CLI 3.0 est officiellement disponible
- Dans cette version, l’ensemble du code a été réécrit en Rust et le format des fichiers d’enregistrement a été mis à niveau
- Diverses fonctionnalités ont été ajoutées ou améliorées, notamment le live streaming de sessions terminal
Réécriture en Rust et améliorations générales
- Le CLI a été entièrement réécrit en Rust afin d’améliorer l’expérience développeur et la maintenabilité, avec une distribution sous forme de binaires statiques qui simplifie l’installation, accélère le démarrage et prépare l’extension des fonctionnalités
- Ce choix s’appuie sur l’expérience de l’auteur, pour qui les appels système et la gestion de la concurrence y sont plus simples qu’en Python ; l’intégration de asciinema virtual terminal (AVT) dans le CLI a également rendu possibles de nouvelles fonctionnalités
- Au final, cela pose les fondations pour les futures évolutions en matière de performances, de distribution et d’architecture
Format de fichier asciicast v3
- Le format de fichier asciicast v3 fait évoluer le produit en corrigeant plusieurs limites apparues avec le v2
- Les timestamps absolus du v2 sont remplacés par un timing basé sur des intervalles (delta), ce qui supprime le problème d’ajustement en cascade des timestamps suivants lors de l’insertion ou de la suppression d’événements
- L’en-tête a été réorganisé pour regrouper les métadonnées liées au terminal sous la clé
term, et le format prend en charge un événement"x"(exit) pour enregistrer l’état de fin de session - Les commentaires de ligne (
#) sont désormais autorisés dans les fichiers, pour une meilleure lisibilité et une gestion plus simple - Un extrait d’exemple est fourni pour présenter de manière intuitive la structure et la composition du flux d’événements
- Le nouveau format est déjà pris en charge par asciinema server et asciinema player
Live streaming de terminal
- Mode local : un serveur HTTP intégré fournit un flux visible sur le même réseau, dans un mode axé sur la confidentialité où les données ne sont envoyées qu’au navigateur du spectateur
- Le CLI embarque la dernière version de asciinema player pour une lecture immédiate, même s’il peut être nécessaire d’ouvrir un port dans le pare-feu
- Mode distant : asciinema server (officiel ou auto-hébergé) est utilisé comme relais pour diffuser le flux via une URL partageable
- Les deux modes peuvent être utilisés simultanément, ce qui permet d’adapter le déploiement au contexte
- Le lecteur s’appuie sur un buffering adaptatif fondé sur la mesure en temps réel de la latence réseau, afin d’équilibrer faible latence et prévention des sous-alimentations du buffer
- Le serveur prend en charge l’enregistrement automatique des flux ; à l’heure actuelle, le serveur opéré sur asciinema.org a l’enregistrement désactivé et applique une politique de limitation à un flux simultané
- En auto-hébergement, l’enregistrement est activé par défaut et il n’y a pas de limite sur le nombre de flux simultanés
Retour au Local-first
- Par le passé,
asciinema recincluait l’upload dans son parcours par défaut, avec un risque de publication inconsciente et de fuite d’informations- La version 2.4 avait introduit une invite de confirmation avant l’upload pour préparer cette transition ; en 3.0, un nom de fichier devient obligatoire, la fonction d’upload est retirée de
rec, et l’action est séparée dans une commande expliciteupload <fichier>
- La version 2.4 avait introduit une invite de confirmation avant l’upload pour préparer cette transition ; en 3.0, un nom de fichier devient obligatoire, la fonction d’upload est retirée de
- La philosophie par défaut est désormais clairement locale d’abord, afin que l’utilisateur décide délibérément de publier ou partager
- Un usage strictement local est entièrement pris en charge, avec une publication explicite uniquement si nécessaire
Renforcement de la compatibilité avec l’auto-hébergement
- Lors de la première utilisation de
upload,streamouauth, une invite de sélection de l’URL du serveur s’affiche ; la valeur par défaut proposée est asciinema.org, mais le choix de l’instance selon l’intention de l’utilisateur est mémorisé- Cela était déjà possible via le fichier de configuration ou les variables d’environnement, mais devient plus simple dans des environnements interactifs (nouvelle VM, conteneur de dev, etc.)
- Cela améliore l’usage en auto-hébergement tout en servant de garde-fou supplémentaire contre les uploads externes non souhaités
Distribution et utilisation
- Il peut falloir un certain temps avant que les dépôts de paquets des différentes distributions soient mis à jour
- En attendant, il est possible de télécharger des binaires précompilés pour GNU/Linux et macOS depuis les releases GitHub, ou de compiler depuis les sources
- Les notes de version et l’historique détaillé des changements sont disponibles dans les release notes et le CHANGELOG sur GitHub
2 commentaires
La 3.0 n’était pas déjà sortie ? J’ai fait une recherche et j’ai vu qu’il s’agissait d’un article de 2021 annonçant que le Player serait réécrit en Rust pour devenir 4 fois plus petit et 50 fois plus rapide.
Asciinema - Enregistrer et partager son terminal
Asciinema 3.0 - 4 fois plus petit, 50 fois plus rapide
Commentaire Hacker News
Asciinema est vraiment un outil formidable ; je l’utilise pour capturer toutes les démos de TerminalTextEffects, et Asciinema GIF Generator (AGG) convertit les fichiers asciicast en GIF de terminal de haute qualité, ce qui permet de publier facilement des démos dans le dépôt ou la documentation de TerminalTextEffects.
La sortie de fichiers raw ou les méthodes de type termsvg ne conviennent pas bien à TTE, car elles produisent une quantité énorme de données sur stdout.
Voir la documentation d’AGG et le dépôt TerminalTextEffects.
Je prends toujours plaisir à décorer le motd du serveur ou les messages de démarrage avec un TTE aléatoire à chaque fois que ça s’affiche.
On peut voir un exemple que j’ai fait ici.
Cet effet de prompt est vraiment magnifique ; qu’il ait une utilité ou non, j’aimerais qu’on continue simplement à en créer, c’est hypnotisant à regarder.
TTE donne l’impression que ces effets fantastiques de l’ancien gestionnaire de fenêtres Compiz, ceux qui m’ont fait utiliser Linux pour la première fois, ont été recréés dans le terminal.
Je me demande comment appliquer TTE de façon intermittente à tmux ou vim, un peu comme un économiseur d’écran : faut-il passer par des pipes, vaut-il mieux utiliser un alias, etc.
Je suis curieux de savoir comment les gens l’utilisent en général, à quoi il servait lors de sa création, et comment il est utilisé aujourd’hui.
J’espère qu’il continuera à évoluer.
t-rec est aussi un outil extrêmement utile ; il permet d’enregistrer la fenêtre voulue pour en faire une vidéo ou un gif.
Ce n’est pas exactement la même chose, mais pour partager rapidement un gif de terminal, t-rec peut parfois être plus simple.
Un fichier GIF de 15 Mo, c’est vraiment impossible à accepter.
Impossible d’y naviguer, impossible de sélectionner le texte, et il faut en plus tolérer un gaspillage de bande passante multiplié par 15.
C’est dommage de transformer un texte qui se compresse bien, se parcourt facilement et reste accessible en l’un des pires formats vidéo possibles.
Le minimum serait de fournir aussi le fichier asciinema brut ou un lien vers le visualiseur web ; on pourrait alors le charger rapidement, faire pause/rechercher et même copier-coller.
Les GIF qui tournent en boucle rapidement ne transmettent presque jamais l’intention, sauf à leur créateur.
Le site asciinema.org est actuellement victime de son propre succès avec un énorme pic de trafic ; le serveur relié au stream btop affiche 95 % d’utilisation CPU.
On peut voir ce stream ici.
Malgré cela, le serveur Elixir/Phoenix sur BEAM continue de fonctionner sans problème malgré le grand nombre de requêtes et la forte utilisation CPU — c’est toute la puissance de BEAM.
À l’heure actuelle, deux VM de 2 Go de RAM suffisent encore, mais il faudra probablement monter en charge bientôt.
À une époque où toute l’infrastructure part dans le cloud, c’est impressionnant de voir un service aussi connu tourner de façon stable sur seulement deux VM de 2 Go.
C’est moins de ressources que la RAM d’un ordinateur portable milieu de gamme actuel, et pourtant tout reste fluide.
Après avoir rapidement augmenté l’infrastructure, le service est de nouveau stable et réactif.
En ce moment, le stream btop saccade fortement et l’utilisation CPU continue de varier brutalement entre 0 % et 100 %.
Je me demande si le service n’est pas en train de crasher puis de redémarrer en boucle.
Longue vie à BEAM !
Petit conseil : il vaudrait mieux réduire la fréquence de rafraîchissement de btop ; à 100 ms, btop lui-même risque de consommer beaucoup de CPU.
Le client Asciinema a continué à changer de langage : Python → Golang → Python → Rust.
On peut aussi consulter l’historique et le billet de blog associé.
J’ai l’impression que ce genre de projet peut être implémenté dans n’importe quel langage sans grande importance, car tous offrent à peu près les mêmes performances.
Comme la base de code est petite, le fait de le porter dans un autre langage a peu d’impact fonctionnel, donc je pense qu’il n’y a pas de mal à le réécrire dans le langage qui motive le développeur.
C’est intéressant.
Je pense que la plupart des problèmes de Go devraient pouvoir être identifiés avant même d’écrire du code ; avec un minimum de recherche, des problèmes comme le packaging étaient déjà des critiques légitimes en 2016, mais ils ont été résolus ensuite avec les modules Go.
Après cela, continuer à le réécrire en ClojureScript, Elixir puis Rust donne malgré tout une impression de suivi des tendances techniques.
Ces changements de langage fréquents nuisent à la crédibilité de l’ingénierie.
J’ai beaucoup d’affection pour Asciinema et je soutiens le projet par de petites contributions et des dons.
Je recommande aussi de jeter un œil aux dons et à la manière dont Asciinema apparaît dans la résolution de problèmes sur des systèmes Linux (replay de SadServers).
Asciinema est de très loin le meilleur outil ou produit que j’aie utilisé.
Le flux d’authentification et d’upload en CLI est propre et intuitif ; même s’il faut passer par plusieurs étapes, cela ne paraît jamais pénible.
D’autres CLI ont un design similaire, mais avec Asciinema je n’ai jamais eu l’impression d’être freiné.
Félicitations pour cette réalisation vraiment remarquable.
Cela dit, j’aimerais bien qu’asciinema intègre directement une fonction d’export en SVG ou en GIF.
Cela améliorerait encore l’utilisabilité, puisqu’on pourrait l’insérer dans un fichier Markdown sans application de conversion séparée.
En tant que très grand fan d’Asciinema, je trouve ce travail vraiment excellent.
Concernant la fonctionnalité de live streaming, j’avais déjà bricolé quelque chose de similaire sur le stream de s2.dev, dont je suis cofondateur, et avec cette architecture il semble que ce soit possible même sans relais intermédiaire.
Personnellement, j’ai trouvé très sympa d’afficher btop en temps réel.
Pour l’architecture du live streaming, ce document peut être utile.
Maintenant que le streaming terminal en direct existe, ce serait amusant que quelqu’un superpose un avatar vtuber en ASCII art par-dessus le terminal.
Asciinema, qui est mon projet Elixir préféré, a maintenant aussi été réécrit en Rust.
J’aime beaucoup cette évolution.
Je me demande s’ils ont aussi ajouté une fonction de surveillance ou de masquage automatique des informations sensibles comme les secrets et les clés dans les commandes ; avec les petits LLM actuels, cela semble plus facile qu’avant.
Le CLI a été réécrit en Rust, mais le serveur reste en Elixir/Phoenix ; c’est justement une architecture bien adaptée à des fonctions comme le filtrage d’informations sensibles.
Il me semblait qu’à l’origine, ce n’était pas d’abord écrit en Python ?
Je me demande si la question sur le filtrage automatique des secrets et des clés dans les commandes était sérieuse ou si c’était une blague.
Les streamers Twitch diffusent souvent avec deux ordinateurs : l’un pour afficher le contenu du stream, l’autre pour faire tourner OBS et la capture HDMI.
Avec la nouvelle fonction de live streaming d’Asciinema, un développeur qui travaille uniquement dans le terminal pourrait sans doute diffuser directement le terminal de sa machine de dev vers une machine OBS, sans carte de capture HDMI.
Pour un tout petit nombre de streamers de programmation, Asciinema 3 pourrait représenter une véritable alternative.
Avec le streaming Asciinema, l’impact sur les performances est négligeable, donc cette configuration double machine n’est pas nécessaire.
Les setups 2 PC sont apparus à cause de la charge CPU de l’encodage x264, mais aujourd’hui l’encodage GPU (Nvidia NVENC) réduit presque entièrement ce problème.
OBS avec x264 n’est plus vraiment utile, sauf pour l’enregistrement hors ligne, par exemple pour des vidéos YouTube.
Si les streamers Twitch utilisent deux PC, c’est surtout pour éviter les conflits de ressources lorsqu’ils diffusent des jeux très gourmands en GPU.
Cela permet aussi d’éviter qu’un crash de pilote pendant une partie n’affecte le stream.
Ce genre de configuration de streaming sert surtout à répartir la charge de l’encodage vidéo ; pour un streamer de programmation qui travaille uniquement dans la console, je ne pense pas que ce soit vraiment nécessaire.