Show HN: Shitty – तेज़ टर्मिनल। मेमोरी-unsafe और आपकी टर्मिनल से तेज़
“shitty” नाम का एक नया open-source terminal emulator Ghostty, Kitty, और GNOME Terminal जैसे लोकप्रिय टूल्स की तुलना में काफी अधिक text rendering throughput का दावा करता है, जिससे यह बहस छिड़ जाती है कि क्या ऐसे performance gains रोज़मर्रा के उपयोग में सचमुच मायने रखते हैं। टिप्पणीकार throughput की तुलना अधिक दिखाई देने वाले कारकों जैसे startup time, resize behavior, और keypress latency से करते हैं, और कई लोग कहते हैं कि उनके लिए टर्मिनल कभी bottleneck नहीं रहा। प्रोजेक्ट का उकसाने वाला नाम, AI-generated code का भारी उपयोग, और GPL-आधारित codebase से MIT licensing की योजना professionalism, licensing ethics, और long-term maintainability पर व्यापक बहस छेड़ती है।
प्रोजेक्ट और प्रदर्शन संबंधी दावे
- अधिकतम थ्रूपुट पर केंद्रित नया क्रॉस-प्लैटफ़ॉर्म टर्मिनल एमुलेटर, जो C++ में लिखा गया है (स्पष्ट रूप से “memory-unsafe,” यानी Rust नहीं)।
- बेंचमार्क Ghostty, kitty, alacritty, GNOME Terminal आदि जैसे लोकप्रिय टर्मिनलों की तुलना में काफी अधिक ASCII थ्रूपुट दिखाते हैं।
stनाम का दो-अक्षरीय बाइनरी नाम उपयोग करता है, जो पहले से मौजूद एक टर्मिनल के साथ ओवरलैप करता है और टकराव की चिंताएँ उठाता है।
व्यावहारिक मूल्य बनाम अत्यधिक अनुकूलन
- कई टिप्पणीकार कहते हैं कि उन्हें शायद ही कभी टर्मिनल प्रदर्शन से सीमित महसूस होता है और वे इसके बजाय फीचर्स, इंटीग्रेशन, और स्थिरता को प्राथमिकता देते हैं।
- कई लोगों का तर्क है कि उच्च थ्रूपुट से जीवनभर की समय-बचत, टर्मिनल बदलने की लागत की तुलना में बहुत छोटी है।
- अन्य लोग ध्यान दिलाते हैं कि अत्यधिक chatty आउटपुट वाले वर्कलोड—जैसे build logs, debug dumps, या गलती से बहुत बड़ी फ़ाइलों को
catकरना—टर्मिनल थ्रूपुट से वास्तविक रूप से सीमित हो सकते हैं।
स्टार्टअप समय और लेटेंसी
- कई उपयोगकर्ता कच्चे थ्रूपुट से अधिक स्टार्टअप समय और कीप्रेस-से-स्क्रीन लेटेंसी की परवाह करते हैं।
- कुछ लोग xfce4-terminal, foot, xterm, kitty (single-instance के साथ) से लगभग त्वरित स्टार्टअप की रिपोर्ट करते हैं, जबकि Ghostty को कुछ सिस्टमों पर धीमा बताया गया है।
- लेखक बहुत सूक्ष्म damage tracking और न्यूनतम redraw कार्य का दावा करता है, और कार्यान्वयन के आधार पर best-in-class latency का दावा करता है, लेकिन कोई ठोस latency मापन नहीं है, और इस “provably minimal work” दावे पर सवाल उठाए जाते हैं।
नामकरण और अपनापन
- “shitty” नाम ध्रुवीकरण करने वाला है: कुछ इसे चतुर और यादगार मानते हैं; अन्य इसे बचकाना और corporate adoption में बाधा मानते हैं।
- इस पर बहस कि टूल नामों में अपशब्दों से बचना कितना मायने रखता है; कुछ कहते हैं कि वे ऐसी जगह काम नहीं करेंगे जहाँ यह समस्या हो, जबकि अन्य पेशेवरपन पर जोर देते हैं।
- दो-अक्षरीय command naming की भी अनावश्यक और टकरावपूर्ण होने के लिए आलोचना की जाती है।
AI-जनित कोड और गुणवत्ता
- कोड का बड़ा हिस्सा (tests सहित) LLMs द्वारा जनरेट किया गया है, जिसमें मानव समीक्षा, sanitizers (ASan/UBSan), fuzzing, और coverage tracking शामिल हैं।
- कुछ लोग इसे अत्यंत पेशेवर, test-driven दृष्टिकोण मानते हैं; अन्य इस दावे पर सवाल उठाते हैं कि यह प्रोजेक्ट को “top 0.1%” में रखता है और संदेह करते हैं कि AI आउटपुट की कितनी गहराई से ऑडिटिंग हुई है।
लाइसेंसिंग और GPL संबंधी चिंताएँ
- प्रोजेक्ट GPL-लाइसेंस वाले आधार से शुरू हुआ और dual-licensing rewrite प्रक्रिया के माध्यम से MIT-only codebase में जाने का लक्ष्य रखता है।
- आलोचक तर्क देते हैं कि यह कानूनी या नैतिक रूप से संदिग्ध है और काम अभी भी GPL-derived है; लेखक कानूनी सलाह का हवाला देते हुए जोर देता है कि प्रक्रिया वैध है।
- copyleft बनाम permissive licenses पर व्यापक बहस उठती है: क्या derivatives को खुला रहने के लिए मजबूर करना community reciprocity की रक्षा करता है या developer freedom को सीमित करता है।
फीचर्स, प्रोटोकॉल, और आर्किटेक्चर
- वर्तमान में आधुनिक graphics और keyboard protocols का समर्थन नहीं है (जैसे sixel, kitty graphics/keyboard); कुछ लोग तर्क देते हैं कि इससे इसे “modern” टर्मिनलों से तुलना करना अधूरा हो जाता है।
- टर्मिनल आउटपुट parser को एक बड़े Ragel-generated finite-state machine के रूप में लागू किया गया है, जिसे elegant और performant दृष्टिकोण के रूप में सराहा गया है।
- आर्किटेक्चर कथित रूप से parsing, terminal state machine, और rendering को साफ़-सुथरे ढंग से अलग करता है, जिससे भविष्य में library-style reuse संभव हो सकता है, हालांकि अभी “libterminal” API की योजना नहीं है।