asciinema CLI 3.0 được viết lại bằng Rust, bổ sung live streaming và nâng cấp định dạng tệp

 (blog.asciinema.org)
11 điểm bởi GN⁺ 2025-09-17 | 2 bình luận | Chia sẻ qua WhatsApp
  • Công cụ ghi terminal asciinema CLI 3.0 đã được viết lại hoàn toàn bằng Rust, đồng thời bổ sung nâng cấp định dạng tệp và tính năng live streaming terminal
  • Việc chọn Rust giúp cung cấp binary tĩnh, thời gian khởi động nhanh, tích hợp AVT để xử lý đồng thời và system call dễ hơn, đồng thời tạo nền tảng cho việc triển khai các tính năng mới
  • Định dạng mới asciicast v3 đưa vào cơ chế thời gian dựa trên khoảng cách giữa các sự kiện (interval/delta), cấu trúc hóa metadata con trong term, sự kiện kết thúc "x", và chú thích dòng # để tăng khả năng chỉnh sửa và biểu đạt
  • Live terminal streaming được cung cấp ở hai chế độ: server nhúng cục bộ và relay từ xa (tự host/server chính thức), cùng với adaptive buffering theo điều kiện mạng để mang lại trải nghiệm xem mượt mà
  • Triết lý cốt lõi được điều chỉnh lại theo hướng Local-first: rec yêu cầu tên tệp bắt buộc và tách riêng việc upload (upload <tệp>), đồng thời thêm prompt chọn server riêng để thân thiện hơn với self-hosting và tăng cường ngăn rò rỉ dữ liệu ngoài ý muốn

Phát hành 3.0: asciinema CLI được viết lại bằng Rust và các cải tiến chính

  • asciinema CLI 3.0 đã chính thức được phát hành
  • Ở phiên bản này, toàn bộ mã nguồn đã được viết lại bằng Rust đồng thời định dạng tệp ghi hình cũng được nâng cấp
  • Nhiều tính năng đã được bổ sung/cải tiến, bao gồm live streaming phiên terminal

Viết lại bằng Rust và cải tiến tổng thể

  • CLI được viết lại hoàn toàn bằng Rust để nâng cao trải nghiệm cho developer và khả năng bảo trì, đồng thời việc phân phối binary tĩnh giúp đơn giản hóa đường cài đặt, cải thiện tốc độ khởi động và mở rộng khả năng phát triển tính năng
    • Theo kinh nghiệm của tác giả, Rust được chọn vì việc xử lý system call và đồng thời dễ hơn so với Python, đồng thời việc tích hợp asciinema virtual terminal (AVT) vào CLI đã mở ra khả năng hiện thực các tính năng mới
  • Kết quả là về mặt hiệu năng, phân phối và kiến trúc, dự án đã xây dựng được nền tảng cho các tính năng bổ sung trong tương lai

