1 पॉइंट द्वारा GN⁺ 2025-04-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Atuin Desktop टर्मिनल workflow के लिए एक executable local-first runbook editor प्रदान करता है
  • script blocks, embedded terminal, database client, और Prometheus charts को एक ही जगह मैनेज किया जा सकता है
  • दस्तावेज़ों के पुराने पड़ने से बचाव और पुन: उपयोग योग्य automation के ज़रिए workflows को दोहराने योग्य और भरोसेमंद बनाता है
  • Atuin Hub के माध्यम से sync और share किया जा सकता है, और वास्तविक shell history से auto-complete को सपोर्ट करता है
  • team accounts और shell history से runbook generation के ज़रिए collaborative operations को मज़बूत करने की योजना है

Atuin Desktop परिचय

  • Atuin Desktop एक executable runbook editor है, जो वास्तविक terminal workflows को दोहराने योग्य, साझा करने योग्य और भरोसेमंद बनाता है
  • यह सुनिश्चित करता है कि दस्तावेज़ लिखते ही पुराने न पड़ जाएँ, और Jinja-style templates के साथ dynamic runbooks प्रदान करता है
  • वास्तविक shell history से auto-complete को सपोर्ट करता है, जिससे तुरंत recall संभव होता है
  • local-first, CRDT-based होने के कारण terminal में जो कुछ चलता है, वह runbook में भी चल सकता है
  • Atuin Hub के माध्यम से devices और teams के बीच sync और share करके इसे हमेशा up-to-date रखा जा सकता है

अभी इसका उपयोग कैसे किया जा रहा है

  • Atuin Desktop के जरिए वास्तविक workflows चलाए जा रहे हैं
    • Atuin CLI releases
    • environments के बीच infrastructure को सुरक्षित तरीके से migrate करना
    • staging या production environments को भरोसे के साथ सेट अप करना
    • real-time database queries को मैनेज करना और उन पर collaboration करना

आगे की योजना

  • team accounts: असली collaborative operations
  • shell history से runbook generation: workflows जो खुद लिखे जाते हैं

1 टिप्पणियां

 
GN⁺ 2025-04-23
Hacker News टिप्पणियाँ
  • Emacs में रुचि रखने वालों के लिए, org-babel का उपयोग करके ऐसा ही काम किया जा सकता है

    • टेक्स्ट फ़ाइलें program, document, notebook, website आदि के रूप में इस्तेमाल की जा सकती हैं
    • यह बहुत शक्तिशाली है और literate programming का एक अच्छा उदाहरण है
    • संबंधित सामग्री यहाँ देखी जा सकती है: https://osem.seagl.org/conferences/seagl2019/program/proposals/664
  • मैंने लगभग 7 साल पहले इस आइडिया को आज़माया था: https://nurtch.com/

    • इस आइडिया में बहुत मूल्य है
    • मैंने JupyterCon Paris 2023 में इस पर एक प्रस्तुति दी थी: https://www.youtube.com/watch?v=TUYY2kHrTzs
    • अगर documents में executable code शामिल है, तो मैं documents पर भी PR review workflow लागू करना चाहूँगा
    • इसके लिए wiki editing की तुलना में टीम की ओर से अधिक निवेश चाहिए
    • शुभकामनाएँ
  • अगर यह local-first है, तो यह पहले से ही corruption के प्रति संवेदनशील है। जब तक सब कुछ container में नहीं चल रहा, local मायने नहीं रखता

    • अगर आप runbook रिकॉर्ड करना चाहते हैं, तो यह कई तरीकों से किया जा सकता है। टेक्स्ट फ़ाइल, Confluence document, screen recording, shell script आदि
    • लोग पहले से ही ऐसा नहीं कर रहे हैं, और सिर्फ UI ज़्यादा चमकदार होने से वे अचानक इसे ज़्यादा नहीं करने लगेंगे
    • निजी तौर पर, मैं किसी system को किसी खास state में लाने के लिए code (या document) नहीं लिखना चाहता
    • मैं state को manually बनाना चाहता हूँ, फिर किसी tool से उस state को dump करना, और बाद में उसी tool को फिर चलाकर उस state को बनाना (या enforce करना) चाहता हूँ
    • मैं यह code में नहीं लिखना चाहता कि computer उस state तक कैसे पहुँचे
    • मैं "declarative configuration" नहीं लिखना चाहता। वह बस किसी और नाम से code ही है
    • मैं manually काम करना, snapshot लेना, और उसे replay करना चाहता हूँ
    • मैं चाहता हूँ कि यह हर system पर, हर जगह काम करे। मैं commands के लिए Bash shell monitoring पर निर्भर हुए बिना state को dump करना और बाद में उसे फिर से apply करना चाहता हूँ
  • जब मैं AWS में था, तब मैं अपनी टीम के लिए ठीक यही चाहता था

    • operations के कई ऐसे versions होते हैं जिन्हें automate करना थोड़ा जोखिम भरा होता है
    • यह उसे धीरे-धीरे बनाने का रास्ता देता है
    • बधाई
  • मैं सोच रहा हूँ कि यह local Jupyter notebook से कैसे अलग है

    • मैं सोच रहा हूँ कि क्या .ipynb में ! या % का इस्तेमाल करके यह काम नहीं किया जा सकता
    • मैं यह ईमानदारी से पूछ रहा हूँ। मैं इस कंपनी या CLI product से परिचित नहीं हूँ
  • दिलचस्प लग रहा है

    • मैंने हाल ही में Jupyter notebooks के विकल्प के रूप में marimo.io का उपयोग शुरू किया है
    • इसमें कई शानदार सुधार हैं, और यह उसी दिशा में एक कदम लगता है
  • लॉन्च के लिए बधाई

    • मैं Atuin को थोड़ा-बहुत follow करता रहा हूँ, और भले ही यह executable runbook feature मेरे लिए नहीं है, फिर भी लोगों को कुछ नया और मज़ेदार बनाते देखना अच्छा लगता है
  • हमारी टीम polyglot notebooks का उपयोग करती थी: https://marketplace.visualstudio.com/items/…

    • हम C# को मुख्य भाषा के रूप में इस्तेमाल करके nuget packages के ज़रिए shared code का उपयोग करते हुए runbooks बना सकते थे
    • इससे वे हमारे अपने API और applications के साथ उसी तरह interact कर सकते थे जैसे production में चलने वाला दूसरा code करता है
    • यह review करने के लिए सबसे अच्छा अनुभव नहीं था, लेकिन हमारे लिए यह काम करता था
  • यह runme.dev से बहुत मिलता-जुलता लगता है: https://runme.dev

  • मैं यह बात समझ नहीं पा रहा हूँ। क्या कोई समझा सकता है कि मैं क्या मिस कर रहा हूँ?

    • मैं सोच रहा हूँ कि एक साधारण shell script की बजाय इसका उपयोग क्यों करना चाहिए