Tmux को OS बनाइए
एक लंबे समय से terminal उपयोगकर्ता tmux जैसी persistence और keyboard-centric window management पर आधारित operating system UI की कल्पना करता है, जिससे यह बहस छिड़ जाती है कि क्या यह दृष्टि सिर्फ tiling window managers और i3, Niri, या Emacs जैसे मौजूदा tools को ही दोहराती है। Commenters का विभाजन highly configurable, power-user setups को महत्व देने और mainstream adoption के लिए friendlier defaults तथा कम manual configuration, शायद local LLMs की मदद से, की आवश्यकता मानने के बीच है। इसके नीचे filesystems बनाम app-specific data silos और traditional file-based organization को task- या app-centric models से बदलने से वास्तव में उपयोगकर्ताओं को लाभ होता है या नहीं, इस पर एक व्यापक बहस चलती है।
Tmux, multiplexers, और persistence
- कई टिप्पणियाँ sessions और machines के बीच persistence को tmux के मुख्य value के रूप में केंद्रित करती हैं।
- tmux-resurrect और tmux-continuum जैसे plugins को restarts के बाद layouts restore करने के लिए सुझाया गया है।
- zellij और अन्य custom terminal multiplexers जैसे alternatives का उल्लेख है; कुछ लोग HTML email और rich content को friction points बताते हैं।
- कुछ लोग newer window managers या integrated terminal solutions पर जाने के बाद tmux को पूरी तरह छोड़ देने की बात करते हैं।
Tiling window managers बनाम “tmux as OS”
- कई लोगों का तर्क है कि लेख वास्तव में एक tiling window manager का वर्णन कर रहा है, न कि OS बदलाव का।
- i3, sway, hyprland, Niri, EXWM, Ratpoison, विभिन्न twms, और इसी तरह के tools को पहले से ही layout और navigation की अधिकांश समस्याएँ हल करने वाला बताया गया है।
- macOS और Windows पर, yabai, Aerospace, OmniWM, Nehir, komorebi, और अन्य equivalents पर चर्चा होती है, जिनमें polish, stability, और complexity को लेकर mixed feedback है।
- कुछ लोग कहते हैं कि लेखक थोड़े से config से अपनी समस्याएँ खुद हल कर सकता था; दूसरे इस बात पर ज़ोर देते हैं कि config non-technical users और व्यापक adoption के लिए एक बाधा है।
Vertical tabs, trees, और task flows
- Arc के vertical tabs बहस छेड़ते हैं; कुछ लोग नाराज़ हैं कि साधारण vertical lists ट्रेंड बन गईं, जबकि पुराने tree-structured tab extensions task grouping के लिए ज़्यादा समृद्ध थे।
- nested/tab-tree models के लिए उत्साह है जो “task trees” से मेल खाते हैं (जैसे, पूरे HN-reading session को expand/collapse करना), हालांकि अब उनका समर्थन niche है।
Filesystem बनाम app silos
- इस विचार के खिलाफ़ ज़ोरदार प्रतिवाद है कि filesystems एक “weak abstraction” हैं।
- pro-filesystem टिप्पणियाँ portability, neutrality, और data तक पहुँच खोए बिना apps बदलने की क्षमता पर ज़ोर देती हैं।
- app-centric storage (Apple की Photos/Notes/iCloud शैली) को opaque और प्रबंधित करने या diff करने में कठिन बताया जाता है; दूसरे उत्तर देते हैं कि कई app internals (caches, DBs) का raw files के रूप में exposed न होना उचित है और sandboxing तथा cloud sync app databases की ओर धकेलते हैं।
- एक व्यापक “noun vs verb” framing भी दिखती है: data-centric filesystem model बनाम app-centric model, और यहाँ अधिकांश लोग पहले वाले के पक्ष में हैं।
Productivity, UX, और “normal users”
- कुछ लोग ज़ोर देते हैं कि UI स्वाद-आधारित “art” है, और Unix-like mix-and-match plus config files (संभवतः LLMs द्वारा generated) दीर्घकालिक जीत है।
- दूसरे तर्क देते हैं कि window और task management में मूलभूत दक्षता एक पेशेवर अपेक्षा होनी चाहिए; अव्यवस्थित desktops collaboration में सबका समय बर्बाद करते हैं।
- counterarguments बताते हैं कि सोच, design, और code quality ज़्यादा महत्वपूर्ण हैं, power-user speed से; window या typing की मामूली inefficiencies अक्सर अप्रासंगिक होती हैं।
LLMs और configuration
- कई टिप्पणियाँ सुझाव देती हैं कि स्थानीय या bundled LLMs का उपयोग window manager configs बनाने के लिए किया जाए या users को natural language में अपना ideal desktop बताने दिया जाए।
- skeptics वर्तमान LLM unreliability की ओर इशारा करते हैं और desktop experience की आधारशिला के रूप में उन पर निर्भर होने के खिलाफ़ चेतावनी देते हैं।