लिनक्स में "खुद को संकलित करें" मानसिकता का स्रोत क्या है [बंद]

Question

मैंने कॉलेज में लिनक्स का थोड़ा उपयोग किया, और मैं शर्तों से परिचित हूं। मैं नियमित रूप से .NET भाषाओं में विकास करता हूं, इसलिए मैं कंप्यूटर अनपढ़ नहीं हूं।

उस ने कहा, मैं वास्तव में यह नहीं कह सकता कि मैं "इसे स्वयं संकलित करता हूं" [सीआईवाई] मानसिकता जो कि * निक्स सर्कल में मौजूद है। मुझे पता है कि यह दूर जा रहा है, लेकिन फिर भी समय-समय पर इसे सुनते हैं। एक डेवलपर के रूप में, मुझे पता है कि संकलक और आवश्यक निर्भरता स्थापित करना बट में दर्द है, इसलिए मुझे ऐसा लगता है कि CIY काम प्रवाह ने * nix को बहुत कम सुलभ बनाने में मदद की है।

CIY मानसिकता के उदय के कारण किन सामाजिक या तकनीकी कारकों का जन्म हुआ?

Comments

आप इसे लिनक्स सर्कल या यूनिक्स में सुनते हैं? एक बहुत बड़ा अंतर है।

— terdon

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

— सेंटिमेन

और रिकॉर्ड के लिए, लिनक्स सिस्टम पर "कंपाइलर और आवश्यक निर्भरता स्थापित करना" वास्तव में उतना कठिन नहीं है। कुछ आसान भी कह सकते हैं।

— मृत्युंजय

@ डारेन - यह उल्टा है, आजकल अधिकांश ओपनसोर्स टार्बॉल एक मानक का पालन करते हैं जो वर्षों पहले मौजूद नहीं था। टारबॉल डाउनलोड करें, टारबॉल निकालें, सीडी से डायरेक्टरी, रन ./configure <options>, फिर बनाओ और इंस्टॉल करें। मैंने 30 साल पहले AT & T 3B2 सर्वर पर AT & T SysV Unix और Gould iron पर चल रहे UTX पर अपने दांत काटे। चीजें तब बहुत कठिन थीं। कुछ में configureप्रक्रिया की शुरुआत थी , ज्यादातर आपको makefile(s)अपने विशेष सिस्टम के लिए मैन्युअल रूप से संपादित करना था ।

— मृत्युंजय

@Deathgrip वास्तव में, क्या आपने कभी विजुअल स्टूडियो के बिना सिस्टम प्रोग्रामिंग के लिए विंडोज डेवलपमेमट वातावरण स्थापित करने की कोशिश की है? नामुमकिन पर मैं तुम्हें बताता हूँ।

— बिल्ली

Answer 1

बहुत सरलता से, * निक्स के इतिहास के लिए, कोई अन्य विकल्प नहीं था। प्रोग्राम को स्रोत टारबॉल के रूप में वितरित किया गया था और आपके द्वारा उन्हें उपयोग करने का एकमात्र तरीका स्रोत से संकलन करना था। तो यह एक आवश्यक बुराई के रूप में इतनी मानसिकता नहीं है।

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

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

तो यह CIY मानसिकता जैसा कि आप कहते हैं कि यह अनिवार्य रूप से गायब हो गई है। यह अभी भी अच्छी तरह से जीवित हो सकता है और यूनिक्स दुनिया में लात मार सकता है, मुझे वहां कोई अनुभव नहीं है, लेकिन लिनक्स में, यदि आप एक सभ्य वितरण के साथ एक लोकप्रिय वितरण का उपयोग कर रहे हैं, तो आपको लगभग खुद को कुछ भी संकलित करने की आवश्यकता नहीं होगी।

Comments

यूनिक्स दुनिया में, यह फिर से ओएस पर निर्भर करेगा। मेरी अंतिम स्थिति में बड़ी संख्या में सोलारिस (सन स्पार्क प्लेटफॉर्म) सर्वर शामिल थे, और मैंने कुछ वर्षों के लिए सोलारिस 10 एक्स 86 को डेस्कटॉप के रूप में घर पर चलाया। मैं एचपीयूएक्स या एआईएक्स के लिए बात नहीं कर सकता, लेकिन आपको सोलारिस पर थोड़ा सा CIY करना होगा। सूर्य ने सोलारिस के लिए पहले से पैक किए गए कई ओपन सोर्स उपयोगिताओं का वितरण किया। वहाँ भी opencsw.org और unixpackages.com जैसी साइटें थीं। लेकिन मैंने अभी भी स्रोत टारबॉल से काफी संकलन किया है।

