Longrid चेतावनी: आपको चेतावनी दी गई है, कई पत्र।

यह लंबे समय से उन अनुप्रयोगों के लिए एक वितरण प्रारूप विकसित कर रहा है जो सिस्टम-वाइड निर्भरताओं से "मुक्त" थे। उबंटू अपने स्नैप, गनोम - फ्लैटपैक को बढ़ावा देने में बहुत सक्रिय है। दोनों वादा और आरपीएम / बहस से स्वर्ग और स्वतंत्रता। आइए उस समस्या के बारे में विचार करें जिसे वे हल करना चाहते हैं, और इस समस्या के समाधान के लिए वे जिस मूल्य की मांग करते हैं।

पुस्तकालयों

आधुनिक दुनिया में कोई भी किसी और के कोड का उपयोग किए बिना एक आवेदन नहीं लिख सकता है। इसके कई कारण हैं:

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

कुंजी यह है कि भले ही हम किसी एकल पुस्तकालय की कार्यक्षमता को सिद्धांत से स्वयं लिख सकते हैं, लेकिन आवश्यक कार्यों की कुल संख्या (और निर्भरता) उन कार्यों की संख्या में लगभग घातीय वृद्धि देती है जिन्हें हल करने की आवश्यकता है, कार्यक्रम के कोड पर काम करने का प्रारंभ समय स्थगित करना अप्राप्य दूरी में।

नाटक के पैमाने को साकार करने के लिए एक उदाहरण: मान लीजिए कि आपका एप्लिकेशन वैकल्पिक तर्कों के रूप में इनपुट की दो लाइनें लेता है और सामान्यीकरण के बाद उन्हें प्रदर्शित करता है। यदि आप एक औद्योगिक अनुप्रयोग (एक आवेदन जो "वास्तविक" एक जैसा दिखता है) लिख रहे हैं, तो:

• आपको कमांड लाइन पार्सर की आवश्यकता है
• जिसे यूनिकोड को स्वीकार करना चाहिए
• और शायद उपयोगकर्ता को एक संकेत दें कि उसने तर्क नाम में सील कर दिया है
• क्या ध्वन्यात्मक तुलना की आवश्यकता है
• और शायद नियमित भाव
• सामान्य तौर पर, आपको न केवल यूनिकोड बल्कि अन्य स्थानों का भी समर्थन करना होगा, जिसके लिए एक स्थानीय समर्थन पुस्तकालय और सभी की आवश्यकता होती है जो लोग स्थानों के संदर्भ में आते हैं।
• सामान्यीकरण के साथ स्ट्रिंग संघनन एक अलग यूनिकोड लाइब्रेरी का एक और उपयोग है, आप स्वयं इसे लागू नहीं करते हैं।
• स्क्रीन पर प्रदर्शित (कमांड लाइन मदद, आपका परिणाम) नर्सों के लिए समर्थन की आवश्यकता होती है, एक पुस्तकालय जो विभिन्न टर्मिनलों का समर्थन करता है (आप पाठ मोड के साथ कर सकते हैं, लेकिन अनुप्रयोग अक्सर रंग क्षमताओं का उपयोग करते हैं)।
• टेस्ट में टेस्ट फ्रेमवर्क का उपयोग होता है, संभवतः मोक्स के लिए एक पुस्तकालय।

यह स्पष्ट है कि "दो-लाइन" कार्य के लिए इस तरह की एक कठिनाई सकल अतिरंजना है, लेकिन जैसे ही आप कुछ और करना शुरू करते हैं, "सब कुछ अपने आप से" का विचार नमूदार और एहसास की सीमा से परे जाना शुरू कर देता है।

आपको लगता है कि कर्ल http (s): // ... की गारंटी देने के लिए कितने पुस्तकालयों की आवश्यकता है? बहुत कुछ। आप एक का उपयोग करेंगे, लेकिन आपकी निर्भरता की निर्भरता आपकी निर्भरता है।

कॉपी और वेस्टिंग को वी.एस. डायनेमिक लिंकिंग

जबकि पुस्तकालयों का उपयोग अपरिहार्य है, उपयोग स्वयं कार्यान्वयन में भिन्न हो सकते हैं। कृपया ध्यान दें कि हमारे पास दो महत्वपूर्ण शब्द हैं: "उपयोग" और "उपयोग का कार्यान्वयन"। उपयोग का क्या मतलब है? अपने सबसे असभ्य रूप में - आवश्यक होने पर पुस्तकालय कोड को कॉल करने की क्षमता। और यहाँ इस के कार्यान्वयन हैं:

