लीन सॉफ़्टवेयर के लिए 2024 की अपील

सरल/स्व-होस्टेड बनाम उपयोगकर्ता‑अनुकूल सेवाएँ

• कई टिप्पणियों में कहा गया कि आप बेहद लीन टूल बना सकते हैं (जैसे वेब सर्वर + SSH/FTP/NFS + छोटे स्क्रिप्ट्स के ज़रिए बुनियादी इमेज/पेस्ट साझा करना)।
• अन्य लोग इसका प्रतिवाद करते हैं कि गैर‑तकनीकी उपयोगकर्ता लगभग पूरी तरह ब्राउज़र में रहते हैं; उनसे FTP/SFTP या माउंट्स सीखने को कहना एक वास्तविक बाधा है।
• स्व-होस्टेड परिवार/दोस्तों के लिए, कुछ का तर्क है कि आप कस्टम अपलोड फ्रंटएंड बनाने के बजाय FileZilla, SFTP फ़ाइलसिस्टम, या सिंक टूल्स जैसी चीज़ें बस सिखा या पहले से इंस्टॉल कर सकते हैं।

इमेज-शेयरिंग उदाहरण, प्रदर्शन, और गोपनीयता

• कुछ लोग लेख के डेमो ऐप की आलोचना करते हैं कि वह इमेजों का आकार कम या अनुकूलित नहीं करता और पूर्ण-आकार के थंबनेल परोसता है, इसे “गलत चीज़ का अनुकूलन” कहते हुए (बाइनरी आकार बनाम बैंडविड्थ)।
• EXIF पर बहस: एक पक्ष कहता है कि मेटाडेटा न हटाना कई संदर्भों में गंभीर गोपनीयता/सुरक्षा जोखिम है; दूसरे कहते हैं कि यह अधिकतर उपयोगकर्ता की ज़िम्मेदारी है या निजी साझा करने के लिए एक फीचर हो सकता है।
• इस पर असहमति है कि क्या इससे लेख “पाखंडी” बन जाता है या बस “अधूरा”।

प्रोत्साहन और फुलाव के कारण

• कई टिप्पणियाँ संगठनात्मक प्रोत्साहनों को दोष देती हैं: तेज़ी से शिप करना प्रमोशन दिलाता है; सावधानीपूर्वक, लीन इंजीनियरिंग “अनुत्पादक” दिखती है।
• फुलाव सुरक्षा/पोर्टेबिलिटी के निर्णयों से भी आता है: हर चीज़ (ड्राइवर, रनटाइम, डिबग मैप्स) को साथ भेजना हर प्लेटफ़ॉर्म के लिए अलग-अलग काट-छाँट करने से आसान है।
• कुछ का कहना है कि क्षमताएँ बढ़ने के साथ फुलाव अपरिहार्य है; अन्य मानते हैं कि यह अधिकतर डेवलपर संस्कृति और प्राथमिकताओं का परिणाम है।

Electron, वेब स्टैक, और GUI टूलकिट्स

• कई लोग Electron और “web in a box” को फुलाव का प्रतीक मानते हैं (छोटे ऐप्स के लिए विशाल डाउनलोड, उच्च RAM/CPU उपयोग)।
• समर्थकों का कहना है कि Electron क्रॉस-प्लेटफ़ॉर्म डेवलपमेंट लागत को बहुत घटाता है, उपलब्ध वेब डेवलपर्स का लाभ उठाता है, और UI इटरेशन को तेज़ करता है।
• उल्लेखित विकल्प: Qt, JavaFX, Avalonia, Tauri, Slint, तथा Telegram जैसे नेटिव “हेवीवेट” ऐप्स। समझौतों में लाइसेंसिंग (Qt), टूलिंग की परिपक्वता, और भर्ती की कठिनाई शामिल हैं।
• कुछ लोग सोचते हैं कि Electron के बिना कई डेस्कटॉप ऐप्स (विशेषकर Linux पर) शायद मौजूद ही न होते; अन्य कहते हैं कि नेटिव स्टैक्स पूरी तरह व्यवहार्य हैं।