— मृत्युंजय

"निक्स के इतिहास के अधिकांश के लिए, कोई अन्य विकल्प नहीं था। कार्यक्रमों को स्रोत टारबॉल के रूप में वितरित किया गया था।" - लेकिन यह CIY मानसिकता के कारण है, है ना?

— वुडरो बारलो

@वुड वास्तव में नहीं। कोई और विकल्प उपलब्ध नहीं था। मत भूलो कि * निक्स पुराना है । इसके अलावा, अधिकांश कार्यक्रम उन सहयोगियों के बीच पारित किए गए थे जो पहले से ही विशेषज्ञ थे और आप 8 अन्य लोगों के लिए इंस्टॉलर या पैकेज मैनेजर के रूप में जटिल के रूप में कुछ का आविष्कार करने से क्यों परेशान होंगे जो आपके कोड का उपयोग करेंगे? जब इस तरह के औजारों का आविष्कार किया गया था, तो * निक्स लोग उन्हें हर किसी की तरह उपयोग करना शुरू कर देते हैं।

— टेराडो

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

— गिल्स एसओ- बुराई को रोकना '

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

— वुडरो बारलो

Answer 2

उस मानसिकता के कुछ कारण हैं, अंतिम उपयोगकर्ताओं, वितरण अनुरक्षकों और कोड आपूर्तिकर्ताओं / डेवलपर्स / परियोजना समूहों से, और उनमें से हर एक पूरी तरह से वैध है।

ओपन सोर्स पहलू

कुछ ऐसे भी हैं जो यह जानकर आनंद लेते हैं कि वे निशुल्क सॉफ्टवेयर का उपयोग कर रहे हैं, और स्रोत से संकलन चुनकर इसे मान्य करते हैं। यह वह जगह है जहां लिनक्स से स्क्रैच प्रोजेक्ट / हाउटो / गाइड / बुक जैसी चीजें आती हैं।

अनुकूलन और विकल्प पहलू

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

सीपीयू आर्किटेक्चर पहलू

क्या आपका कार्यस्थल उच्च अंत गैर-x86 / amd64 मशीनों का उपयोग करता है? जिस पैकेज की आपको आवश्यकता है / वह आपके CPU आर्किटेक्चर के लिए पूर्व-संकलित उपलब्ध नहीं हो सकता है, जो भी वितरण आप चला रहे हैं उससे बहुत कम। दी, इस तरह के हार्डवेयर चलाने वाले अधिकांश स्थान आईबीएम आदि के समर्थन में हैं, और सामान को स्थापित / संकलित नहीं करते हैं। लेकिन क्या होगा अगर आप एक अधिशेष बिक्री से उठाते हैं, एक पुराने iMac w / PPC प्रोसेसर, आदि खोदते हैं?

वितरण पहलू

वितरण "परिवारों" - यानी, डेबियन w / उबंटू, टकसाल, एट अल और रेडहैट के साथ CentOS, व्हाइटबॉक्स, फेडोरा, एट अल - सभी विभिन्न पैकेज प्रारूपों का उपयोग करते हैं। और विभिन्न पुस्तकालय संस्करणों के साथ प्रत्येक संस्करण के जहाज, आदि। यहां तक ​​कि एक सरल सिंगल फाइल शेल स्क्रिप्ट के लिए एक उचित डेबियन की स्थापना की जाती है। deb फ़ाइल में समय और प्रयास लगता है। यदि आपने कुछ सॉफ़्टवेयर को कुछ खुजली को खरोंच करने के लिए लिखा है, और इसे मुफ़्त बनाना चाहते हैं और इसे अपने स्वयं के वेबसर्वर gitlab पर पोस्ट करना चाहते हैं, जो भी हो, आप केवल एक सामान्य .tar.gz फ़ाइल को स्रोत पर फ़ाइल के निर्माण के निर्देश के साथ पोस्ट करेंगे या नहीं। डेबियन (स्थिर और परीक्षण, शायद पुराना) के 2 संस्करणों के लिए पैकेज अप करें, आरपीएम के रूप में रेडहैट और फेडोरा के कई संस्करण, स्लैकवेयर के लिए एक टीजीजेड, जेंटू के लिए एक पुनर्निर्माण प्रोफ़ाइल, आदि आदि।

Comments

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

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

— dogoncouch

Answer 3

