संकलित प्रारूप में कार्यक्रम क्यों नहीं वितरित किए जाते हैं?

Question

लेकिन वे जैसे निर्देश देते हैं

cd downloaded_program
./configure
make install

यह आवश्यक है कि ELF बनाता है, और शायद कुछ .so फाइलें।

उन लोगों को डाउनलोड करने के लिए ज़िप फ़ाइल के अंदर क्यों नहीं रखा जाए, जैसे कि विंडोज़ ऐप्स के साथ? क्या कोई कारण है कि उन्हें उपयोगकर्ता द्वारा संकलित करने की आवश्यकता है?

Comments

स्रोत कोड कैसे वितरित किया जाता है। आपने इसे ubuntu के साथ टैग किया - क्या आपने aptसामान की कोशिश की है?

— mikeserv

उबंटू: 40,000 सबसे आम कार्यक्रम $ sudo apt-get install [name]:। अधिक दुर्लभ सॉफ्टवेयर: कुछ स्रोत से बनाया जाना चाहिए {cmake .. && make, .configure && make, waf, scons, आदि ~ 10 बिल्ड विकल्प}।

— नूड लार्सन

आपके पास तीन विंडोज © संस्करण हैं, और ~ 100 "लिनक्स ओएस" संस्करण हैं। (40,000) सबसे आम कार्यक्रमों से अधिक बनाए रखने और संग्रहीत करने के लिए असंभव।

— नूड लार्सन

यह सवाल सिर्फ गलत है। सबसे सॉफ्टवेयर में द्विपदीय प्रारूप में वितरित किया जाता है, आम तौर पर .rpmया .debया .tgzसंकुल। स्रोत उन लोगों के लिए भी वितरित किया जाता है जो इसे स्वयं संकलित करना चाहते हैं या इसकी जांच करते हैं या इसे संशोधित करते हैं, या इसे एक या अधिक विकृतियों के लिए पैकेज करते हैं। कोई भी .ziplinux पर बायनेरिज़ को वितरित करने के लिए उपयोग नहीं करता है क्योंकि .zip फाइलें आवश्यक जानकारी का समर्थन नहीं करती हैं जैसे कि उपयोगकर्ता, समूह, और उनके पास मौजूद फ़ाइलों के लिए अनुमति।

— कैस

मुझे अभी तक किसी भी लिनक्स प्रोग्राम को संकलित करने की आवश्यकता नहीं है जिसे मैं चलाना चाहता हूं। एक्ज़ीक्यूटेबल्स हमेशा उपलब्ध रहे हैं ... अब तक।

— user2338816

Answer 1

आइए कारकों का विश्लेषण करें ...

विश्लेषण :

परिभाषाएँ प्लैटफ़ॉर्म के अनुसार हो रही हैं: कुछ ऐसे मुद्दे हैं जो एक ऐसे वातावरण में उत्पन्न होते हैं जहाँ डेवलपर्स एक एप्लिकेशन के कई आर्किटेक्चर-विशिष्ट वेरिएंट बना रहे हैं और बनाए रख रहे हैं:

• अलग-अलग वेरिएंट के लिए अलग-अलग स्रोत कोड की आवश्यकता होती है - अलग-अलग UNIX- आधारित ऑपरेटिंग सिस्टम एक ही कार्य (उदाहरण के लिए, strchr (3) बनाम इंडेक्स (3)) को लागू करने के लिए विभिन्न कार्यों का उपयोग कर सकते हैं। इसी तरह, विभिन्न वेरिएंट (उदाहरण के लिए, string.h बनाम strings.h) के लिए विभिन्न हेडर फ़ाइलों को शामिल करना आवश्यक हो सकता है।

• अलग-अलग वेरिएंट के लिए अलग-अलग बिल्ड प्रक्रिया की आवश्यकता होती है - अलग-अलग प्लेटफॉर्म के लिए बिल्ड प्रक्रिया अलग-अलग होती है। अंतर में संकलक स्थानों, संकलक विकल्पों और पुस्तकालयों के रूप में ऐसे विवरण शामिल हो सकते हैं।

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

• हर ऑपरेटिंग सिस्टम की अपनी लिंकिंग मैनेजमेंट स्कीम होती है और इसे जरूरत पड़ने पर ELF (एक्जिक्यूटेबल और लिंकिंग फॉर्मेट) फाइल तैयार करनी चाहिए।

