asciinema CLI 3.0, Rust में फिर से लिखा गया और लाइव स्ट्रीमिंग व फ़ाइल फ़ॉर्मैट अपग्रेड लाया

• टर्मिनल रिकॉर्डिंग टूल asciinema CLI 3.0 को Rust में पूरी तरह फिर से लिखा गया है, जिससे फ़ाइल फ़ॉर्मैट अपग्रेड और टर्मिनल लाइव स्ट्रीमिंग फीचर जोड़े गए हैं
• Rust अपनाने से static binary उपलब्ध कराना, तेज़ startup time, और AVT integration के ज़रिए concurrency·system call handling आसान हुई है, साथ ही नए फीचर्स लागू करने की नींव भी बनी है
• नया asciicast v3 फ़ॉर्मैट event interval (delta)-based timing, term के तहत structured metadata, "x" exit event, और # line comments लाता है, जिससे editing और expressiveness बेहतर होती है
• लाइव टर्मिनल स्ट्रीमिंग दो मोड में मिलती है: local built-in server और remote relay (self-hosted/official server), और नेटवर्क स्थिति के अनुसार adaptive buffering के साथ अधिक smooth viewing experience देती है
• मूल दर्शन को Local-first के रूप में फिर व्यवस्थित किया गया है, जहाँ rec में फ़ाइलनाम अनिवार्य है और upload को अलग किया गया है (upload <फ़ाइल>), साथ ही self-hosted server selection prompt के ज़रिए self-hosting friendliness और अनचाहे data leakage की रोकथाम को मजबूत किया गया है

---

3.0 रिलीज़: Rust में फिर से लिखा गया asciinema CLI और प्रमुख सुधार

• asciinema CLI 3.0 आधिकारिक रूप से रिलीज़ हो गया है
• इस संस्करण में पूरा कोड Rust में फिर से लिखा गया है और साथ ही recording file format को अपग्रेड किया गया है
• टर्मिनल सेशन लाइव स्ट्रीमिंग सहित कई फीचर जोड़े/सुधारे गए हैं

Rust rewrite और समग्र सुधार

• CLI को Rust में पूरी तरह फिर से लिखकर developer experience और maintainability बेहतर की गई है; static binary वितरण से installation path सरल हुआ है, startup speed बेहतर हुई है, और feature extensibility की नींव बनी है
  • लेखक के अनुभव के अनुसार Python की तुलना में system calls और concurrency handling आसान होने के कारण यह चुनाव किया गया, और asciinema virtual terminal (AVT) को CLI में integrate करने से नए फीचर लागू करना संभव हुआ
• परिणामस्वरूप performance, distribution, और architecture के लिहाज़ से भविष्य के फीचर जोड़ने की आधारशिला तैयार हुई है

asciicast v3 फ़ाइल फ़ॉर्मैट