जैसा कि @terdon कहते हैं, आजकल चीजों को संकलित करने की आवश्यकता बहुत अधिक पतली है, खासकर घरेलू उपयोगकर्ताओं के लिए।

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

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

मुझे डेबियन में पोर्ट करने के लिए सिस्टम की पुनर्रचना करते समय और / या डेबियन के नए संस्करणों के लिए सॉफ्टवेयर संकलित करना पड़ा, जिसमें एक फ्रेमवर्क था जो अब ओएस द्वारा समर्थित नहीं था।

उदाहरण के लिए, अतीत में मुझे हाथ से डीएचसीपी डेमों को संकलित करने के लिए (तब तक) हाल ही में प्रोटोकॉल में बदलाव के लिए या टेलीकॉम दुनिया में प्रावधान के लिए विशिष्ट पैच का समर्थन करने के लिए समर्थन करना था।

मैं अभी भी अपने स्थानीय रिपॉजिटरी डेब्यू में FreeRadius संस्करणों के लिए खुद को देव git रेपो से संकलित करता हूं, क्योंकि स्थिर संस्करणों की एक स्ट्रिंग थी जो डेबियन में (गंभीर) कीड़े थे, और आमतौर पर डीबिन / उबंटू के लिए इसी .debs नहीं थे। हमारी जरूरतों के लिए पर्याप्त है।

और यह बिना कहे चला जाता है कि अक्सर थोड़ी देर में हमें भी अपने द्वारा लिखे सामान को चलाना / संकलित करना होता है।

आजकल निर्भरताएँ स्थापित करना पहले की तरह कठिन नहीं है, और कुछ सॉफ़्टवेयर में कुछ सामान्य लिनक्स वितरणों के लिए नियम फ़ाइलों को भी कस्टमाइज़ किया गया है जो निर्भरता को संकलित करने के लिए पैकेज फ़ाइल बनाने के भारी काम को करते हैं। स्थानीय रिपॉजिटरी से इस तरह के पैकेज को स्थापित करना आधिकारिक रिपॉजिटरी से एक ही पैकेज को स्थापित करने से बहुत अलग नहीं है।

Answer 4

CIY मानसिकता के उदय के कारण किन सामाजिक या तकनीकी कारकों का जन्म हुआ ?

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

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

अब स्थिति, अधिकांश लोगों के पास केवल अपने डेस्कटॉप पर बैठे मशीन का केवल व्यवस्थापक और एकमात्र उपयोगकर्ता होने के नाते, पारंपरिक यूनिक्स मॉडल से काफी अलग है। एक sysadmin ने केंद्रीय प्रणाली और सभी के डेस्कटॉप पर सॉफ्टवेयर को बनाए रखा। (अक्सर लोगों के वर्कस्टेशन सिर्फ एनएफएस-माउंट /optऔर /usr/local/सेंट्रल सर्वर से होते हैं, और वहां सामान स्थापित करते हैं।)

---

.NET और Java जैसी चीजों से पहले, विभिन्न CPU आर्किटेक्चर में सच बाइनरी-पोर्टेबिलिटी असंभव थी। यूनिक्स संस्कृति इस कारण से डिफ़ॉल्ट के रूप में स्रोत-पोर्टेबिलिटी के साथ विकसित हुई, यहां तक ​​कि एलएसबी जैसे हाल ही में लिनक्स प्रयासों तक बाइनरी-पोर्टेबिलिटी को सक्षम करने का प्रयास करने के लिए। उदाहरण के लिए, POSIX ( प्रमुख यूनिक्स मानक) एकमात्र स्रोत-पोर्टेबिलिटी मानकीकरण करने के लिए, हाल के संस्करणों में भी प्रयास करता है।

संबंधित सांस्कृतिक कारक: प्रारंभिक वाणिज्यिक एटी एंड टी यूनिक्स स्रोत कोड (टेप पर) के साथ आया था। आपको स्रोत से सिस्टम का निर्माण नहीं करना था, यह सिर्फ वहां था जब आप यह देखना चाहते थे कि जब डॉक्स पर्याप्त नहीं थे, तो वास्तव में कुछ कैसे काम करता है।

विकिपीडिया कहता है :

"व्यापक ऑन-लाइन प्रलेखन की यूनिक्स नीति और (कई वर्षों तक) सभी सिस्टम स्रोत कोड के लिए तैयार पहुंच प्रोग्रामर की उम्मीदों को बढ़ाती है, और मुफ्त सॉफ्टवेयर आंदोलन के 1983 के लॉन्च में योगदान दिया है।"

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

