asciinema CLI 3.0, reescrito em Rust, traz streaming ao vivo e upgrade no formato de arquivo

• A ferramenta de gravação de terminal asciinema CLI 3.0 foi totalmente reescrita em Rust, adicionando upgrade no formato de arquivo e streaming ao vivo do terminal
• Com a adoção de Rust, passa a oferecer binários estáticos, inicialização mais rápida e, com a integração do AVT, fica mais fácil lidar com concorrência e chamadas de sistema, além de estabelecer a base para novos recursos
• O novo formato asciicast v3 introduz temporização baseada em intervalos (delta) entre eventos, estruturação dos metadados de term, evento de encerramento "x" e comentários de linha com #, aumentando a editabilidade e o poder de expressão
• O streaming ao vivo do terminal é oferecido em dois modos: servidor local embutido e relay remoto (auto-hospedado/servidor oficial), com buffer adaptativo conforme as condições de rede para uma visualização mais fluida
• A filosofia básica foi reorganizada como Local-first: rec agora exige nome de arquivo e separa o upload (upload <arquivo>), além de reforçar a afinidade com self-hosting e a prevenção contra vazamento acidental de dados por meio de um prompt para escolha do servidor próprio

---

Lançamento da versão 3.0: asciinema CLI reescrito em Rust e principais melhorias

• O asciinema CLI 3.0 foi lançado oficialmente
• Nesta versão, todo o código foi reescrito em Rust ao mesmo tempo em que o formato dos arquivos de gravação foi atualizado
• Também foram adicionados e melhorados diversos recursos, como o streaming ao vivo de sessões de terminal

Reescrita em Rust e melhorias gerais

• O CLI foi totalmente reescrito em Rust para melhorar a experiência do desenvolvedor e a manutenibilidade, com distribuição em binários estáticos, simplificação da instalação, inicialização mais rápida e base para expansão de funcionalidades
  • A escolha se baseou na experiência do autor de que chamadas de sistema e tratamento de concorrência são mais fáceis do que em Python, e a integração do asciinema virtual terminal (AVT) ao CLI permitiu implementar novos recursos
• Como resultado, foram estabelecidas as bases para futuras adições de funcionalidades em termos de desempenho, distribuição e arquitetura

Formato de arquivo asciicast v3