• हम उस कोड को कॉपी कर सकते हैं जो हमारे लिए आवश्यक संचालन करता है। कोड के एक टुकड़े के रूप में (कॉपी और पेस्ट), एक प्रोग्रामिंग भाषा में एक अलग मॉड्यूल के रूप में (संकलित भाषाओं के लिए ऑब्जेक्ट फ़ाइल), या एक अलग मॉड्यूल के रूप में (व्याख्या की गई भाषाओं के लिए)। इसके ठीक बगल में "आवेदन के साथ अपनी निर्देशिका में लाइब्रेरी के स्रोत फ़ाइल की प्रतिलिपि बनाएँ।" यह क्या समस्याएं पैदा करता है? मुख्य, मुख्य समस्या यह है कि हम मूल के साथ संबंध खो देते हैं (हमेशा के लिए)। यहां तक ​​कि अगर मूल पुस्तकालय का लेखक त्रुटि को ठीक करता है, तो हमें इसके बारे में पता नहीं होगा। इसके अलावा, अगर हम सिर्फ कोड की नकल करते हैं, तो प्रोग्राम पर काम करने वाला अगला व्यक्ति यह भी पता नहीं लगा पाएगा कि यह कोड "एलियन" है। वास्तव में, हमने "स्क्रैच से लिखें" प्रश्न में रास्ता काट दिया और किसी और को ले लिया। हालांकि, हम केवल एक टुकड़ा काटते हैं, क्योंकि यदि इस कोड में त्रुटियां हैं (लेकिन वे वहां नहीं होंगे , वे वहां हैं ), तो उनके सुधार के लिए समस्या को ठीक करने के लिए बहुत नीचे तक जाने और समझने की आवश्यकता होगी। यहां तक ​​कि अगर परीक्षण के लिए स्रोत कोड के कई सौ हजार लाइनों और सैकड़ों आरएफसी (साथ ही टिप्पणियों को लागू करना आवश्यक है कि आरएफसी से अलग हैं) पढ़ने के लिए, हमारे पास कोई दूसरा रास्ता नहीं है। इस जगह में मुख्य गलती यह है कि हमने यह जानकारी खो दी है कि यह कोड विदेशी है। किसी फ़ाइल में टिप्पणी करने से मदद मिल सकती है, लेकिन इसके लिए किसी व्यक्ति की सक्रिय और गहरी भागीदारी की आवश्यकता होती है, क्योंकि यदि हम "libfoobar, src / lib / foo.c संस्करण 364a51577f3782dbfe5d2482ab941980357c492" से ली गई टिप्पणी में लिखते हैं, तो किसी को यह देखने की आवश्यकता होगी कि कोई व्यक्ति कहां है? यह कौन सा संस्करण है और पिछले संस्करण से क्या बदल गया है। "इस प्रक्रिया को सरल बनाने के लिए, हमें मशीन-पठनीय मेटा-जानकारी की आवश्यकता है।
• यदि हम मेटा-सूचना के साथ "किसी और के कोड" के साथ और इस कोड को प्रबंधित करने के लिए कार्यक्रमों का उपयोग करते हैं (कॉपी-पेस्ट के बजाय), तो इसे वेंडिंग कहा जाता है, अर्थात आपके कोड में किसी अन्य व्यक्ति के कोड को नियंत्रित करना शामिल है। तकनीकी रूप से, वेंडिंग स्रोत स्रोत के चरण में, ऑब्जेक्ट्स को निष्पादन योग्य फ़ाइल से लिंक करने, एप्लिकेशन से मॉड्यूल (दुभाषियों में), या लाइब्रेरी के "आपके" संस्करण के साथ गतिशील लिंकिंग हो सकता है (इस पर बाद में अधिक)।
• अंत में, हम एप्लिकेशन लॉन्च स्टेज पर डायनामिक लिंकिंग कर सकते हैं। संकलित भाषाओं के लिए, ये साधारण सोहे हैं; व्याख्या की गई भाषाओं के लिए, सिस्टम-व्यापी आयात में एक मॉड्यूल है। यदि कई अनुप्रयोग इसे आयात कर सकते हैं, तो यह एक साझा पुस्तकालय है। यदि एप्लिकेशन "अपना मॉड्यूल लाया", तो लाइब्रेरी "अपना" है, भले ही इसका इंटरफ़ेस "साझा लाइब्रेरी" का अर्थ हो। उदाहरण के लिए, यदि कोई एप्लिकेशन अपने "अपने" संस्करण का उपयोग करता है, भले ही यह सामान्य एक से भिन्न हो या न हो, तो यह वेंडिंग है। और अगर सिस्टम आयात किया जाता है, तो यह एक साझा पुस्तकालय है।