---

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

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

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

(स्रोत-स्तरीय पोर्टेबिलिटी मुद्दों के अन्य प्रकार है कि सिर्फ इसलिए कि निर्माण env में मतभेद की होती हैं, और वास्तव में यहां मुद्दा यह है। साथ जावा शैली द्विआधारी पोर्टेबिलिटी, ऑटो उपकरण (लिए प्रासंगिक नहीं हैं कर रहे हैं autoconf/ auto-make) और की तरह इसी तरह की बातों cmakewouldn 'टी की जरूरत हो। और हम चीजों को नहीं होगा की तरह कुछ सिस्टम के शामिल किए जाने की आवश्यकता <netinet/in.h>के बजाय<arpa/inet.h> के लिएntohl(3) । (और शायद हमारे पास नहीं हैं ntohl()या पहली जगह में किसी भी अन्य बाइट-आदेश सामान!)

---

मैं नियमित रूप से .NET भाषाओं में विकास करता हूं, इसलिए मैं कंप्यूटर अनपढ़ नहीं हूं।

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

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

लाइब्रेरी संस्करण एक और समस्या है । लाइब्रेरीज़ बाइनरी-लेवल ABI को बदलते समय अक्सर सोर्स-लेवल API को स्थिर रख सकते हैं। ( एपीआई और एबीआई के बीच अंतर देखें ।) उदाहरण के लिए, एक अपारदर्शी में किसी अन्य सदस्य को जोड़ने से structअभी भी इसका आकार बदल जाता है, और किसी भी कोड के लिए नए लाइब्रेरी संस्करण के लिए हेडर के साथ एक recompile की आवश्यकता होती है जो इस तरह की संरचना के लिए स्थान आवंटित करता है, चाहे वह गतिशील हो (मैलोक) ), स्थैतिक (वैश्विक), या स्वचालित (स्टैक पर स्थानीय)।

ऑपरेटिंग सिस्टम भी महत्वपूर्ण हैं । एक ही CPU वास्तुकला के लिए यूनिक्स का एक अलग स्वाद अलग बाइनरी फ़ाइल स्वरूपों हो सकता है, जैसे स्थिरांक के लिए सिस्टम कॉल, और अलग अलग संख्यात्मक मान बनाने के लिए एक अलग ABI fopen(3)की O_RDONLY, O_APPEND,O_TRUNC ।

ध्यान दें कि यहां तक ​​कि एक गतिशील रूप से जुड़े बाइनरी में अभी भी कुछ ओएस-विशिष्ट स्टार्टअप कोड हैं जो पहले चलते हैं main()। विंडोज पर, यह है crt0। यूनिक्स और लिनक्स में एक ही बात है, जहां कुछ सी-रनटाइम स्टार्टअप कोड हर बाइनरी में सांख्यिकीय रूप से जुड़ा हुआ है। मुझे लगता है कि सिद्धांत में आप एक ऐसी प्रणाली डिजाइन कर सकते हैं जहां वह कोड गतिशील रूप से भी जुड़ा हुआ था, और libc या डायनेमिक लिंकर का ही हिस्सा है, लेकिन यह नहीं है कि किसी भी ओएस पर व्यवहार में चीजें कैसे काम करती हैं, इससे मैं अवगत हूं। यह केवल सिस्टम-कॉल ABI समस्या को हल करेगा, न कि मानक-पुस्तकालय कार्यों के लिए स्थिरांक के लिए संख्यात्मक मानों की समस्या। (आम तौर पर सिस्टम-कॉल को लिबास रैपर फ़ंक्शन के माध्यम से किया जाता है: स्रोत के लिए एक सामान्य x86-64 लिनक्स बाइनरी mmap()जो syscallनिर्देश का उपयोग नहीं करेगा , बस एकcall इसी नाम के लिबास रैपर फ़ंक्शन को निर्देश।

यह इस बात का हिस्सा है कि आप i386-Linux पर i386-FreeBSD बायनेरी क्यों नहीं चला सकते। (थोड़ी देर के लिए, लिनक्स कर्नेल में सिस्टम-कॉल संगतता परत थी। मुझे लगता है कि बीएसडी कम से कम एक बीएसएनएल लिनक्स को एक समान कम्प्रेसर परत के साथ चला सकता है, लेकिन आपको निश्चित रूप से लिनक्स पुस्तकालयों की आवश्यकता है।)

---

यदि आप बायनेरिज़ वितरित करना चाहते हैं, तो आपको सीपीयू / ओएस-फ्लेवर + संस्करण / स्थापित-लाइब्रेरी-संस्करणों के हर संयोजन के लिए एक अलग से एक बनाना होगा ।

'80 / 80 'के दशक में वापस, यूनिक्स सिस्टम (MIPS, SPARC, POWER, PA-RISC, m68k, आदि) के लिए आम उपयोग में कई अलग-अलग प्रकार के CPU थे, और Unix (IRIX, SunOS, SunOS) के कई अलग-अलग स्वाद थे। सोलारिस, एआईएक्स, एचपी-यूएक्स, बीएसडी, आदि)।
और यह सिर्फ यूनिक्स सिस्टम है। कई स्रोत पैकेज अन्य प्रणालियों पर भी संकलन और काम करेंगे , जैसे VAX / VMS, MacOS (m68k और PPC), Amiga, PC / MS-DOS, अटारी एसटी, आदि।