• O formato de arquivo evoluiu para o asciicast v3, corrigindo várias limitações reveladas no v2
• Os timestamps absolutos do v2 foram substituídos por temporização baseada em intervalos (interval/delta), eliminando o problema de ajustar em lote os timestamps subsequentes ao inserir ou remover eventos
• O cabeçalho foi reorganizado para agrupar os metadados relacionados ao terminal sob a chave term, e foi adicionado suporte ao evento de saída "x" (exit) para armazenar o estado de encerramento da sessão
• Passou a permitir comentários de linha (#) dentro do arquivo, melhorando a legibilidade e a facilidade de manutenção
• Um snippet de exemplo é fornecido para apresentar de forma intuitiva a estrutura e a composição do fluxo de eventos
• O novo formato já é suportado pelo asciinema server e pelo asciinema player

Streaming ao vivo do terminal

• Modo local: oferece um stream visível na mesma rede por meio de um servidor HTTP embutido, em um modo priorizando a privacidade no qual os dados são enviados apenas ao navegador dos espectadores
  • O CLI já vem com a versão mais recente do asciinema player embutida para reprodução imediata, embora possa ser necessário abrir portas no firewall
• Modo remoto: usa o asciinema server (oficial ou auto-hospedado) como relay para distribuir o stream por meio de uma URL compartilhável
  • Os dois modos podem ser usados ao mesmo tempo, permitindo uma configuração de distribuição adequada a cada situação
• O player equilibra baixa latência e prevenção de buffer underrun com buffer adaptativo baseado em medição em tempo real da latência da rede
• O servidor oferece suporte a gravação automática do stream; no momento, o servidor operado em asciinema.org está com a gravação desativada e aplica a política de limite de 1 stream simultâneo
  • Em self-hosting, a gravação é ativada por padrão e não há limite de streams simultâneos

Retorno ao Local-first

• No passado, asciinema rec incluía a ação de upload no fluxo padrão, o que trazia risco de publicação involuntária e vazamento de informações
  • Na versão 2.4, foi introduzido um prompt de escolha antes do upload como preparação para a mudança; no 3.0, passou a haver nome de arquivo obrigatório, remoção da função de upload de rec e separação em um comando explícito, upload <arquivo>
• A filosofia central foi redefinida de forma clara como local-first, redesenhando o fluxo para que o usuário decida conscientemente quando publicar ou compartilhar
  • O uso exclusivamente local é totalmente suportado, e a publicação só acontece quando for explicitamente desejada

Reforço da afinidade com self-hosting

• Ao usar upload/stream/auth pela primeira vez, é exibido um prompt para escolher a URL do servidor; o padrão sugerido é asciinema.org, mas a instância escolhida conforme a intenção do usuário é salva
  • Isso já podia ser definido por arquivo de configuração ou variável de ambiente, mas agora a configuração ficou mais fácil em ambientes interativos (nova VM, Dev container etc.)
• Isso melhora a usabilidade para self-hosting e também funciona como uma camada extra de segurança para evitar uploads externos indesejados

Distribuição e orientações de uso

• Pode levar algum tempo até que a atualização chegue aos repositórios de pacotes de cada distribuição
• Enquanto isso, é possível baixar binários pré-compilados para GNU/Linux e macOS nas releases do GitHub ou compilar a partir do código-fonte
• As notas da versão e o histórico detalhado de mudanças podem ser consultados nos documentos release notes e CHANGELOG no GitHub

[xguru]

O 3.0 já não tinha saído antes? Fui pesquisar e vi que era um post de 2021, quando anunciaram que reescreveriam o Player em Rust para ficar 4 vezes menor e 50 vezes mais rápido.

Asciinema - Grave e compartilhe sua tela de terminal
Asciinema 3.0 - 4 vezes menor, 50 vezes mais rápido

[GN⁺]

Comentários no Hacker News

• Asciinema é uma ferramenta realmente incrível; eu a uso para capturar todos os demos do TerminalTextEffects, e o Asciinema GIF Generator (AGG) converte arquivos asciicast em GIFs de terminal de alta qualidade, então fica fácil colocar demos no repositório ou na documentação do TerminalTextEffects
  Saída de arquivo raw ou métodos do tipo termsvg não combinam com o TTE, porque despejam uma quantidade enorme de dados no stdout
  Vale a pena conferir a documentação do AGG e o repositório do TerminalTextEffects

  • Tenho me divertido decorando o motd do servidor ou mensagens de inicialização com TTEs aleatórios toda vez que aparecem
    Um exemplo que fiz pode ser visto aqui

  • Esse efeito no prompt é realmente lindo; tenha utilidade ou não, eu queria que continuassem fazendo mais, fico hipnotizado vendo
    O TTE passa a sensação de aqueles efeitos fantásticos do gerenciador de janelas Compiz que me fizeram usar Linux pela primeira vez, só que implementados no terminal
    Tenho curiosidade sobre como aplicar o TTE de forma intermitente no tmux ou no vim, como um protetor de tela; fico pensando se teria que encadear com pipe, se seria melhor usar alias etc.
    Queria saber como as pessoas costumam usar, para que ele foi criado originalmente e como está sendo usado hoje
    Espero que continue evoluindo

  • t-rec também é uma ferramenta muito útil; ela pode gravar a janela que você quiser e gerar vídeo ou gif
    Não é exatamente a mesma coisa, mas se a ideia é só compartilhar rapidamente um gif de terminal, às vezes o t-rec é mais fácil

  • Um arquivo GIF de 15 MB é simplesmente impossível de engolir
    Não dá para navegar, não dá para selecionar texto, e ainda se desperdiça 15 vezes mais largura de banda
    É uma pena pegar um texto que pode ser compactado de forma suave, é fácil de navegar e é acessível, e transformá-lo no pior formato possível de vídeo
    No mínimo, seria bom incluir também o arquivo asciinema raw ou um link para o visualizador web, porque aí dá para carregar rápido, pausar/navegar/copiar e colar
    GIFs que só ficam em loop rapidamente quase não transmitem a intenção para ninguém além de quem os criou

• O site asciinema.org está tão popular que no momento passa por uma explosão de tráfego; a CPU do servidor com o stream do btop está em impressionantes 95% de uso
  Um exemplo desse stream pode ser visto aqui
  Mesmo assim, o servidor em Elixir/Phoenix rodando sobre a BEAM continua atendendo bem apesar de muitas requisições e alto uso de CPU — esse é o poder da BEAM
  Neste momento, ainda está aguentando com apenas duas VMs de 2 GB de RAM, mas em breve deve precisar escalar

  • Em uma época em que toda a infraestrutura vai para a nuvem, é surpreendente ver um serviço tão conhecido rodando de forma estável em apenas duas VMs de 2 GB
    Isso é menos memória do que muitos notebooks intermediários de hoje têm, e mesmo assim está liso

  • Depois de escalar a infraestrutura imediatamente, voltou a ficar estável e responsivo

  • No momento, o stream do btop está engasgando bastante e o uso de CPU fica saltando o tempo todo entre 0% e 100%
    Fico me perguntando se o serviço está travando e reiniciando sem parar

  • Vida longa à BEAM!

  • Uma dica: talvez fosse bom reduzir a taxa de atualização do btop; rodando a 100 ms, o btop acaba consumindo bastante CPU

• O cliente do Asciinema continua mudando de Python → Golang → Python → Rust
  Também dá para consultar o documento sobre a evolução e o post relacionado no blog

  • Parece o tipo de projeto em que não faz muita diferença em que linguagem é implementado, porque todas acabam entregando desempenho parecido
    Como a base de código é pequena, migrar para outra linguagem quase não afeta a funcionalidade, então acho tranquilo continuar reescrevendo na linguagem que mantém o desenvolvedor motivado

  • Interessante
    Acho que a maior parte dos problemas de Go deveria ser identificável antes mesmo de escrever código; só com uma investigação simples, questões como packaging já eram reclamações legítimas em 2016, mas foram resolvidas depois com Go modules
    Depois disso, continuar reescrevendo em ClojureScript, Elixir e Rust dá uma sensação inevitável de estar correndo atrás de tendência tecnológica
    Essas trocas frequentes de linguagem reduzem a confiança na engenharia

• Tenho carinho pelo Asciinema e apoio o projeto com pequenas contribuições e doações
  Recomendo dar uma olhada nas informações sobre doação e também em como o Asciinema aparece na resolução de problemas de sistemas Linux (replay do SadServers)

• Asciinema é disparado a melhor ferramenta/produto que já usei
  O fluxo de autenticação/upload via CLI é limpo e intuitivo, então mesmo passando por várias etapas nunca parece inconveniente
  Outras CLIs têm designs parecidos, mas o Asciinema nunca me passou sensação de atrito

• Parabéns, é um resultado realmente incrível
  Só queria que o asciinema tivesse embutido um recurso para salvar direto em SVG ou GIF
  Isso melhoraria ainda mais a usabilidade, porque daria para inserir em arquivos Markdown sem precisar de um app separado de conversão

• Como grande fã do Asciinema, acho esse trabalho realmente excelente
  Sobre o recurso de live streaming, eu já cheguei a hackear algo parecido por cima do stream da s2.dev, da qual sou cofundador, e nessa estrutura parece que isso pode funcionar até sem relay intermediário
  Pessoalmente, achei muito legal mostrar o btop em tempo real
  Para referência sobre a arquitetura de live streaming, este documento ajuda bastante

• Agora que existe streaming em tempo real do terminal, seria divertido se alguém colocasse por cima um avatar vtuber em ASCII art como overlay no terminal

  • Isso lembra Max Headroom v0.2

• O asciinema, meu projeto favorito em elixir, agora também foi reescrito em Rust
  Gostei muito dessa evolução
  Fico curioso se também foi adicionada alguma função para detectar/mascarar automaticamente informações sensíveis como segredos e chaves em comandos; hoje em dia, com LLMs leves, isso parece mais fácil do que antes

  • A CLI foi reescrita em Rust, mas o servidor continua em Elixir/Phoenix; essa parte parece uma estrutura perfeita para recursos como filtragem de informações sensíveis

  • Fiquei me perguntando se antes não tinha sido feito primeiro em Python

  • Fico na dúvida se essa pergunta sobre filtragem automática de segredos/chaves em comandos não era uma piada

• Streamers da Twitch normalmente usam dois computadores: um para mostrar a tela da transmissão e outro para rodar OBS e captura HDMI
  Com o novo recurso de live streaming do Asciinema, para desenvolvedores que trabalham só no console (terminal), parece que daria para transmitir a tela do terminal da máquina de desenvolvimento direto para a máquina com OBS sem usar capturadora HDMI
  Para um grupo bem pequeno de streamers de programação, o Asciinema 3 pode virar uma alternativa de verdade

  • Com streaming via Asciinema, o impacto em desempenho é quase nulo, então essa configuração com dois equipamentos não seria necessária
    O setup com 2 PCs surgiu por causa da carga de CPU da codificação x264, mas hoje, com codificação por GPU (Nvidia NVENC), o peso praticamente desapareceu
    OBS com x264 quase não é mais necessário, a não ser para gravação offline, como vídeos para YouTube

  • Streamers da Twitch usam 2 PCs para evitar disputa de recursos quando transmitem jogos que consomem muita GPU
    Além disso, isso evita que um crash de driver durante o jogo afete a transmissão

  • A maior parte dessas configurações de equipamento para streaming serve para distribuir a carga da codificação de vídeo, então, para um streamer de programação que trabalha só no console, realmente não parece necessário