Định dạng tệp asciicast v3

  • Định dạng tệp asciicast v3 là bước tiến hóa tiếp theo, khắc phục nhiều nhược điểm từng bộc lộ ở v2
  • Cơ chế timestamp tuyệt đối của v2 được thay bằng thời gian dựa trên khoảng cách (interval/delta), giúp giải quyết vấn đề phải điều chỉnh hàng loạt các timestamp phía sau khi chèn hoặc xóa sự kiện
  • Header được tái cấu trúc để gom metadata liên quan đến terminal vào dưới khóa term, đồng thời hỗ trợ sự kiện "x" (exit) để lưu trạng thái kết thúc phiên
  • Cho phép chú thích dòng (#) trong tệp để cải thiện tính dễ đọc và khả năng quản lý
  • Bài viết cũng cung cấp snippet ví dụ để trình bày trực quan cấu trúc và cách tổ chức event stream
  • Định dạng mới đã được hỗ trợ trong asciinema server và asciinema player

Live terminal streaming

  • Chế độ cục bộ: cung cấp stream có thể xem trong cùng mạng thông qua HTTP server nhúng, là chế độ ưu tiên quyền riêng tư khi dữ liệu chỉ được truyền tới trình duyệt của người xem
    • CLI được đóng gói sẵn asciinema player mới nhất để có thể phát ngay, dù có thể cần mở cổng trên firewall
  • Chế độ từ xa: sử dụng asciinema server (chính thức hoặc tự host) làm relay để phân phối stream qua URL có thể chia sẻ
    • Có thể sử dụng đồng thời cả hai chế độ để cấu hình phân phối phù hợp với từng tình huống
  • Player sử dụng adaptive buffering dựa trên đo độ trễ mạng theo thời gian thực để cân bằng giữa độ trễ thấp và việc tránh buffer underrun
  • Server hỗ trợ tự động ghi lại stream, nhưng server vận hành tại asciinema.org hiện đang tắt ghi hình và áp dụng chính sách chỉ 1 stream đồng thời
    • Khi self-hosting, mặc định việc ghi hình được bật và không có giới hạn số stream đồng thời

Quay lại với Local-first

  • Trước đây, asciinema rec có hành vi upload nằm trong luồng mặc định, tạo ra rủi ro công khai ngoài ý muốn và rò rỉ thông tin
    • Ở bản 2.4, một prompt lựa chọn trước khi upload đã được thêm vào để chuẩn bị cho thay đổi này; đến 3.0, hệ thống được tách hẳn bằng cách bắt buộc tên tệp, loại bỏ chức năng upload khỏi rec và dùng lệnh upload <tệp> một cách tường minh
  • Triết lý mặc định được xác định rõ là ưu tiên local, thiết kế lại luồng để người dùng chỉ công khai/chia sẻ khi có chủ đích
    • Cách dùng chỉ-local được hỗ trợ đầy đủ, và chỉ publish một cách tường minh khi cần

Tăng cường thân thiện với self-hosting

  • Khi lần đầu dùng upload/stream/auth, hệ thống sẽ hiển thị prompt chọn URL server, đưa ra mặc định là asciinema.org nhưng lưu lại lựa chọn instance theo đúng ý định người dùng
    • Trước đây việc chỉ định cũng đã có thể thực hiện qua file cấu hình hoặc biến môi trường, nhưng nay có thể thao tác dễ dàng hơn trong môi trường tương tác (VM mới, Dev container, v.v.)
  • Điều này vừa nâng cao khả năng sử dụng self-hosting, vừa đóng vai trò như một lớp bảo vệ bổ sung để ngăn upload ra bên ngoài ngoài ý muốn

Phân phối và hướng dẫn sử dụng

  • Việc cập nhật vào repository gói của từng bản phân phối có thể sẽ cần thêm thời gian
  • Trong thời gian đó, có thể tải binary dựng sẵn cho GNU/Linux và macOS từ GitHub Releases, hoặc build từ source
  • Release note và lịch sử thay đổi chi tiết có thể xem trong tài liệu release notes và CHANGELOG trên GitHub

Bài viết liên quan

2 bình luận

 
xguru 2025-09-17

Tôi tưởng 3.0 đã ra từ trước rồi chứ? Nên tìm thử thì hóa ra đó là bài viết năm 2021, khi họ thông báo sẽ viết lại Player bằng Rust để làm nó nhỏ hơn 4 lần và nhanh hơn 50 lần.

Asciinema - Ghi lại và chia sẻ màn hình terminal
Asciinema 3.0 - Nhỏ hơn 4 lần, nhanh hơn 50 lần
 
GN⁺ 2025-09-17
Ý kiến Hacker News

  • Asciinema thực sự là một công cụ rất tuyệt, tôi dùng nó để ghi lại toàn bộ demo của TerminalTextEffects, Asciinema GIF Generator (AGG) sẽ chuyển file asciicast thành GIF terminal chất lượng cao, nên có thể dễ dàng đưa demo lên kho lưu trữ hoặc tài liệu của TerminalTextEffects
    Cách xuất file raw hoặc kiểu như termsvg không phù hợp với TTE vì nó đẩy ra stdout một lượng dữ liệu khổng lồ
    Có thể tham khảo tài liệu AGG và liên kết đến kho lưu trữ TerminalTextEffects

    • Tôi đang rất thích việc trang trí motd của server hoặc thông báo khởi động bằng TTE ngẫu nhiên mỗi lần hiển thị
      Ví dụ tôi làm có thể xem ở đây

    • Hiệu ứng prompt này thực sự rất đẹp, có dùng vào việc gì hay không thì tôi vẫn muốn nó tiếp tục được tạo ra, cứ ngồi nhìn thôi cũng mê rồi
      TTE cho cảm giác như những hiệu ứng tuyệt vời trên Compiz window manager, thứ từng khiến tôi bắt đầu dùng Linux từ rất lâu trước đây, nay được tái hiện trong terminal
      Tôi tò mò không biết có cách nào áp dụng TTE vào tmux hay vim theo kiểu screensaver thỉnh thoảng xuất hiện không, ví dụ phải nối qua pipe hay dùng alias thì tốt hơn
      Tôi muốn biết mọi người thường dùng nó thế nào, ban đầu nó được tạo ra để làm gì và hiện giờ đang được ứng dụng ra sao
      Hy vọng dự án sẽ tiếp tục phát triển

    • t-rec cũng là một công cụ cực kỳ hữu ích, có thể ghi lại cửa sổ mong muốn rồi tạo thành video hoặc gif
      Không hoàn toàn giống nhau, nhưng nếu chỉ cần chia sẻ nhanh terminal gif thì có lúc t-rec dễ hơn

    • File GIF 15MB thì thật sự không thể chấp nhận nổi
      Không tua được, không chọn được văn bản, lại còn lãng phí băng thông gấp 15 lần
      Thật đáng tiếc khi chuyển văn bản vốn nén mượt, dễ tua và có tính truy cập cao sang dạng video tệ hại nhất
      Ít nhất cũng nên kèm file asciinema raw hoặc liên kết tới web viewer, như vậy sẽ tải rất nhanh, lại có thể dừng/tua/copy-paste đầy đủ
      Những GIF chỉ lặp đi lặp lại nhanh chóng hầu như không truyền tải được ý đồ gì ngoài với chính người tạo ra nó

  • Trang asciinema.org hiện đang quá nổi tiếng nên bị quá tải lưu lượng, CPU của server đang gắn stream btop lên tới tận 95%
    Có thể xem ví dụ stream đó ở đây
    Dù vậy, server Elixir/Phoenix chạy trên BEAM vẫn phục vụ ổn thỏa ngay cả khi có rất nhiều request và mức sử dụng CPU cao — đó chính là sức mạnh của BEAM
    Hiện tại mới chỉ chịu tải bằng 2 VM RAM 2GB, nhưng có cảm giác sắp phải mở rộng rồi

    • Trong thời đại mọi hạ tầng đều dồn lên cloud, thật đáng kinh ngạc khi một dịch vụ nổi tiếng như vậy vẫn chạy ổn định chỉ với hai VM 2GB
      Lượng tài nguyên đó còn ít hơn cả RAM trên một chiếc laptop tầm trung ngày nay

    • Sau khi mở rộng hạ tầng ngay lập tức, hệ thống đã ổn định trở lại và phản hồi cũng tốt hơn

    • Hiện tại stream btop đang giật rất nặng và mức dùng CPU cứ dao động liên tục từ 0% đến 100%
      Không biết có phải dịch vụ đang liên tục crash rồi khởi động lại không

    • BEAM muôn năm!

    • Mẹo nhỏ là nên giảm tần suất refresh của btop, nếu để 100ms thì chính btop sẽ ngốn khá nhiều CPU

  • Client Asciinema liên tục thay đổi từ Python → Golang → Python → Rust
    Cũng có thể tham khảo tài liệu lịch sử và bài blog liên quan

    • Với kiểu dự án này thì có lẽ viết bằng ngôn ngữ nào cũng không quá quan trọng, vì ngôn ngữ nào cũng cho hiệu năng tương tự
      Do codebase nhỏ nên chuyển sang ngôn ngữ nào cũng ít ảnh hưởng về mặt chức năng, vì vậy tôi nghĩ cứ rewrite bằng ngôn ngữ nào khiến lập trình viên có động lực là được

    • Cũng khá thú vị
      Tôi nghĩ phần lớn vấn đề của Go lẽ ra phải nhận ra trước khi bắt tay viết code, chỉ cần nghiên cứu sơ bộ cũng thấy các vấn đề kiểu packaging từng là phàn nàn chính đáng vào năm 2016, nhưng đã được giải quyết sau Go modules
      Sau đó lại tiếp tục rewrite sang ClojureScript, Elixir rồi Rust thì khó tránh khỏi cảm giác đang chạy theo xu hướng công nghệ
      Việc đổi ngôn ngữ thường xuyên như vậy làm giảm độ tin cậy về mặt kỹ thuật

  • Tôi rất quý Asciinema và đã ủng hộ dự án bằng những đóng góp nhỏ cùng tiền quyên góp
    Khuyên mọi người xem qua hướng dẫn quyên góp và thử xem Asciinema trông như thế nào khi xử lý sự cố hệ thống Linux (bản phát lại của SadServers)

  • Asciinema là công cụ/sản phẩm tốt nhất mà tôi từng dùng
    Trải nghiệm xác thực/tải lên qua CLI rất gọn gàng và trực quan, nên dù phải qua nhiều bước vẫn không hề thấy phiền
    Một số CLI khác cũng có thiết kế tương tự, nhưng với Asciinema thì tôi chưa từng cảm thấy bị cản trở

  • Chúc mừng một thành quả thật tuyệt vời
    Tuy vậy, tôi vẫn mong asciinema có sẵn tính năng lưu trực tiếp ra SVG hoặc GIF
    Như vậy có thể chèn vào file markdown mà không cần app chuyển đổi riêng, giúp trải nghiệm dùng thuận tiện hơn nhiều

  • Là một fan cuồng của Asciinema, tôi thấy lần làm này thật sự rất hay
    Về tính năng live streaming, tôi từng hack một thứ tương tự trên stream của s2.dev nơi tôi là đồng sáng lập, và với kiến trúc này có vẻ còn làm được mà không cần relay trung gian
    Cá nhân tôi thấy việc hiển thị btop theo thời gian thực rất ngầu
    Có thể tham khảo tài liệu này để hiểu kiến trúc live streaming

  • Giờ đã có tính năng stream terminal theo thời gian thực, sẽ rất vui nếu ai đó chồng thêm một avatar vtuber ASCII art lên trên terminal như một lớp overlay

    • Ý tưởng này làm tôi nhớ đến Max Headroom v0.2

  • Asciinema, dự án elixir tôi thích nhất, giờ lại được rewrite thêm bằng Rust
    Tôi rất thích bước tiến này
    Không biết họ có bổ sung tính năng tự động làm sạch/giám sát dữ liệu nhạy cảm như secret hay key trong câu lệnh không, giờ có nhiều LLM nhẹ nên chắc dễ hơn trước

    • CLI được rewrite bằng Rust, nhưng server vẫn là Elixir/Phoenix, phần này khá hợp để làm các tính năng như lọc thông tin nhạy cảm

    • Có phải ngày xưa ban đầu nó từng được làm bằng Python trước không nhỉ

    • Tôi không rõ câu hỏi về tính năng tự động lọc secret/key trong câu lệnh có phải đang nói đùa hay không

  • Các streamer Twitch thường phát bằng hai máy tính: một máy để hiển thị nội dung stream, máy còn lại chạy OBS và HDMI capture
    Nếu tận dụng tính năng live streaming mới của Asciinema, thì với các lập trình viên chỉ làm việc trong console (terminal), có vẻ có thể stream thẳng màn hình terminal của máy dev sang máy OBS mà không cần thiết bị HDMI capture
    Với một nhóm rất nhỏ streamer lập trình, Asciinema 3 có thể trở thành một lựa chọn thay thế thực sự

    • Với streaming của Asciinema thì gần như không ảnh hưởng đến hiệu năng, nên không cần kiểu cấu hình hai máy như vậy
      Thiết lập 2PC ban đầu xuất hiện vì gánh nặng CPU của việc encode x264, nhưng giờ encode bằng GPU (Nvidia NVENC) thì gần như không còn đáng kể
      OBS x264 giờ không còn cần thiết trừ khi bạn ghi hình offline như làm video YouTube

    • Streamer Twitch dùng 2PC là để tránh xung đột tài nguyên khi stream game ngốn nhiều GPU
      Ngoài ra còn để phòng trường hợp driver bị crash trong lúc chơi game làm ảnh hưởng đến buổi stream

    • Kiểu dàn máy stream như vậy chủ yếu để phân tán tải mã hóa video, nên với streamer lập trình chỉ làm việc trong console thì tôi nghĩ thực ra không cần thiết