• कंपाइलर एक ऐसा निर्माण करेगा जो निर्देशों का एक अनुक्रम होगा , और अलग-अलग आर्किटेक्चर का मतलब अलग-अलग निर्देश सेट ( इंस्ट्रक्शन सेट आर्किटेक्चर की तुलना ) है। इसलिए, प्रत्येक आर्किटेक्चर के लिए कंपाइलर का आउटपुट अलग है (उदाहरण: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola का 6800, MOS T 6502, और इतने सारे अन्य )

सुरक्षा :

• यदि आप एक बाइनरी डाउनलोड करते हैं, तो आप यह सुनिश्चित नहीं कर सकते हैं कि यह वही करता है जो यह कहता है, लेकिन आप स्रोत कोड का ऑडिट करने और अपने सिस्टम में एक स्व संकलित बाइनरी का उपयोग करने का प्रयास कर सकते हैं। इसके बावजूद, उपयोगकर्ता Techmag ने अपनी टिप्पणी में एक अच्छी बात की, कोड का ऑडिट करने के लिए कोड का आकलन करने के लिए जानकार और सक्षम कोडर्स की आवश्यकता होती है और यह सुरक्षा की गारंटी नहीं है।

बाजार : इस खंड में बहुत सारे कारक हैं, लेकिन मैं इसे फिर से शुरू करने की कोशिश करूंगा:

• प्रत्येक कंपनी का लक्ष्य सभी प्लेटफार्मों तक पहुंचने का नहीं है, यह बाजार और प्लेटफार्मों की लोकप्रियता पर निर्भर करता है और वे क्या बेचना चाहते हैं।

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

निष्कर्ष :

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

Comments

मुझे लगता है कि प्रोसेसर मॉडल अंतर के बारे में थोड़ा और स्पष्ट होने से यह उत्तर बेहतर होगा - और कैसे ~ 10 साल पहले, प्रत्येक यूनिक्स संस्करण मूल रूप से अपना था। लिनक्स आज तक व्याप्त प्रभाव नहीं था।

— Sobrique

@ शोब्रिक: या यहां तक ​​कि प्रोसेसर मॉडल के अंतर का भी उल्लेख करें - 10 साल पहले हमारे पास आज के समय में 2 से अधिक प्रकार हैं और लिनक्स लगभग उन सभी पर चलता है (मैं खुद लिनक्स को पावरपीसी पर चलाता था)। यह अभी भी x86, AMD64 (अन्यथा x86-64 के रूप में जाना जाता है) और एआरएम के साथ आंशिक रूप से आज भी प्रासंगिक है। MIPS आज भी उन लोगों के बीच काफी लोकप्रिय है जो अपने स्वयं के चिप्स का निर्माण कर सकते हैं क्योंकि यह अब तक पूरी तरह से पेटेंट मुक्त है।

— स्लीवेटमैन

विलंब के लिए क्षमा चाहते हैं! तुम दोनों को धन्यवाद! मैंने cpu आर्किटेक्चर में कुछ संदर्भ जोड़े, मैंने एक तुलना सूची में एक लिंक भी जोड़ा। मैं नहीं चाहता कि जवाब इतना बड़ा हो। लेकिन हाँ, यह बहुत प्रासंगिक है!

— फेसुंडो विक्टर

सुरक्षा टिप्पणी का तात्पर्य है कि पाठक / इंस्टॉलर जानता है कि कोड को कैसे पढ़ना और समझना है। यह देखते हुए कि शेलशॉक भेद्यता दशकों तक जीवित रही, मैंने देखा कि मैं सम्मानपूर्वक सुझाव दूंगा कि यह एक गलत धारणा है। यह पता करने योग्य और सक्षम कोडर्स को हां कोड करने के लिए अनुमति देता है, लेकिन यह विज्ञापित के रूप में एक वास्तविक सुरक्षा निवारक नहीं है। इसका वास्तव में विपरीत प्रभाव हो सकता है। राज्य और संगठित अपराध वित्त पोषित हैकर्स संभवत: अगले

— शेलशॉक के

तुम सही हो! मैंने उस उत्तर को प्रतिबिंबित करने के लिए संशोधित किया। मैंने उत्तर के मुख्य उद्देश्य पर ध्यान न देने की कोशिश की। धन्यवाद टेकमग!

— फेसुंडो विक्टर

Answer 2

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

स्रोत कोड के रूप में सॉफ्टवेयर का वितरण भी स्वतंत्र सत्यापन की अनुमति देता है कि सॉफ्टवेयर वह करता है जो वह दावा करता है और इसके बजाय या साथ ही कुछ बुरा नहीं करता है - जो कि निर्माता में विश्वास के स्तर को कम करने के बावजूद, वास्तव में इसे बढ़ाता है!

Answer 3