लाइब्रेरीज़, पैकेजिंग, और साझा बनाम स्थिर

• Mesa के आकार और आवश्यक जटिलता बनाम अत्यधिक शिपिंग के बीच “रेखा कहाँ खींचें” इस पर चर्चा।
• साझा लाइब्रेरीज़ के पक्ष में तर्क (केंद्रीकृत, डिस्क/RAM पर अधिक लीन) बनाम स्थिर बाइनरीज़ (सरल डिप्लॉयमेंट, कम छिपी निर्भरताएँ)।
• पैकेज मैनेजर वास्तविक जटिलता छिपा सकते हैं: apt install से यह पता नहीं चलता कि आप पूरा ब्राउज़र इंजन ले रहे हैं या एक छोटा स्थिर बाइनरी।

क्या सॉफ़्टवेयर की गुणवत्ता बिगड़ रही है?

• एक पक्ष कहता है कि आधुनिक ऐप्स (खासकर Electron) स्पष्ट रूप से बदतर हैं: साधारण टूल्स का सैकड़ों MB RAM/CPU उपयोग करना और पुराने नेटिव UI की तुलना में खराब UX पैटर्न।
• दूसरा पक्ष कहता है कि अतीत का सॉफ़्टवेयर (जैसे 90 के दशक का डेस्कटॉप) भी कुख्यात रूप से बग्गी और असुरक्षित था; नॉस्टैल्जिया पूर्वाग्रह हो सकता है।
• अधिक सूक्ष्म दृष्टिकोण: लगभग 2003–2013 के बीच एक “स्वर्ण काल” था जिसमें मज़बूत नेटिव टूलकिट्स और बेहतर इंजीनियरिंग प्रथाएँ थीं, जिसके बाद वेब/मोबाइल क्रॉस-प्लेटफ़ॉर्म दबावों ने गिरावट लाई।

फुलाव बनाम लीननेस के उदाहरण

• रिपोर्टेड फुलाव:
  • Notion Calendar ~84 MB.
  • Firefox as a Snap प्रति संस्करण सैकड़ों MB खपत करता हुआ।
  • ClickHouse “client” बाइनरी ~900 MB क्योंकि इसमें server/tools शामिल हैं।
  • QGIS Windows इंस्टॉलर लगभग 1 GB और बढ़ते हुए।
• लीनर प्रतिउदाहरण:
  • पुराना Ventrilo client कुछ MB और न्यूनतम RAM में।
  • कुछ Qt/JavaFX डेस्कटॉप ऐप्स सावधानी से ~30–140 MB और दर्जनों MB RAM तक सीमित रखे गए।
  • एक टूल को अनावश्यक हिस्से हटाकर 33 MB से 1.4 MB तक घटाया गया (विवरण पूरी तरह नहीं दिए गए)।

नियमन, सप्लाई चेन, और APIs

• नए सुरक्षा कानून और दीर्घकालिक अपडेट दायित्व कुछ संगठनों को निर्भरता-प्रसार पर पुनर्विचार करने के लिए पहले ही प्रेरित कर रहे हैं।
• कुछ लोग बेहतर टूलिंग और विशाल डिपेंडेंसी ग्राफ़ पर तर्क करने के लिए हल्के formal methods का सुझाव देते हैं, बजाय इसके कि फुलाव के गायब हो जाने की उम्मीद की जाए।
• अन्य लोग खुले APIs की वकालत करते हैं ताकि उपयोगकर्ता आधिकारिक फूले हुए क्लाइंट्स के बजाय लीन वैकल्पिक क्लाइंट चुन सकें।

ऑपरेटिंग सिस्टम और सुरक्षा मॉडल

• चर्चा की एक धारा OS सुरक्षा मॉडलों को दोष देती है: पुराने सिस्टम (जैसे फ्लॉपी-आधारित सेटअप) सरल capability सीमाएँ परोक्ष रूप से लागू करते थे, जबकि आधुनिक OS व्यापक पहुँच के साथ मनचाहा कोड चलाने देते हैं, जिससे आज की विशाल निर्भरता-श्रृंखलाएँ अधिक खतरनाक हो जाती हैं।