asciinema CLI 3.0 เขียนใหม่ด้วย Rust พร้อมเพิ่มไลฟ์สตรีมมิงและอัปเกรดฟอร์แมตไฟล์

• เครื่องมือบันทึกเทอร์มินัล asciinema CLI 3.0 ถูก เขียนใหม่ทั้งหมด ด้วย Rust พร้อมเพิ่มความสามารถ อัปเกรดฟอร์แมตไฟล์ และ ไลฟ์สตรีมมิงเทอร์มินัล
• การเลือกใช้ Rust ทำให้สามารถแจกจ่ายแบบ static binary ได้ มีเวลาเริ่มต้นที่รวดเร็วขึ้น และด้วยการผสาน AVT จึงจัดการ concurrency และ system call ได้ง่ายขึ้น พร้อมวางรากฐานสำหรับฟีเจอร์ใหม่
• ฟอร์แมตใหม่ asciicast v3 เพิ่มระบบเวลาแบบ interval (delta)-based timing สำหรับอีเวนต์, จัดโครงสร้างเมตาดาต้าย่อยไว้ใต้ term, รองรับอีเวนต์จบการทำงาน "x", และเพิ่มคอมเมนต์ระดับบรรทัด # เพื่อให้แก้ไขและแสดงผลได้ยืดหยุ่นขึ้น
• ไลฟ์สตรีมมิงเทอร์มินัล มีให้ใช้สองโหมดคือเซิร์ฟเวอร์ภายในเครื่องแบบโลคัล และรีเลย์ระยะไกล (โฮสต์เอง/เซิร์ฟเวอร์ทางการ) โดยมี adaptive buffering ตามสภาพเครือข่ายเพื่อให้การรับชมลื่นไหล
• ปรัชญาหลักถูกปรับกลับเป็น Local-first โดย rec ต้องระบุชื่อไฟล์เสมอและแยกการอัปโหลดออกมาต่างหาก (upload <ไฟล์>), พร้อม พรอมป์ตให้เลือกเซิร์ฟเวอร์ของตนเอง เพื่อรองรับการ self-hosting มากขึ้นและลดความเสี่ยงจาก ข้อมูลรั่วไหลโดยไม่ตั้งใจ

---

เปิดตัว 3.0: asciinema CLI ที่เขียนใหม่ด้วย Rust และการปรับปรุงสำคัญ

• asciinema CLI 3.0 เปิดตัวอย่างเป็นทางการแล้ว
• เวอร์ชันนี้มีการ เขียนโค้ดทั้งหมดใหม่ด้วย Rust ควบคู่ไปกับ การอัปเกรดฟอร์แมตไฟล์บันทึก
• มีการเพิ่มและปรับปรุงฟีเจอร์หลายอย่าง รวมถึง ไลฟ์สตรีมมิงเซสชันเทอร์มินัล

การเขียนใหม่ด้วย Rust และการปรับปรุงโดยรวม

• CLI ถูก เขียนใหม่ทั้งหมดด้วย Rust เพื่อยกระดับประสบการณ์ของนักพัฒนาและการบำรุงรักษา พร้อมทั้งแจกจ่ายเป็น static binary ทำให้ขั้นตอนติดตั้งง่ายขึ้น เปิดใช้งานได้เร็วขึ้น และรองรับการขยายฟีเจอร์ได้ดีขึ้น
  • ผู้เขียนเลือกใช้ Rust จากประสบการณ์ที่พบว่าการจัดการ system call และ concurrency ทำได้ง่ายกว่า Python และยังผสาน asciinema virtual terminal (AVT) เข้ากับ CLI จึงเปิดทางให้สร้างฟีเจอร์ใหม่ได้
• ผลลัพธ์คือได้ รากฐานสำหรับการเพิ่มฟีเจอร์ในอนาคต ทั้งในด้านประสิทธิภาพ การแจกจ่าย และสถาปัตยกรรม

ฟอร์แมตไฟล์ asciicast v3

