SSH के लिए नेटिव ग्राफ़िकल शेल

 (probablymarcus.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अगर सर्वर और edge डिवाइस केवल terminal दिखाने के बजाय browser-based graphical shell दें, तो दूसरे डिवाइस से remote apps को अधिक स्वाभाविक तरीके से इस्तेमाल किया जा सकता है
  • यह shell app home screen और app-to-app URL lookup API देता है, जिससे फ़ाइल या resource को सही app तक पहुँचाने का flow बनाया जा सकता है
  • apps छोटे HTTP server के रूप में UI उपलब्ध कराते हैं, लेकिन यह सामान्य public web server नहीं होते, बल्कि मुख्यतः SSH या local access को ध्यान में रखकर चलने वाले private server होते हैं
  • encryption को हर app में अलग से implement करने के बजाय SSH layer पर छोड़ा जा सकता है, इसलिए हर app server कम dependencies के साथ सरल संरचना बनाए रख सकता है
  • Lewis ने इसके लिए Outer Loop को SSH browser के रूप में बनाया और open source Outer Shell जारी किया, जिसे HTML apps और native outerframe apps दोनों को ध्यान में रखकर डिज़ाइन किया गया है

SSH पर चलने वाला ग्राफ़िकल शेल

  • web browser पहले से ही ऐसा स्थापित मॉडल है जिसमें एक डिवाइस यानी server दूसरे डिवाइस यानी client को अनुभव उपलब्ध कराता है
  • यही तरीका server और edge डिवाइस पर लागू किया जाए तो remote environment में भी terminal-based apps की जगह graphical apps इस्तेमाल किए जा सकते हैं
  • shell apps के लिए home screen देता है, और हर app एक छोटे HTTP server के रूप में web user interface serve करता है
  • shell API apps को एक-दूसरे के URL खोजने देता है, जिससे apps के बीच कनेक्शन बनता है
    • उदाहरण के लिए, अगर कोई app खुद को text editor के रूप में register करे, तो किसी दूसरे app में text file पर double-click करके उसे उस editor app में खोला जा सकता है
  • apps मौजूदा HTML-based web apps भी हो सकते हैं, या native outerframe apps भी

इम्प्लीमेंटेशन का तरीका और जारी प्रोजेक्ट

  • app HTTP server आम तौर पर ऐसे private server की तरह काम करते हैं जिन तक नेटवर्क के दूसरे डिवाइस सीधे पहुँच नहीं सकते
    • उपयोगकर्ता इन्हें SSH के ज़रिए या local रूप से इस्तेमाल करते हैं
    • ज़्यादातर मौजूदा web-based server tools के विपरीत, ये localhost port के बजाय मुख्यतः Unix domain socket file का उपयोग करते हैं
    • Unix domain socket file port की तरह होती है, लेकिन filesystem में मौजूद रहती है और उसके पास स्पष्ट user permissions होते हैं
  • हर HTTP server को encryption खुद संभालने की ज़रूरत नहीं होती
    • encryption SSH layer में संभाला जाता है
    • इसकी वजह से हर app server बिना dependencies के बहुत सरल रह सकता है
  • Outer Loop को ऐसे ग्राफ़िकल शेल के लिए SSH browser के रूप में बनाया गया है
  • open source Outer Shell जारी किया गया है
  • संबंधित दस्तावेज़ तीन हिस्सों में उपलब्ध हैं
    • Outer Loop: browser कैसे काम करता है
    • Outer Shell: Outer Shell API और apps जोड़ने का तरीका
    • Outerframe: native apps कैसे काम करते हैं
  • browser में Unix socket connection जैसी क्षमताओं को अब तक बहुत niche feature माना गया, लेकिन SSH और sudo awareness जैसी सुविधाओं के साथ जुड़कर ये नई तकनीकी संभावनाएँ खोल सकती हैं
  • Jupyter और Tensorboard जैसे अलग-अलग server-style web apps आए, लेकिन हर एक ने अपना एकबारगी security protocol इस्तेमाल किया, इसलिए इन्हें “सही तरीके” से पास करने का कोई साझा तरीका स्थापित नहीं हो पाया
  • AI के code writing में मददगार बनने के साथ, हर app के लिए target platform के हिसाब से अलग codebase रखना व्यावहारिक हो गया है, और एक ऐसे web architecture का प्रस्ताव दिया गया है जिसमें reading और lightweight apps के लिए HTML, जबकि work-oriented apps के लिए platform-specific native apps इस्तेमाल हों

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • इस विचार को कमतर बताने वाली इतनी प्रतिक्रियाएँ देखकर काफ़ी झुंझलाहट होती है। लगता है HN के कई पाठक अभी भी TUI श्रेष्ठतावाद में फँसे हैं और GUI में ज़्यादा दिलचस्पी नहीं रखते
    दो बातें मुख्य हैं। TUI, GUI से स्वभावतः बेहतर नहीं है, और SSH को transport layer के रूप में pty forwarding, यानी TUI display layer ही नहीं बल्कि GUI display layer को भी support करना चाहिए
    असल में ये दोनों बातें 30 साल पहले UNIX में पहले ही साकार हो चुकी थीं, और X protocol तथा ssh -X वाला समाधान भी था। लेकिन X जीत नहीं पाया, और वह भविष्य नहीं आया जिसमें remote machine पर ssh -X से connect करके gnome-control-center चलाने पर settings window खुलती और आप remote computer configure कर पाते। अगर आपको लगता है कि यह ठीक से होता है, तो खुद आज़मा लें; experience बेहद खराब है
    फिर भी यह ज़रूरत बनी रही, और Jupyter Notebook जैसे apps web server के रूप में develop होने लगे। web का document format, styling और client scripting language, अपनी तमाम कमियों के बावजूद interactive apps की display layer के तौर पर इस्तेमाल लायक हो गए, और चूँकि web की शुरुआत ही remote documents से हुई थी, network transparency भी उसमें built-in है
    Electron apps को देखें तो यह मानना पड़ेगा कि HTML/CSS/JS stack desktop apps में भी dominant position पर आ गया है, और इसे SSH के जरिए remote apps की display layer के रूप में इस्तेमाल करना स्वाभाविक है। यह project भी उसी flow में लगता है
    Electron app में भी X की तरह display server और client अलग-अलग होते हैं; उन्हें क्रमशः “renderer process” और “main process” कहा जाता है और वे IPC से communicate करते हैं। सैद्धांतिक रूप से, अगर सही IPC transport मौजूद हो तो main process और renderer process को अलग-अलग machines पर चलाया जा सकता है; यह idea उससे बहुत अलग नहीं लगता

    • Thinlinc, NoMachine, X2Go जैसी चीज़ें भी हैं, और ये सभी SSH को मुख्य backend के रूप में इस्तेमाल करती हैं। यह काफ़ी common idea है
    • ssh -X इस्तेमाल होने वाले toolkit और दूरी/latency पर निर्भर करते हुए अच्छा काम करता है। उदाहरण के लिए, rendering pipeline की वजह से Gtk अच्छा नहीं है
      दूरी और latency काफी बढ़ जाएँ तो सोचना पड़ता है कि इसे user को कैसे दिखाया जाए। माध्यम कोई भी हो, physical limits से बचा नहीं जा सकता। remote graphical access का वादा करने वाले किसी भी tool को latency ध्यान में रखकर design करना चाहिए। vim latency में भी अच्छा चलता है, क्योंकि वह असल में commands को queue में जमा करके भेजता है
    • X forwarding की तरह Wayland को SSH के ऊपर इस्तेमाल किया जा सकता है, और इसे waypipe कहते हैं। इसलिए वह भविष्य मरा नहीं है
    • निजी तौर पर मुझे खुशी है कि ssh -X से remote machine का gnome-control-center खोलकर server configure करने वाला भविष्य नहीं आया। GUI से server configure करना एक घिनौना तरीका है, और यह Windows दुनिया तक ही सीमित रहे तो बेहतर है
    • यह भी काफ़ी चिढ़ाने वाला है कि पहला comment हमेशा दूसरे commenters को दोष देने और उनके विचारों को कमतर बताने वाला होता है

  • यह अतीत में भी कई बार दिखी, समस्या ढूँढ़ती हुई solution जैसी चीज़ लगती है। नीचे वाला quote इस कोशिश पर ठीक बैठता लगता है
    “जो लोग Unix को नहीं समझते, वे उसे खराब तरीके से फिर से बनाने के लिए अभिशप्त हैं।” ~Henry Spencer

    • एक programmer को hire किया और Linux laptop देकर कुछ settings करने को कहा; कुछ घंटों बाद उसने पूछा कि PuTTY कहाँ से download कर सकता हूँ। तभी समझ आया कि interview में एक बड़ी कमी रह गई थी
    • ऐसा नहीं है। अब अधिक लोग Linux इस्तेमाल कर रहे हैं, इसलिए 40 साल पहले लिए गए user experience decisions पर ज़्यादा सवाल उठ रहे हैं
      लगभग हर developer-targeted machine में SSH server installed और accessible होता है
      SSH terminal को 1960 के दशक के text-only कचरे जैसा क्यों दिखना चाहिए? TUI ही SSH से stream करने लायक सबसे अच्छा target क्यों होना चाहिए? terminal में 4K movie क्यों नहीं देख सकते या pinch zoom से web browse क्यों नहीं कर सकते?
    • यह कुछ ज़्यादा कठोर assessment लगता है। असल में usability gap है, और यह project उसी को छूकर देखने की कोशिश है
      SSH से Linux directory को native UI components के रूप में देखने जैसा idea ठीक लगता है
      हालाँकि कुछ चीज़ें sshfs mount जैसे तरीकों से पहले ही solve की जा चुकी समस्याएँ भी लगती हैं
    • “जो लोग Unix को नहीं समझते” वाला हिस्सा ही यहाँ असली मूल समस्या लगता है
      बहुत पहले programmable thermostat पर लिखा एक लेख याद आता है। उसमें कहा गया था कि वह इतना powerful है कि बहुत गहराई से configure किया जा सकता है, लेकिन ज़्यादातर लोगों के लिए इस्तेमाल करना बेहद खराब है। सार कुछ ऐसा था कि “लोग आपका जटिल system सीखना नहीं चाहते, वे उस system द्वारा वादा किए गए फायदे चाहते हैं।” अच्छा UI उस gap को कम करना जानता है
    • यह UNIX से ज़्यादा Plan 9 के करीब लगता है। UNIX को इतना पूजने की ज़रूरत नहीं है

  • graphical app के frontend और backend को अलग करने का idea अच्छा है। लेकिन इसे नया कहना मुश्किल है; शायद मैं कुछ miss कर रहा हूँ
    लगता है इन्हें X11Forwarding yes या html5 web app के बारे में पता नहीं है
    browser के Unix socket से connect करने जैसी capability को बहुत niche feature होने की वजह से reject किया जाता रहा है
    वह security issue है, इसलिए implement नहीं किया गया। कम-से-कम raw Unix sockets के लिए तो यही है; WebSocket या HTTP तक सीमित दूसरे ports संभव हैं

    • security पर संक्षेप में जवाब दूँ तो, कई Mozilla forums में देखी गई चर्चा लगभग ऐसी थी
      browser को किसी भी socket से connect करने की अनुमति नहीं दी जा सकती। कई sockets स्पष्ट रूप से browser connection नहीं चाहते, या उन्हें यह अहसास ही नहीं होता कि browser connect कर सकता है
      इसलिए किसी तरह की allowlist जोड़नी पड़ेगी, और तब यह niche feature के हिसाब से बहुत complex हो जाएगा
      इसलिए मुझे लगता है कि मुख्य बात niche nature ही थी
      संदर्भ के लिए, Outer Loop ने allowlist जोड़ी है: https://outerloop.sh/unix-domain-sockets/

  • मैं यह समझने की कोशिश कर रहा हूँ कि यहाँ Outer Shell कैसे काम करता है। वेबसाइट इसकी प्रेरणा कुछ इस तरह बताती है
    Jupyter या TensorBoard जैसे ऐप अगर remote server पर चल रहे हों, तो वे आम तौर पर standard web browser में दिखाई नहीं देते। क्योंकि पूरी इंटरनेट को इन ऐप्स तक पहुँच देना बहुत जोखिम भरा है। इसके बजाय वे server के local port पर चलते हैं, और मेरा कंप्यूटर वहाँ सीधे access नहीं कर सकता
    परंपरागत रूप से, इन्हें access करने के लिए नया terminal खोलकर ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com & जैसे commands चलाने पड़ते थे
    क्या यह सही है? आम तौर पर तो prototyping के समय ही ऐसी SSH forwarding इस्तेमाल होती है, और deploy करते समय myjupyternotebook.com जैसी website बनाकर authentication लगा देते हैं ताकि दूसरे लोग access न कर सकें। HTTP basic authentication भी कोई बहुत बड़ी बात नहीं है
    अगर आप public exposure को HTTP के बजाय SSH पर रखना चाहते हैं, तो VPN या tunnel के पीछे रखने जैसे दूसरे विकल्प भी हैं
    Outer Loop बहुत शानदार है, लेकिन मुझे साफ़ नहीं है कि इसकी जरूरत क्यों है। शायद मैं कुछ miss कर रहा हूँ, इसलिए यह समझने में मदद चाहिए कि इसे क्यों बनाया गया

    • server, SSH आदि इस्तेमाल करने वाले लोगों के अलग-अलग समूह लगते हैं
      मैं deep learning experiments, GPU kernel optimization, robotics development जैसे use cases के ज्यादा करीब हूँ। robot बस एक चलता-फिरता server ही है, और इन मामलों में हम साफ़ तौर पर remote computer इस्तेमाल कर रहे होते हैं
      इस समूह के लोगों को आपके सुझाए flow की तुलना में यह tool ज्यादा intuitive लग सकता है। हालांकि हो सकता है मैं अपनी सोच ही इसमें project कर रहा हूँ
      मुझे यह उन बुनियादी चीजों में से एक लगता है जो अस्तित्व में हो सकती हैं। कुछ-कुछ remote-first graphical operating system जैसा
    • अगर user सिर्फ एक है, यानी आप खुद, और service को केवल desktop operating system से access करना है, तो यह reverse proxy और TLS certificate संभालने की मेहनत बचाने जैसा दिखता है
    • अगर आप SSH के जरिए बहुत सारे ports forward कर रहे हैं, तो SSH से SOCKS5 proxy शुरू कराने का विकल्प भी सोच सकते हैं
      ssh -D 4711 -q -C -N user@host
      इससे localhost:4711 एक SOCKS5 proxy बन जाता है जिसे browser में set किया जा सकता है
      बेशक WireGuard VPN बेहतर है। सबसे बड़ी बात, SSH एक ही TCP connection पर multiplex करता है, इसलिए अगर एक packet खो जाए तो उसके retransmit होने तक सारा forwarded traffic head-of-line blocking झेलता है
    • HTTP basic authentication सुरक्षित नहीं है
    • SSH port forwarding का मुख्य उपयोग तब होता है जब network किसी misconfiguration की वजह से टूट गया हो और उसे rescue करना हो

  • लगता है लेखक ने Cockpit के बारे में नहीं सुना है
    जिन चीजों को वे “नहीं है” या “नई” कह रहे हैं, वे 10 साल से ज्यादा समय से Cockpit में मौजूद हैं। socket-based web server connections, server apps का backend-frontend separation, shell access वाला server console—ये विचार भी शामिल हैं
    “क्या यह अजीब नहीं है कि यह अभी तक मौजूद नहीं है?” इस सवाल का मेरा जवाब होगा—नहीं। क्योंकि यह पहले से काफी समय से मौजूद है

    • “सभ्य रहें। तंज न कसें। पूछताछ की तरह नहीं, जिज्ञासा के साथ बातचीत करें। व्यंग्य हटाएँ।”
      सच्चे मन से,
      HN guidelines police :-)
      https://news.ycombinator.com/newsguidelines.html
    • अगर मैं गलत नहीं हूँ, तो Cockpit एक web UI है और native code नहीं चलाता। यह महत्वपूर्ण फर्क है
    • मैंने भी Cockpit के बारे में नहीं सुना। यह क्या है?

  • शानदार लेख है। अपनी research के लिए bookmark करूँगा
    मेरे terminal की “clickity clackity” feature [0] local machine से जुड़ी है, इसलिए जैसे ही remote में जाते हैं, graphical nature गायब हो जाती है
    offline replay [1] की वजह से यह धीरे-धीरे बदल रहा है। इसमें native GUI और TUI साथ काम करते हैं और rewind जैसी capabilities खोलते हैं। लेकिन अभी काफी लंबा रास्ता है, और दूसरों को सही तरीके से experiment करते देखना अच्छा है। terminal एक बहुत ज्यादा उपेक्षित क्षेत्र है
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • terminal से परिचित लोग भूल जाते हैं कि university में न सीखने वाले व्यक्ति के लिए SSH कितना hostile है
    अगर यह VPS manage करने वाली छोटी team के लिए platform person hire किए बिना entry barrier कम कर सके, तो यह सफल है। हालांकि keys और jump hosts को कैसे handle करेगा, यह जानने की उत्सुकता है

  • कमाल है। यह निश्चित रूप से सही दिशा में जा रहा है
    frontend और backend के बीच separation layer को सबसे छोटे संभव “टुकड़े” पर काटना चाहिए
    यहाँ तंज कस रहे कई लोग भी latency और extra overhead को खुद “महसूस” करेंगे तो समझेंगे। अलग-अलग use cases के हिसाब से data को सावधानी से काटने पर पर्याप्त सोच नहीं लगाई गई
    आगे बढ़कर कहूँ तो, demo में जिस top app के बारे में कहा गया कि “settings को बार-बार हिलाकर load बनाया”, उसमें client side पर rendering को ज्यादा JIT करना चाहिए था। तब Pi और client के बीच आने-जाने वाली information ps output के compressed delta भर तक घट जाती

  • ऐसा नहीं करना चाहिए। browser को general socket permissions न देने के पीछे बहुत पुराने, मजबूत security reasons और web control plane isolation के कई कारण हैं
    mechanically सबसे नज़दीकी उपमा यह है कि 3-wheel ATV खराब idea क्यों है

    • मुझे लगता है, अगर ये शर्तें हों तो ठीक है
      sockets default रूप से blocked हों, और server side पर explicitly allowlist किए जाने के बाद ही खुलें
      असली sudo awareness हो, ताकि sudo password के बिना root sockets तक पहुँचा न जा सके। यह feature इसलिए महत्वपूर्ण है क्योंकि नहीं तो लोगों को user-accessible sockets के साथ root backend चलाने के लिए प्रेरित करने वाला incentive बन जाएगा
      details यहाँ हैं: https://outerloop.sh/security/