अभी भी कई सीपीयू आर्किटेक्चर और ओएस हैं, हालांकि अब डेस्कटॉप का एक बड़ा हिस्सा x86 तीन प्रमुख ओएस में से एक चल रहा है।

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

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

मुख्य व्यावसायिक परियोजनाओं को छोड़कर सभी प्रमुख संयोजनों पर निर्माण और परीक्षण करने की लागत को छोड़कर, पुराने स्कूल यूनिक्स के लिए बायनेरिज़ वितरित करना पूरी तरह से संभव था ।

यहां तक ​​कि बस के लिए बायनेरी बनाना i386-linux-gnuऔर amd64-linux-gnuकठिन है। पोर्टेबल बायनेरिज़ को संभव बनाने के लिए लिनक्स स्टैंडर्ड बेस जैसी चीजों पर बहुत समय और प्रयास खर्च किया गया है । यहां तक ​​कि सांख्यिकीय रूप से लिंकिंग बायनेरी सब कुछ हल नहीं करता है। (उदा। रेडहैट सिस्टम बनाम डेबियन सिस्टम पर वर्ड-प्रोसेसिंग प्रोग्राम को कैसे प्रिंट करना चाहिए? एक डेमॉन के लिए उपयोगकर्ता या समूह को कैसे स्थापित करना चाहिए, और इसके स्टार्टअप स्क्रिप्ट को हर रिबूट के बाद चलाने की व्यवस्था करनी चाहिए?) वे महान नहीं हैं उदाहरण, क्योंकि स्रोत से पुनर्प्राप्ति उन्हें हल नहीं करता है।

---

उस सब के अलावा, दिन में वापस स्मृति अब की तुलना में अधिक कीमती थी। संकलन-समय पर वैकल्पिक सुविधाओं को छोड़कर छोटे बायनेरिज़ (कम कोड आकार) बना सकते हैं जो अपने डेटा संरचनाओं के लिए कम मेमोरी का उपयोग करते हैं। यदि किसी सुविधा में किसी निश्चित classया हर structचीज़ को ट्रैक करने के लिए किसी अतिरिक्त सदस्य की आवश्यकता होती है, तो उस सुविधा को अक्षम करने से ऑब्जेक्ट 4 बाइट्स (उदाहरण के लिए) से हट जाएगा, जो कि एक वस्तु है जिसे प्रोग्राम 100k आवंटित करता है तो अच्छा है।

इन दिनों वैकल्पिक संकलन-समय की विशेषताएं अक्सर अतिरिक्त पुस्तकालयों को वैकल्पिक बनाने के लिए उपयोग की जाती हैं। जैसे आप संकलन कर सकते हैं ffmpegके साथ या बिना libx264, libx265, libvorbisविशिष्ट वीडियो / ऑडियो एनकोडर, उपशीर्षक हैंडलिंग, आदि आदि के लिए, और कई अन्य पुस्तकालयों अधिक सामान्यतः, बहुत कुछ के साथ या बिना संकलित किया जा सकता libreadline: अगर यह उपलब्ध है जब आप चलाने ./configure, परिणामस्वरूप बाइनरी लाइब्रेरी पर निर्भर करेगा, और टर्मिनल से पढ़ते समय फैंसी लाइन-संपादन प्रदान करेगा। यदि यह नहीं है, तो कार्यक्रम स्टैन से fgets()या कुछ और के साथ लाइनों को पढ़ने के लिए कुछ फ़ॉल-बैक समर्थन का उपयोग करेगा ।)

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