पहला, आपका प्रश्न एक त्रुटिपूर्ण आधार पर आधारित है। कार्यक्रमों को संकलित प्रारूप में वितरित किया जाता है!

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

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

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

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

Answer 4

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

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

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

Comments

यही कारण है कि आप शायद "64 बिट" विंडोज़ ओएस पर कई अन्य कार्यक्रमों की तरह 32 बिट फ़ायरफ़ॉक्स चला रहे हैं, जबकि 64 बिट लिनक्स आमतौर पर 64 बिट एप्लिकेशन चलाता है।

— mchid

Answer 5

स्रोत के रूप में वितरण का मूल कारण निश्चित रूप से मंच विविधता था; लिनक्स समुदाय ने उस कार्यप्रणाली को दोनों के लिए और नए, आंशिक रूप से राजनीतिक कारणों से जारी रखा है।

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

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

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

Answer 6

कई मामलों में (कम से कम * निक्स दुनिया में), स्रोत कोड सॉफ्टवेयर का सबसे पोर्टेबल संस्करण है। स्रोत होने की गारंटी देता है कि साझा किया गया सॉफ़्टवेयर हर प्लेटफ़ॉर्म पर काम करेगा जो संभवतः इसका समर्थन कर सकता है (जो कि कई मामलों में बस पॉसिक्स-अनुपालन का मतलब है)। बायनेरिज़ जारी करना केवल प्लेटफ़ॉर्म (सॉफ़्टवेयर और हार्डवेयर दोनों) के साथ संगतता की गारंटी देता है जो उन बायनेरिज़ के लिए जारी किए जाते हैं।

विचार करें कि विंडोज़ पर, सॉफ्टवेयर साझा करने के लिए बायनेरिज़ सबसे सुविधाजनक और पोर्टेबल रूप हैं। चूंकि संकलन स्रोत सामान्य विंडोज़ सॉफ़्टवेयर वितरण मॉडल का हिस्सा नहीं है, इसलिए Microsoft अपने ओएस के कई संस्करणों में बायनेरिज़ काम करने के लिए सुनिश्चित करने के लिए वर्षों से बड़ी लंबाई में चला गया है: http://www.joelonsoftware.com/articles/APIWar.html

Comments

विंडोज अंतर्निहित वास्तुकला पर भी निर्भर करता है। एआरएम-सक्षम विंडोज एप्लिकेशन नियमित लैपटॉप / डेस्कटॉप पर नहीं चलते हैं, और इसी तरह। यही कारण है कि लिनक्स के पास बेहतर हार्डवेयर सपोर्ट है- क्योंकि कोड को किसी भी प्लेटफ़ॉर्म पर संकलित करने के लिए लिखा गया है, जिसमें एक लिनक्स लिनक्स कार्यान्वयन है, जबकि विंडोज ज्ञात प्रकार के हार्डवेयर पर निर्भर करता है।

— फेयरफॉक्स

यदि आप Windows / x86 का निर्माण करते हैं तो आप 95% बाइनरी कम्पैटिबिलिटी को कवर करते हैं। वह बहुत बढिया है। जब भी लिनक्स / x86 अधिक सामान्य हो रहा है, हम एक ऐसी दुनिया से आए हैं जहाँ आपके पास अपने स्वयं के विशेष प्रोसेसर आर्किटेक्चर और यूनिक्स संस्करण के साथ कई बड़े नाम थे - जो बाइनरी संगत नहीं था।

— सोब्रीक

@Sobrique आपको वह 95% आंकड़ा कहां से मिला? पिछली बार मैंने देखा कि हर 1 x86 के लिए 4 ARM CPU थे। यह कुछ साल पहले था, इससे पहले कि हर कोई एआरएम प्रोसेसर के साथ स्मार्ट-फोन का उपयोग करना शुरू कर दे। इसलिए यदि हम यह मान लें कि कोई अन्य प्रोसेसर नहीं है जो कि 20% है।

— ctrl-alt-delor

Answer 7

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

Answer 8

मुख्य कारण है कि मैं व्यक्तिगत रूप से सिर्फ एक कार्यक्रम के निष्पादन योग्य होना पसंद नहीं करता हूं, क्योंकि मैं पहले यह देखना चाहता हूं कि स्रोत कोड वास्तव में क्या कर रहा है (ज्यादातर इसलिए कि मैं सिर्फ दूसरों के कोड को देखने का आनंद लेता हूं) लेकिन मुझे कई अन्य का पता है जो भी दुर्भावनापूर्ण कोड के लिए स्रोत कोड की जाँच करें।

Answer 9

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

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

Answer 10

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

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

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

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