• ฟอร์แมตไฟล์ asciicast v3 คือวิวัฒนาการถัดไปที่เข้ามาแก้ข้อจำกัดหลายอย่างของ v2
• ระบบ timestamp แบบค่าสัมบูรณ์ของ v2 ถูกแทนที่ด้วย interval (delta)-based timing เพื่อแก้ปัญหาที่ต้อง ปรับ timestamp ทั้งชุดของเหตุการณ์ถัดไป เมื่อต้องแทรกหรือลบอีเวนต์
• มีการจัดโครงสร้าง header ใหม่ โดยรวมเมตาดาต้าที่เกี่ยวกับเทอร์มินัลไว้ใต้คีย์ term และรองรับอีเวนต์ "x" (exit) สำหรับเก็บสถานะการจบเซสชัน
• อนุญาตให้มี คอมเมนต์ระดับบรรทัด (#) ภายในไฟล์ เพื่อให้อ่านและดูแลจัดการได้ง่ายขึ้น
• มีตัวอย่างสไนปเป็ตเพื่อแสดงโครงสร้างและการจัดองค์ประกอบของสตรีมอีเวนต์ให้เข้าใจได้ตรงไปตรงมา
• ฟอร์แมตใหม่นี้รองรับแล้วใน asciinema server และ asciinema player

ไลฟ์สตรีมมิงเทอร์มินัล

• โหมดโลคัล: ใช้เซิร์ฟเวอร์ HTTP ที่ฝังมาในตัวเพื่อให้รับชมสตรีมได้ภายในเครือข่ายเดียวกัน เป็นโหมดที่ ให้ความสำคัญกับความเป็นส่วนตัว เพราะข้อมูลจะถูกส่งไปยังเบราว์เซอร์ของผู้ชมเท่านั้น
  • CLI มาพร้อม asciinema player เวอร์ชันล่าสุดแบบ bundle จึงเล่นได้ทันที แต่อาจต้องเปิดพอร์ตบนไฟร์วอลล์
• โหมดระยะไกล: ใช้ asciinema server (ทั้งเซิร์ฟเวอร์ทางการหรือที่โฮสต์เอง) เป็นรีเลย์เพื่อเผยแพร่สตรีมผ่าน URL ที่แชร์ได้
  • ทั้งสองโหมดสามารถใช้งาน พร้อมกันได้ ทำให้เลือกการกระจายสตรีมได้ตามสถานการณ์
• ตัว player ใช้ adaptive buffering โดยอิงจากการวัดความหน่วงของเครือข่ายแบบเรียลไทม์ เพื่อสร้างสมดุลระหว่างความหน่วงต่ำกับการป้องกัน buffer underrun
• ฝั่งเซิร์ฟเวอร์รองรับ การบันทึกสตรีมอัตโนมัติ ขณะที่เซิร์ฟเวอร์ asciinema.org ที่ให้บริการอยู่ในปัจจุบันปิดการบันทึกไว้ และมีนโยบาย จำกัดสตรีมพร้อมกัน 1 รายการ
  • หาก self-hosting จะเปิดการบันทึกเป็นค่าเริ่มต้น และไม่มีการจำกัดจำนวนสตรีมพร้อมกัน

การกลับสู่แนวทาง Local-first

• ในอดีต asciinema rec มีขั้นตอนอัปโหลดรวมอยู่ในเส้นทางการใช้งานปกติ จึงมีความเสี่ยงต่อ การเปิดเผยหรือรั่วไหลของข้อมูลโดยไม่รู้ตัว
  • ในเวอร์ชัน 2.4 ได้เพิ่ม พรอมป์ตก่อนอัปโหลด เพื่อเตรียมการเปลี่ยนผ่าน และใน 3.0 ได้เปลี่ยนเป็น ต้องระบุชื่อไฟล์ พร้อม ตัดความสามารถอัปโหลดออกจาก rec และแยกเป็นคำสั่งชัดเจน upload <ไฟล์>
• ปรัชญาหลักถูกทำให้ชัดเจนว่าเป็น local-first โดยออกแบบ flow ใหม่ให้ผู้ใช้เป็นผู้ตัดสินใจว่าจะเผยแพร่หรือแชร์เมื่อมีเจตนาเท่านั้น
  • รองรับการใช้งานแบบโลคัลล้วน อย่างสมบูรณ์ และจะเผยแพร่ก็ต่อเมื่อสั่งอย่างชัดเจนเมื่อจำเป็น

เสริมความเป็นมิตรต่อการ self-hosting

• เมื่อใช้ upload/stream/auth ครั้งแรก จะมี พรอมป์ตให้เลือก URL ของเซิร์ฟเวอร์ โดยเสนอค่าเริ่มต้นเป็น asciinema.org แต่จะบันทึก อินสแตนซ์ที่ผู้ใช้เลือกตามเจตนา ไว้
  • เดิมก็สามารถกำหนดผ่านไฟล์ตั้งค่าหรือตัวแปรสภาพแวดล้อมได้อยู่แล้ว แต่แนวทางนี้ช่วยให้กำหนดค่าได้ง่ายขึ้นใน สภาพแวดล้อมแบบโต้ตอบ (เช่น VM ใหม่หรือ Dev container)
• แนวทางนี้ช่วยเพิ่มความสะดวกในการ self-hosting และยังทำหน้าที่เป็นมาตรการความปลอดภัยเพิ่มเติมเพื่อ ป้องกันการอัปโหลดออกภายนอกโดยไม่ต้องการ

การแจกจ่ายและคำแนะนำการใช้งาน

• อาจต้องใช้เวลาสักระยะกว่าที่แต่ละดิสทริบิวชันจะอัปเดตแพ็กเกจในรีโพซิทอรีของตน
• ในระหว่างนี้สามารถดาวน์โหลด ไบนารีที่ pre-build แล้วสำหรับ GNU/Linux และ macOS จาก GitHub Releases มาใช้งาน หรือจะ build จากซอร์ส ก็ได้
• รายละเอียดรีลีสและประวัติการเปลี่ยนแปลงแบบเต็มสามารถดูได้จาก release notes และเอกสาร CHANGELOG บน GitHub

[xguru]

เวอร์ชัน 3.0 เคยออกมาก่อนหน้านี้แล้วไม่ใช่หรือ? พอลองค้นดูก็พบว่าเป็นโพสต์เมื่อปี 2021 ที่ประกาศไว้ว่า ตอนเขียน Player ใหม่ด้วย Rust จะทำให้ขนาดเล็กลง 4 เท่าและเร็วขึ้น 50 เท่า

Asciinema - บันทึกและแชร์หน้าจอเทอร์มินัล
Asciinema 3.0 - เล็กลง 4 เท่า เร็วขึ้น 50 เท่า

[GN⁺]

ความคิดเห็นบน Hacker News

• Asciinema เป็นเครื่องมือที่ยอดเยี่ยมจริง ๆ ฉันใช้มันตอนจับเดโมของ TerminalTextEffects ทั้งหมด โดย Asciinema GIF Generator (AGG) จะช่วยแปลงไฟล์ asciicast ให้เป็น GIF เทอร์มินัลคุณภาพสูง ทำให้เอาเดโมไปใส่ในรีโพซิทอรีหรือเอกสารของ TerminalTextEffects ได้ง่าย
  วิธีแบบ raw file output หรือแนว ๆ termsvg ไม่ค่อยเหมาะกับ TTE เพราะมันพ่นข้อมูลจำนวนมหาศาลออกมาทาง stdout
  ลองดู เอกสาร AGG และลิงก์ไปยัง รีโพซิทอรี TerminalTextEffects ได้

  • ทุกครั้งที่ตกแต่ง motd ของเซิร์ฟเวอร์หรือข้อความตอนเริ่มต้นด้วย TTE แบบสุ่มก็รู้สึกสนุกมาก
    ตัวอย่างที่ฉันทำไว้ดูได้ที่นี่

  • เอฟเฟกต์พร้อมต์นี้สวยจริง ๆ ไม่ว่าจะมีประโยชน์ใช้งานหรือไม่ก็อยากให้ทำต่อไปเรื่อย ๆ ดูเพลินมาก
    TTE ให้ความรู้สึกเหมือนเอาเอฟเฟกต์สุดมหัศจรรย์ที่ครั้งหนึ่งเคยทำให้ฉันเริ่มใช้ลินุกซ์จาก Compiz window manager มาสร้างใหม่ในเทอร์มินัล
    อยากรู้ว่ามีวิธีเอา TTE ไปใช้กับ tmux หรือ vim เป็นพัก ๆ แบบ screensaver ไหม ต้องต่อผ่าน pipe หรือทำเป็น alias จะดีกว่าไหม
    ปกติใช้งานกันยังไง ตอนสร้างขึ้นมามีไว้เพื่ออะไร และตอนนี้เอาไปใช้แบบไหนกันบ้าง
    หวังว่าจะพัฒนาต่อไปเรื่อย ๆ

  • t-rec ก็เป็นเครื่องมือที่มีประโยชน์มากเช่นกัน สามารถอัดหน้าต่างที่ต้องการแล้วทำเป็นวิดีโอหรือ gif ได้
    แม้จะไม่เหมือนกันเสียทีเดียว แต่ถ้าแค่อยากแชร์ terminal gif อย่างรวดเร็ว บางครั้ง t-rec ก็ง่ายกว่า

  • ไฟล์ GIF ขนาด 15MB นี่รับไม่ไหวจริง ๆ
    ทั้งเลื่อนไปตำแหน่งที่ต้องการก็ไม่ได้ เลือกข้อความก็ไม่ได้ แถมยังเปลืองแบนด์วิดท์มากกว่าถึง 15 เท่า
    การเอาข้อความที่บีบอัดได้ดี เลื่อนดูง่าย และเข้าถึงได้ดี ไปแปลงเป็นวิดีโอในฟอร์แมตที่แย่ที่สุดนี่น่าเสียดายมาก
    อย่างน้อยก็ควรแนบไฟล์ asciinema แบบ raw หรือให้ลิงก์ไปยัง web viewer ด้วย แบบนั้นจะโหลดได้เร็ว หยุด/เลื่อน/คัดลอก-วางก็ทำได้หมด
    GIF ที่วนลูปเร็ว ๆ มักแทบไม่สื่อเจตนาของผู้ทำให้คนอื่นเข้าใจได้เลย

• ตอนนี้เว็บ asciinema.org ได้รับความนิยมมากจนทราฟฟิกพุ่งหนักมาก CPU บนเซิร์ฟเวอร์ที่ต่อกับสตรีม btop ขึ้นไปถึง 95% เลย
  ตัวอย่างสตรีมดังกล่าวดูได้ที่นี่
  ถึงอย่างนั้นเซิร์ฟเวอร์ Elixir/Phoenix ที่รันบน BEAM ก็ยังให้บริการได้สบาย ๆ แม้มีคำขอจำนวนมากและใช้ CPU สูง — นี่แหละพลังของ BEAM
  ตอนนี้ยังเอาอยู่ด้วย VM ขนาด 2GB RAM แค่ 2 เครื่อง แต่คงต้องขยายในไม่ช้า

  • ในยุคที่โครงสร้างพื้นฐานทุกอย่างไหลไปรวมที่คลาวด์ การที่บริการดังขนาดนี้รันได้เสถียรบน VM 2GB แค่สองเครื่องถือว่าน่าทึ่งมาก
    ใช้ทรัพยากรน้อยกว่าแรมของโน้ตบุ๊กระดับกลางสมัยนี้เสียอีกแต่ก็ยังลื่นดี

  • หลังจากขยายอินฟราทันที ตอนนี้กลับมาเสถียรและตอบสนองดีอีกครั้งแล้ว

  • ตอนนี้สตรีม btop กระตุกหนักมาก และการใช้ CPU ก็เหวี่ยงขึ้นลงระหว่าง 0% ถึง 100% ตลอด
    เลยสงสัยว่าบริการกำลังแครชแล้วรีสตาร์ตซ้ำอยู่หรือเปล่า

  • BEAM จงเจริญ!

  • ขอแนะนำว่าควรลดรอบการรีเฟรชของ btop ลงหน่อย ถ้าตั้งไว้ 100ms ตัว btop เองจะกิน CPU เยอะ

• ไคลเอนต์ Asciinema เปลี่ยนไปมาจาก Python → Golang → Python → Rust
  ดูเพิ่มได้ที่ เอกสารประวัติการเปลี่ยนแปลง และ บล็อกที่เกี่ยวข้อง

  • โปรเจกต์แบบนี้จะเขียนด้วยภาษาอะไรก็คงไม่ได้ต่างกันมาก เพราะทุกภาษาก็ให้ประสิทธิภาพใกล้เคียงกัน
    เพราะโค้ดเบสเล็ก ต่อให้ย้ายภาษา ฟีเจอร์ก็คงแทบไม่เปลี่ยน ดังนั้นถ้านักพัฒนาจะเขียนใหม่เรื่อย ๆ ด้วยภาษาที่ทำให้มีแรงจูงใจ ก็ถือว่าโอเค

  • ก็น่าสนใจดี
    ฉันคิดว่าปัญหาส่วนใหญ่ของ Go ควรมองเห็นได้ก่อนจะเริ่มเขียนโค้ดเสียอีก แค่ศึกษานิดหน่อยก็น่าจะรู้เรื่องปัญหา packaging ซึ่งในปี 2016 ก็เป็นข้อบ่นที่สมเหตุสมผล แต่หลังจากมี Go modules แล้วก็ถูกแก้ไป
    หลังจากนั้นการเขียนใหม่ต่อด้วย ClojureScript, Elixir, Rust มันให้ความรู้สึกเหมือนกำลังไล่ตามกระแสเทคโนโลยีมากกว่า
    การเปลี่ยนภาษาไปมาบ่อย ๆ แบบนี้ทำให้ความน่าเชื่อถือด้านวิศวกรรมลดลง

• ฉันชอบ Asciinema มาก และสนับสนุนโปรเจกต์นี้ด้วยการมีส่วนร่วมเล็ก ๆ น้อย ๆ และการบริจาค
  แนะนำให้ดู ข้อมูลการบริจาค และดูด้วยว่า Asciinema แสดงผลอย่างไรเวลาจัดการปัญหาระบบลินุกซ์ (รีเพลย์ของ SadServers)

• Asciinema เป็นเครื่องมือ/ผลิตภัณฑ์ที่ดีที่สุดที่ฉันเคยใช้มาแบบทิ้งห่าง
  ขั้นตอนยืนยันตัวตน/อัปโหลดผ่าน CLI เรียบร้อยและตรงไปตรงมามาก ต่อให้มีหลายสเต็ปก็ไม่เคยรู้สึกน่ารำคาญ
  CLI อื่นก็มีดีไซน์คล้ายกันอยู่บ้าง แต่ของ Asciinema ไม่เคยให้ความรู้สึกว่าถูกรบกวนเลย

• ขอแสดงความยินดีกับความสำเร็จอันยอดเยี่ยมนี้
  แต่อยากให้ asciinema มีฟังก์ชันบันทึกเป็น SVG หรือ GIF ได้ในตัว
  จะได้เอาไปแทรกในไฟล์ Markdown ได้เลยโดยไม่ต้องพึ่งแอปแปลงแยก ทำให้ใช้งานสะดวกขึ้นมาก

• ในฐานะแฟนตัวยงของ Asciinema ฉันคิดว่างานครั้งนี้ยอดเยี่ยมจริง ๆ
  เรื่องฟีเจอร์ไลฟ์สตรีมมิงนั้น ฉันเคยแฮ็กอะไรคล้าย ๆ กันไว้บน สตรีม ของ s2.dev ที่ฉันเป็นผู้ร่วมก่อตั้ง และด้วยสถาปัตยกรรมแบบนี้ก็น่าจะทำได้โดยไม่ต้องมีรีเลย์ตรงกลาง
  ส่วนตัวแล้วชอบที่เอา btop มาแสดงแบบเรียลไทม์ มันดูเจ๋งมาก
  ถ้าจะดูโครงสร้างของระบบไลฟ์สตรีมมิง เอกสารนี้ น่าจะช่วยได้

• เมื่อมีฟีเจอร์สตรีมสดของเทอร์มินัลแล้ว ก็น่าสนุกถ้ามีใครทำ avatar vtuber แบบ ASCII art มาโอเวอร์เลย์บนเทอร์มินัล

  • เป็นไอเดียที่ทำให้นึกถึง Max Headroom v0.2

• asciinema ซึ่งเป็นโปรเจกต์ elixir ที่ฉันชอบที่สุด ตอนนี้ถูกเขียนใหม่ด้วย Rust แล้ว
  ฉันชอบพัฒนาการนี้มาก
  แต่อยากรู้ว่าในคำสั่งมีการเพิ่มฟังก์ชันสำหรับกรอง/ตรวจจับข้อมูลลับ เช่น secret หรือ key โดยอัตโนมัติหรือยัง ทุกวันนี้มี LLM เบา ๆ เยอะขึ้นแล้ว น่าจะทำได้ง่ายกว่าเมื่อก่อน

  • CLI ถูกเขียนใหม่ด้วย Rust ก็จริง แต่เซิร์ฟเวอร์ยังเป็น Elixir/Phoenix อยู่ และส่วนนี้เหมาะมากกับฟีเจอร์อย่างการกรองข้อมูลลับ

  • ก่อนหน้านี้มันไม่ได้เริ่มจาก Python ก่อนเหรอ

  • คำถามเรื่องกรอง secret/key อัตโนมัติจากคำสั่งนี่สงสัยว่าไม่ได้พูดเล่นใช่ไหม

• ปกติสตรีมเมอร์บน Twitch ใช้คอมสองเครื่องในการสตรีม โดยเครื่องหนึ่งไว้แสดงภาพที่ถ่ายทอด อีกเครื่องไว้รัน OBS และ HDMI capture
  ถ้าใช้ฟีเจอร์ไลฟ์สตรีมมิงใหม่ของ Asciinema นักพัฒนาที่ทำงานอยู่แค่ในคอนโซล (terminal) ก็น่าจะสตรีมหน้าจอเทอร์มินัลจากเครื่อง dev ไปยังเครื่อง OBS ได้ตรง ๆ โดยไม่ต้องใช้ตัวจับภาพ HDMI
  สำหรับสตรีมเมอร์สายเขียนโปรแกรมกลุ่มเล็ก ๆ Asciinema 3 อาจกลายเป็นทางเลือกที่แท้จริงได้

  • ถ้าเป็นการสตรีมด้วย Asciinema แทบไม่มีผลกระทบต่อประสิทธิภาพอยู่แล้ว จึงไม่จำเป็นต้องมีชุดอุปกรณ์แบบนี้
    เหตุผลที่เซ็ตอัป 2PC เกิดขึ้นแต่แรกคือภาระ CPU จากการเข้ารหัส x264 แต่ทุกวันนี้ถ้าเข้ารหัสด้วย GPU (Nvidia NVENC) แทบไม่มีภาระแล้ว
    OBS x264 แทบไม่จำเป็นแล้ว เว้นแต่จะใช้บันทึกแบบออฟไลน์ เช่น ทำวิดีโอลง YouTube

  • ที่สตรีมเมอร์ Twitch ใช้ 2PC เป็นเพราะการสตรีมเกมที่ใช้ GPU หนัก ๆ ต้องการหลีกเลี่ยงการแย่งทรัพยากร
    อีกอย่างคือช่วยป้องกันไม่ให้การแครชของไดรเวอร์ระหว่างเล่นเกมส่งผลกับสตรีม

  • เซ็ตอัปอุปกรณ์สตรีมแบบนี้ส่วนใหญ่มีไว้กระจายภาระการเข้ารหัสวิดีโอ ดังนั้นถ้าเป็นสตรีมเมอร์สายเขียนโปรแกรมที่ทำงานแค่ในคอนโซล ก็คงไม่จำเป็นเท่าไรนัก