• asciicast v3 फ़ाइल फ़ॉर्मैट के रूप में विकास करते हुए, यह v2 में दिखी कई कमियों को दूर करता है
• v2 के absolute timestamps को interval (delta)-based timing से बदला गया है, जिससे event insert/delete के समय बाद के सभी timestamps को एक साथ समायोजित करने की समस्या खत्म होती है
• header को फिर से संगठित कर terminal-संबंधित metadata को term key के नीचे group किया गया है, और session exit state को सहेजने के लिए "x" (exit) event समर्थित है
• फ़ाइल में line comments (#) की अनुमति दी गई है, जिससे readability और manageability बेहतर होती है
• उदाहरण snippet के ज़रिए structure और event stream composition को सहज रूप से दिखाया गया है
• नया फ़ॉर्मैट asciinema server, asciinema player में पहले से समर्थित है

लाइव टर्मिनल स्ट्रीमिंग

• Local mode: built-in HTTP server के ज़रिए उसी नेटवर्क में देखी जा सकने वाली stream उपलब्ध कराता है; यह privacy-first मोड है जहाँ डेटा केवल दर्शकों के browser तक भेजा जाता है
  • CLI में नवीनतम asciinema player bundled है, इसलिए तुरंत playback संभव है; firewall port खोलने की ज़रूरत पड़ सकती है
• Remote mode: asciinema server (official या self-hosted) को relay के रूप में इस्तेमाल कर shareable URL के ज़रिए stream वितरित की जाती है
  • दोनों मोड एक साथ भी उपयोग किए जा सकते हैं, जिससे स्थिति के अनुसार deployment configuration संभव होती है
• player real-time network latency measurement पर आधारित adaptive buffering के ज़रिए low latency और buffer underrun prevention के बीच संतुलन बनाता है
• server stream auto-recording को सपोर्ट करता है; फिलहाल asciinema.org का operational server recording disabled और एक समय में 1 stream limit नीति पर चल रहा है
  • self-hosting पर डिफ़ॉल्ट रूप से recording enabled रहती है और simultaneous stream limit नहीं होती

Local-first की ओर वापसी

• पहले asciinema rec में upload behavior default flow का हिस्सा था, जिससे अनजाने में public हो जाना या information leakage का जोखिम था
  • 2.4 में upload से पहले selection prompt लाकर इस बदलाव की तैयारी की गई थी, और 3.0 में filename required, rec से upload फीचर हटाना, और upload <फ़ाइल> explicit command के रूप में अलग करना लागू किया गया
• मूल दर्शन को local-first के रूप में स्पष्ट कर दिया गया है, ताकि उपयोगकर्ता इरादे के साथ publish/share का निर्णय लें
  • local-only उपयोग पूरी तरह समर्थित है, और ज़रूरत पड़ने पर ही स्पष्ट रूप से publish किया जाता है

self-hosting friendliness को मजबूत करना

• upload/stream/auth का पहली बार उपयोग करते समय server URL selection prompt दिखाया जाता है; डिफ़ॉल्ट रूप में asciinema.org सुझाया जाता है, लेकिन उपयोगकर्ता की मंशा के अनुसार instance selection सहेज लिया जाता है
  • पहले भी config file/environment variable से यह सेट किया जा सकता था, लेकिन interactive environments (नई VM, Dev container आदि) में अब इसे आसान बनाया गया है
• इससे self-hosting usability बढ़ती है, और साथ ही अनचाहे बाहरी upload को रोकने के लिए एक अतिरिक्त सुरक्षा परत भी मिलती है

वितरण और उपयोग मार्गदर्शन

• हर distribution के package repository में पहुँचने में कुछ समय लग सकता है
• तब तक GNU/Linux·macOS के लिए prebuilt binaries GitHub releases से डाउनलोड कर उपयोग किए जा सकते हैं, या source से build किया जा सकता है
• release notes और विस्तृत change history GitHub के release notes और CHANGELOG दस्तावेज़ों में देखी जा सकती है

[xguru]

क्या 3.0 पहले नहीं आ चुका था? यह सोचकर खोजा, तो पता चला कि यह 2021 की वह पोस्ट थी जिसमें Player को Rust में फिर से लिखते हुए कहा गया था कि यह 4 गुना छोटा और 50 गुना तेज़ होगा.

Asciinema - टर्मिनल स्क्रीन को रिकॉर्ड करें और साझा करें
Asciinema 3.0 - 4 गुना छोटा, 50 गुना तेज़

[GN⁺]

Hacker News टिप्पणियाँ

• Asciinema वाकई एक शानदार टूल है, मैं इसे सभी TerminalTextEffects डेमो कैप्चर करने के लिए इस्तेमाल करता हूँ, Asciinema GIF Generator(AGG) asciicast फ़ाइलों को उच्च-गुणवत्ता वाले terminal GIF में बदल देता है, इसलिए TerminalTextEffects रिपॉज़िटरी या docs में डेमो आसानी से डाले जा सकते हैं
  raw फ़ाइल output या termsvg जैसी विधियाँ TTE के लिए उपयुक्त नहीं हैं क्योंकि वे stdout पर बहुत ज़्यादा डेटा output करती हैं
  AGG docs और TerminalTextEffects रिपॉज़िटरी के लिंक देखना उपयोगी होगा

  • server motd या startup message को हर बार किसी random TTE से सजाकर पास करना मुझे अब भी मज़ेदार लगता है
    मैंने जो उदाहरण बनाया है, वह यहाँ देखा जा सकता है

  • यह prompt effect सच में बहुत सुंदर है, इसका कोई काम हो या न हो, बस इसे बनाते रहना चाहिए
    मैं इसे मंत्रमुग्ध होकर देख रहा हूँ
    TTE ऐसा लगता है जैसे terminal में वही शानदार effects लागू हो गए हों, जिन्होंने बहुत पहले Compiz window manager के कारण मुझे पहली बार Linux इस्तेमाल करने पर मजबूर किया था
    मैं सोच रहा हूँ कि TTE को tmux या vim में screensaver की तरह बीच-बीच में कैसे लागू किया जाए, pipe से जोड़ना चाहिए या alias के रूप में इस्तेमाल करना बेहतर होगा
    लोग आमतौर पर इसे कैसे इस्तेमाल करते हैं, बनाते समय इसका उद्देश्य क्या था, और अब इसका उपयोग कैसे हो रहा है, यह जानने की जिज्ञासा है
    आशा है कि इसका विकास आगे भी जारी रहेगा

  • t-rec भी काफ़ी उपयोगी टूल है, यह मनचाही window रिकॉर्ड करके video या gif बना सकता है
    यह पूरी तरह वही चीज़ नहीं है, लेकिन अगर सिर्फ terminal gif जल्दी share करनी हो, तो कई बार t-rec ज़्यादा आसान होता है

  • 15MB की GIF फ़ाइल बिल्कुल भी स्वीकार्य नहीं है
    न उसमें seek किया जा सकता है, न text select किया जा सकता है, और ऊपर से 15 गुना bandwidth की बर्बादी
    जो text स्वाभाविक रूप से compress हो सकता है, आसानी से seek किया जा सकता है, और accessibility भी देता है, उसे सबसे खराब किस्म के video format में बदल देना वाकई अफ़सोसजनक है
    कम से कम raw asciinema फ़ाइल या web viewer का link भी साथ दिया जाए, तो वह जल्दी load होगा, pause/seek/copy-paste सब संभव होगा
    तेज़ी से loop होती GIF अक्सर बनाने वाले के अलावा किसी और तक अपना आशय ठीक से नहीं पहुँचा पाती

• asciinema.org साइट अभी इतनी लोकप्रिय हो गई है कि उस पर भारी traffic surge है, btop stream से जुड़ा server 95% CPU usage पर पहुँच गया है
  उस stream का उदाहरण यहाँ देखा जा सकता है
  फिर भी BEAM पर चल रहा Elixir/Phoenix server इतने requests और CPU usage के बावजूद ठीक से service दे रहा है — यही है BEAM की ताकत
  फ़िलहाल 2GB RAM वाले सिर्फ दो VM से काम चल रहा है, लेकिन जल्द scale करने की ज़रूरत महसूस हो रही है

  • ऐसे समय में जब पूरा infra cloud की ओर जा रहा है, इतनी प्रसिद्ध service का सिर्फ दो 2GB VM पर स्थिरता से चलना चौंकाने वाला है
    यह आजकल के मध्यम-स्तरीय laptop की RAM से भी कम resources हैं, फिर भी सब सुचारु है

  • infra को तुरंत scale करने के बाद अब सब फिर से स्थिर और responsive हो गया है

  • अभी btop stream बहुत ज़्यादा अटक रही है और CPU usage भी 0% से 100% के बीच लगातार उछल रहा है
    सोच रहा हूँ कहीं service लगातार crash होकर restart तो नहीं हो रही

  • BEAM अमर रहे!

  • एक tip के तौर पर, btop का refresh interval कम कर देना अच्छा होगा, 100ms पर चलाने से btop खुद भी बहुत CPU खा लेता है

• Asciinema client बार-बार Python → Golang → Python → Rust में बदलता रहा है
  इतिहास दस्तावेज़ और संबंधित ब्लॉग भी देखे जा सकते हैं

  • ऐसे project में किस language में implementation है, इससे शायद बहुत फ़र्क नहीं पड़ता, क्योंकि सभी languages लगभग समान performance देंगी
    codebase छोटा है, इसलिए किसी भी language में port करने से functionality पर असर मामूली रहेगा, और अगर developer की motivation बनी रहती है, तो बार-बार rewrite भी ठीक है

  • यह दिलचस्प है
    मेरा मानना है कि Go की ज़्यादातर समस्याएँ code लिखने से पहले ही समझ में आ जानी चाहिए थीं, केवल थोड़ी investigation से भी packaging जैसी समस्याएँ 2016 में वैध शिकायत थीं, लेकिन Go modules के बाद वे हल हो गईं
    उसके बाद ClojureScript, Elixir, Rust में लगातार rewrite करना तकनीकी रुझानों के पीछे भागने जैसा लगता है
    इतनी बार language बदलने से engineering credibility पर असर पड़ता है

• मुझे Asciinema से लगाव है, और मैं छोटे contributions तथा donation के ज़रिए इस project को support करता हूँ
  donation guide और Linux system समस्या-समाधान में Asciinema कैसा दिखता है, यह भी (SadServers replay) एक बार देखना चाहिए

• Asciinema मेरे द्वारा इस्तेमाल किए गए tools और products में सबसे बेहतरीन है
  CLI के ज़रिए authentication/upload का flow इतना साफ़ और सहज है कि कई चरण होने पर भी कभी असुविधाजनक नहीं लगता
  दूसरे CLI में भी ऐसी design होती है, लेकिन Asciinema ने कभी intrusive महसूस नहीं कराया

• इस सचमुच शानदार उपलब्धि के लिए बधाई
  हालाँकि, अच्छा होगा अगर asciinema में सीधे SVG या GIF के रूप में save करने की built-in सुविधा भी हो
  फिर किसी अलग conversion app की ज़रूरत नहीं पड़ेगी और markdown फ़ाइलों में embed करना और आसान हो जाएगा

• Asciinema का बड़ा प्रशंसक होने के नाते मुझे यह काम बहुत शानदार लगा
  live streaming feature के बारे में, मैंने अपने सह-संस्थापक s2.dev की stream पर कुछ ऐसा ही hack करके लगाया था, और इस architecture के साथ शायद बिना किसी मध्य relay के भी यह संभव हो
  व्यक्तिगत रूप से मुझे btop को real time में दिखाना अच्छा लगा
  live streaming architecture के लिए यह दस्तावेज़ उपयोगी होगा

• अब जब terminal real-time streaming feature आ चुका है, तो मज़ेदार होगा अगर कोई terminal के ऊपर overlay के रूप में ASCII art vtuber avatar चढ़ा दे

  • यह Max Headroom v0.2 की याद दिलाने वाला विचार है

• मेरा पसंदीदा elixir project asciinema अब Rust में भी rewrite हो गया है
  मुझे यह प्रगति बहुत पसंद आई
  क्या इसमें command से secret, key जैसी sensitive जानकारी को अपने-आप redact/monitor करने की सुविधा भी जोड़ी गई है, यह जानने की जिज्ञासा है; आजकल हल्के LLM भी बहुत हैं, इसलिए यह पहले से आसान होना चाहिए

  • CLI को Rust में rewrite किया गया है, लेकिन server अब भी Elixir/Phoenix है, और यही हिस्सा sensitive information filtering जैसी सुविधाओं के लिए बिल्कुल उपयुक्त है

  • क्या यह पहले Python में नहीं बना था?

  • command से secret/key auto-filtering वाली बात कहीं मज़ाक तो नहीं है, यह संदेह होता है

• Twitch streamers आम तौर पर दो computers से stream करते हैं, एक gameplay या broadcast screen दिखाने के लिए, और दूसरा OBS व HDMI capture चलाने के लिए
  अगर Asciinema की नई live streaming feature का उपयोग किया जाए, तो केवल console(terminal) में काम करने वाले developers शायद dev machine के terminal output को बिना HDMI capture card के सीधे OBS machine तक stream कर सकें
  बहुत कम संख्या में सही, लेकिन कुछ programming streamers के लिए Asciinema 3 एक वास्तविक alternative बन सकता है

  • Asciinema streaming में performance पर लगभग कोई असर नहीं पड़ता, इसलिए ऐसी dual-machine setup की ज़रूरत नहीं है
    2PC setup की शुरुआत x264 encoding के CPU load के कारण हुई थी, लेकिन आजकल GPU encoding(Nvidia NVENC) से यह बोझ लगभग खत्म हो गया है
    OBS x264 अब offline recording(जैसे YouTube video) के अलावा ज़्यादा आवश्यक नहीं रहा

  • Twitch streamers 2PC का उपयोग इसलिए करते हैं ताकि GPU-intensive game streaming के दौरान resource contention न हो
    साथ ही game के बीच driver crash होने पर stream पर असर न पड़े

  • ऐसे streaming gear setup ज़्यादातर video encoding load बाँटने के लिए होते हैं, इसलिए अगर कोई programming streamer सिर्फ console में काम करता है, तो शायद इसकी ज़रूरत नहीं होगी