इन तरीकों में क्या अंतर है? मैं संक्षेप में तर्क दूंगा; कई लेखों में उनकी चर्चा कई बार की गई। इनमें से प्रत्येक तर्क पड़ोसी प्रतिवादों की उपस्थिति के बावजूद मान्य है:

• तोह के लिए मेमोरी (रैम और डिस्क) को सहेजना, स्थापित सिस्टम के आकार को कम करना। जितने अधिक अनुप्रयोग एक ही का उपयोग करते हैं, उतनी अधिक मेमोरी बचत होती है। तदनुसार, इसके विपरीत, जितना अधिक "आपके" पुस्तकालय एक आवेदन लाता है, उतना ही "मोटा" होता है।
• कमजोरियों की निगरानी करने वाली बहस प्रणाली (पुस्तकालय अद्यतन प्रदान करना) या अनुप्रयोग के लेखक (इसे समय पर अद्यतन करना) है।
• निर्भरता के संघर्ष का समाधान (साझा पुस्तकालयों के बाद से इस समस्या को हल करना, इस प्रक्रिया में सभी प्रतिभागियों से ध्यान और सटीकता की आवश्यकता होती है, कभी-कभी दुर्गम कठिनाइयों का निर्माण होता है), वही प्रसिद्ध डीएल नरक।
• पुस्तकालयों के नए संस्करण - या तो वे आवेदन के लेखकों के अनुरोध पर दिखाई देते हैं, या वितरण के लेखकों के निर्णय से। एक मामले में, लेखक अपनी ज़रूरत की नई सुविधा ला सकता है, एक अन्य मामले में, वितरण पुस्तकालय में कुछ नया करने के लिए मौजूदा एप्लिकेशन में सुधार ला सकता है (उदाहरण के लिए, hidpi स्क्रीन qt या gtk पुस्तकालयों से जुड़े सभी अनुप्रयोगों में सही ढंग से काम करना शुरू कर देता है) ।

इन सभी मुद्दों पर पहले भी कई बार निपटा गया है। इसके बजाय, मैं "सभी मेरा" और "सभी सामान्य" वाटरशेड के सामाजिक पहलुओं पर ध्यान केंद्रित करना चाहता हूं।

सामाजिक अनुबंध और पावर मेंटेनर

साझा पुस्तकालय सहयोग, शक्ति और जिम्मेदारी हैं। जो लोग यह निर्धारित करते हैं कि कौन से साझा पुस्तकालय ऑपरेटिंग सिस्टम में उपलब्ध हैं वे सॉफ्टवेयर निर्माताओं को निर्देशित करते हैं कि वे किन पुस्तकालयों का उपयोग कर सकते हैं। बहुत सारे सॉफ़्टवेयर विभिन्न पुस्तकालयों का उपयोग कर सकते हैं, और संकेत का उपयोग करने के लिए सटीक संस्करण लिंकर (संकलित भाषाओं के लिए) या निर्भरता फ़ाइल हैंडलर (पाइप, बंडल, आदि) के विवेक पर छोड़ दिया गया है। यदि वितरण में सभी एप्लिकेशन समान आवश्यकताओं के साथ बनाए जाते हैं, तो अनुग्रह आता है: यदि किसी लाइब्रेरी में कोई त्रुटि है, तो इस लाइब्रेरी का अनुचर संस्करण को अपडेट करता है, और फिक्स स्वचालित रूप से सभी अनुप्रयोगों पर लागू होता है। यहां तक ​​कि अगर आवेदन हर दो साल में जारी किया जाता है, तो भी सशर्त ओपनसेल में फिक्स एक सप्ताह के भीतर लागू किया जाएगा। यदि किसी विशेष ओएस में पुराने प्रोटोकॉल को छोड़ने का निर्णय लिया जाता है, तो कुछ संशोधनों (उदाहरण के लिए, उपयोगकर्ता इंटरफ़ेस), तो ये परिवर्तन सभी के लिए भी लागू होंगे। सामान्य शैली में देखें और महसूस करें कि (हो सकता है) उपयोगकर्ता द्वारा एक बार और सभी के लिए बदला जा सके। क्या यह अनुग्रह नहीं है?

सत्ता और इसके लिए संघर्ष

... इस अनुग्रह के लिए आवश्यक है कि सभी एप्लिकेशन लाइब्रेरी के चयनित संस्करण के साथ काम कर सकें। लेकिन क्या होगा अगर कुछ एप्लिकेशन लाइब्रेरी से एक बहुत ही नया फ़ंक्शन चाहते हैं, और अन्य सभी एप्लिकेशन इसका उपयोग नहीं करना चाहते हैं, क्योंकि यह, उदाहरण के लिए, लाइब्रेरी का एलटीएस रिलीज नहीं है, अर्थात्। क्या यह पर्याप्त स्थिर नहीं है? लेकिन वितरण किट नए संस्करणों "सिद्धांत से बाहर" पर स्विच करने से इनकार कर सकती है, क्योंकि हमने उपयोगकर्ताओं को केवल बग फिक्स करने का वादा किया था, और नए संस्करण केवल ओएस के अगले संस्करण में, जो (पसंद) आधे साल में जारी किया जाएगा। और यह आवेदन के लेखकों से प्रतिरोध का कारण बनता है। आप मुझे यह बताने वाले हैं कि मुझे किन संस्करणों के साथ काम करना चाहिए? मैं एक लेखक हूं, मैं इसे इस तरह से देखता हूं। मुझे libfoobar 3.14-pre2 या अधिक पुराना चाहिए, न कि आपका प्राचीन सुस्त libfoobar 3.10।

... इस बिंदु पर, लेखक बस आवेदन आवश्यकताओं libfoobar>=3.14-pre2 । अनुरक्षक अनुरोध को लेता है और पैच करता है, साथ ही इस लाइब्रेरी पर निर्भर कोड को हटा देता है। हो सकता है कि। या बस इस तरह की निर्भरता के साथ एक नया संस्करण स्वीकार करने से इनकार करता है जब तक कि यह निर्भरता (libfoobar 3.16) वितरण के नए संस्करण में नहीं है।

यदि लेखक को वास्तव में नए संस्करण का उपयोग करने के लिए उपयोगकर्ताओं की आवश्यकता है (उदाहरण के लिए, क्योंकि लेखक पुराने संस्करण का समर्थन नहीं करना चाहता है), तो वह उपयोगकर्ता को एप्लिकेशन भेजने के लिए वर्कअराउंड की तलाश करता है।

एक ही बात तब होती है जब कई वितरण होते हैं, कुछ नए, कुछ पुराने। पुराने वितरण को बनाए रखना, विभिन्न पुस्तकालयों के साथ परीक्षण करना मुश्किल है। तो विकल्प "आपके पुस्तकालयों के साथ जहाज" लगभग तुरंत दिखाई देता है।

सामुदायिक त्रासदी

यह एक सामुदायिक त्रासदी के उद्भव के लिए आवश्यक शर्तें बनाता है:

• प्रत्येक निर्माता (सॉफ्टवेयर लेखक) अपनी आवश्यकतानुसार जहाज करना चाहता है। अन्य लोगों के नियमों (संस्करणों) को अपनाना समय और प्रयास की बर्बादी है, दुनिया में कई अलग-अलग वितरण हैं।
• उपयोगकर्ता नए संस्करण चाहते हैं।

इसी समय, अधिक एप्लिकेशन अपने पुस्तकालयों के साथ आते हैं, सिस्टम लाइब्रेरी का उपयोग कम है। अनुग्रह याद है? कम यह "सार्वभौमिक" है, कम अनुग्रह है। यदि साझा लाइब्रेरी का उपयोग 995 में से 5 विभिन्न अनुप्रयोगों द्वारा किया जाता है, तो इस लाइब्रेरी का लाभ 0.5% है। यह शर्म की बात है, हाँ। इसके अलावा, यह सभी उपयोगकर्ताओं को नुकसान पहुंचाता है, यहां तक ​​कि जो लोग, सिद्धांत रूप में, एक नई सुविधा की तीव्र आवश्यकता नहीं है - लेकिन यदि आवेदन केवल एक वेंडिंग फॉर्म में उपलब्ध है, तो उपयोगकर्ता के पास कोई विकल्प नहीं है।

यह पता चला है कि हमारे पास एक वैश्विक चरम सीमा है: सभी अनुप्रयोग केवल साझा पुस्तकालयों का उपयोग करते हैं (अधिकतम सामान्य अनुग्रह, व्यक्तिगत अनुप्रयोगों के लेखकों के लिए असुविधा) या "प्रत्येक के द्वारा" (आवेदनों की एक गुच्छा के साथ एक मोटा वितरण जो कि अवांछनीय लेकिन व्यापक रूप से उपयोग की जाने वाली क्षमताएं हो सकती हैं) स्मृति का एक गुच्छा खाने, लेकिन प्रत्येक आवेदन के लेखक सुविधाजनक है)।

यह वह जगह है जहां हम आरपीएम / डिबेट वीएस स्नैप / फ्लैटपैक विवाद पर आते हैं

आजादी या गुलामी?

Ubuntu बहुत, बहुत दृढ़ता से Snap'y की वकालत करता है। गनोम को भरोसा है कि भविष्य फ्लैटपैक में है। उनमें से प्रत्येक गहरी व्यक्तिवादी अनुप्रयोगों के लिए एक रूपरेखा है। सभी प्रकार के इलेक्ट्रॉनों, जिनके पास न केवल इंजन कम्पार्टमेंट हुड है, बल्कि इंजन कम्पार्टमेंट ऑपरेटिंग सिस्टम भी है। खुद का libc, खुद का libssl, खुद का regexp, खुद ncurses, आदि। केवल कोर सामान्य के रूप में कार्य करता है, अर्थात वास्तव में, यह एक ही कंटेनरीकृत अनुप्रयोग है, लेकिन डेस्कटॉप के लिए। प्रत्येक अपने स्वयं के कोर दें, और आपको एक आभासी मशीन के रूप में उपकरण मिलता है। मेटाडेटा जोड़ें - और आपको डॉकटर कंटेनर मिलता है।

अनुप्रयोगों (एप्लिकेशन लेखकों) का व्यक्तिवाद समझ में आता है, लेकिन फिर आम अच्छे के लिए कौन खड़ा है? एक प्रमुख स्थानीय सुधार एक मामूली सामान्य वितरण गिरावट है जो विशुद्ध रूप से अनुप्रयोगों द्वारा गुणा किया जाता है। यदि हर कोई अपने लिए स्थानीय सुधार करता है, तो हानि की मात्रा सुधार की राशि के लाभ से अधिक हो जाती है।

ऐसा लगता है कि इस स्थान पर वितरण के रचनाकारों को सामान्य हित के संरक्षक के रूप में कार्य करना चाहिए। हालांकि ...

नीति

उबंटू डिबियन पर निर्भर करता है जो कि कैनोनिकल (उबंटू कंपनी) से बहुत अधिक है। उबंटू का मूल्य उबंटू अनुरक्षकों के प्रयासों में नहीं है, लेकिन डेबियन से आने वाले एक विशाल सॉफ़्टवेयर रिपॉजिटरी में, जहां सभी एप्लिकेशन एक साथ काम करते हैं, जो व्यक्तिगत पैकेज के हजारों अनुचर के प्रयासों के माध्यम से एक साथ काम करते हैं जो कि डेबियन वितरण के मालिक हैं। परिणाम को चमकाने के अपने प्रयासों के लिए कैनोनिकल इसके शीर्ष पर जोड़ता है - और इसके लिए इसे कुछ से प्यार है। थोड़ा विपणन और एक निश्चित जीवनचक्र जोड़ें, जो उद्यम को पसंद करता है, और हमें एक महान उत्पाद मिलता है।

... जो हजारों स्वयंसेवकों की इच्छा पर निर्भर करता है।

जो लगभग किसी भी व्यावसायिक कंपनी के अनुकूल नहीं है। इस लत को कैसे तोड़ें? अपने खुद के ऐप बंडल बनाकर यह सही है। जितने अधिक एप्लिकेशन होंगे, अपस्ट्रीम में कम अपडाउन से कंपनी को नुकसान होगा। यह कहानी को याद करने के लिए पर्याप्त है जब सिस्टमड पर डेबियन में एक वोट ने अपस्टार्ट को दफन कर दिया, जिसे कैनोनिकल ने विकसित किया।

लेकिन हजारों अनुप्रयोगों में से कई को बनाए रखें, जिनमें से कुछ अपने स्वयं के स्थान हैं (erlang, go, perl, python, R, julia, आदि), और कुछ इसी विषय क्षेत्र में राक्षस हैं (ब्राउज़र, emacs, टेक्स, पेसमेकर, आदि) - ये हैं भारी काम। कोई आश्चर्य नहीं कि ये हजारों रखवाले हैं।

... और एक विचार है। और, चलो, आवेदन लेखक खुद ही आवेदन बनाए रखते हैं। सभी को एक सैंडबॉक्स दें, उन्हें खुदाई करने दें। लेखकों को स्वतंत्रता, कैनोनिकल - एप्लिकेशन प्राप्त होते हैं जो डेबियन पर निर्भर नहीं होते हैं और जो कम से कम किसी को मुफ्त में बनाए रखता है। उपयोगकर्ताओं को मिलता है ...

... ऐसे अनुप्रयोग जो मोटे होते हैं, भारी होते हैं, जिनके अपडेट अनियमित होते हैं और जो आसानी से वर्षों तक कमजोरियों को दूर रख सकते हैं ... लेकिन उनमें से कुछ चमकदार नए हैं।

तो आगे क्या है?

एक ऐसी दुनिया की कल्पना करें जिसमें हर कोई अपने साथ सब कुछ ले जाए ... क्या आप जानते हैं कि यह कैसा दिखता है? रसोइये पर एक नज़र डालें। वह अपने पोस्टग्रैसिकल (अपनी निर्भरता के साथ), अपने खरगोश (जो कि उसके इरांग पर निर्भर करता है) के साथ जहाज करता है, साथ ही शेफ-सर्वर भी एरलांग पर होता है, इसलिए उसके पास खुद का इर्लंग भी होता है। अचानक, हमारे पास दो erlangs हैं और एक ही एप्लिकेशन के अंदर एक ही लाइब्रेरी की दर्जनों प्रतियां, संस्करण में थोड़ी भिन्न हैं। यह अंतिम विकल्प नहीं है, जैसा कि अंदर, घटकों के बीच अभी भी आम पुस्तकालय हैं। यदि हम उन्हें और अधिक काटते हैं, तो हमें एक आवेदन के लिए ओपनसेल और एफबीआईसी की कई दर्जन प्रतियां प्राप्त होती हैं। अपने अंतिम रूप में भी नहीं, यह प्रति एप्लिकेशन 600MB जैसा दिखता है।

... जो, ज़ाहिर है, औसत इलेक्ट्रॉन अनुप्रयोग की तुलना में बहुत बड़ा है। ... और पूरे मारीडब सर्वर (पूरे डीबीएमएस!), या क्रिटा या जिम्प (विशाल ग्राफिक्स अनुप्रयोगों) की तुलना में 12 गुना अधिक है।

और अगर हर कोई ऐसा ही होगा? मेरे पास अपने कंप्यूटर पर 2000 पैकेज स्थापित हैं (गिनती -देव और लिबास नहीं) ... 2000 * 300 = 600GB (परिणाम के औसत आकार के लिए, मैंने रसोइयेस्क से आधा लिया, क्योंकि हर कोई निर्भरता से इतना भयानक नहीं है)। अब वे लगभग 7 जीबी पर कब्जा कर लेते हैं (संसाधनों में, जैसे कि प्रलेखन, बनावट संपादक, सीएडी टेम्पलेट आदि)।

यदि यह 600GB में बदल जाता है, तो क्या यह समुदायों की शुद्ध त्रासदी नहीं है? प्रत्येक क्षण में, हम स्थानीय अनुकूलन (और किसी और की असुविधा का समाधान) का पालन करते हैं, लेकिन साथ में, इन स्थानीय अनुकूलन का योग प्रणाली की समग्र इष्टतमता को कम करता है। मेरी राय में, प्रतिभागियों में से प्रत्येक के स्थानीय लाभ से अधिक।

मुझे समझ में आता है कि क्यों कैनोनिकल ने स्नैप को धक्का दिया। मैं इसे समझता हूं, और मंजूर नहीं करता।