क्रॉस-प्लेटफ़ॉर्म अनुप्रयोगों के लिए "वसा बायनेरिज़" का अधिक व्यापक रूप से उपयोग क्यों नहीं किया जाता है?

Question

जहाँ तक मुझे पता है, तथाकथित "वसा बायनेरिज़" - निष्पादन योग्य फाइलें जिनमें कई प्रणालियों के लिए मशीन कोड होते हैं - केवल Apple पीसी पर वास्तव में उपयोग किए जाते हैं, और यहां तक ​​कि ऐसा लगता है कि वे केवल उनका उपयोग करते थे क्योंकि उन्हें संक्रमण की आवश्यकता थी पावरपीसी से x86 तक।

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

मैं बहुत सारे अनुमान लगा सकता हूं कि यह दृष्टिकोण कभी क्यों नहीं पकड़ा गया, उदाहरण के लिए:

• मल्टी-ओएस बायनेरी को पार करने योग्य क्रॉस-संकलन टूल की कमी
• आपको वैसे भी प्रत्येक OS पर कोड का परीक्षण करने की आवश्यकता होती है, इसलिए आपके पास पहले से ही ऐसे सिस्टम होने चाहिए जो प्रत्येक OS के लिए मूल रूप से संकलित कर सकें
• पहले से ही 64-बिट मशीनों पर 32-बिट प्रोग्राम "बस काम"
• डायनेमिक लिंकिंग प्रत्येक OS पर अलग-अलग तरीके से काम करता है, इसलिए एक "वसा पुस्तकालय" भले ही "वसा अनुप्रयोग" हो, काम नहीं कर सकता है

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

Comments

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

— डोभाल

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

क्योंकि हमारे पास बाइट कोड और वर्चुअल मशीनें हैं जो इस समस्या को बेहतर तरीके से हल करती हैं।

— रॉबर्ट हार्वे

मुझे आश्चर्यचकित करता है, क्या पॉलीग्लॉट निष्पादन योग्य फ़ाइल बनाना संभव है जो विंडोज और कुछ * NIX दोनों में काम करता है?

— आआआआआ आआआआआ आआआआआआआ

ऐतिहासिक रिकॉर्ड के लिए, वसा बायनेरीज़ 68k से -> पीपीसी संक्रमण, पीपीसी नहीं -> x86 संक्रमण।

— मार्क

Answer 1

वसा बाइनरी दृष्टिकोण सबसे अधिक समझ में आता है अगर:

1. दोनों आर्किटेक्चर एक ही प्रणाली पर सह-अस्तित्व में हैं
2. बाकी सभी चीजें कमोबेश सभी आर्किटेक्चर के लिए समान हैं

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

लिनक्स पर, दोनों मापदंड अभी भी लागू होंगे यदि आप एक ही लिनक्स वितरण पर 32 और 64 बिट दोनों का समर्थन करना चाहते हैं । लेकिन परेशान क्यों, अगर आपको पहले से ही कई वितरणों का समर्थन करना है?

पर विंडोज , 16 बिट 32 बिट से संक्रमण विंडोज एनटी, जो कई संबंध में 16 बिट विंडोज दुनिया से प्रमुख विचलन (आभासी स्मृति, बहु उपयोगकर्ता अभिगम नियंत्रण, एपीआई परिवर्तन ...) था की शुरूआत के साथ शुरू में हुआ। इन सभी परिवर्तनों के साथ, 32 और 16 बिट दुनिया को अलग रखना बेहतर था। NT के पास पहले से ही "सबसिस्टम" की अवधारणा अलग-अलग OS "personae" (Win32, POSIX) का समर्थन करती थी, इसलिए Win16 को तीसरा सबसिस्टम बनाना एक सीधा विकल्प था।

Win32 संक्रमण के लिए Win32 में समान बड़े परिवर्तन शामिल नहीं थे, लेकिन Microsoft ने वैसे भी एक समान दृष्टिकोण का उपयोग किया, शायद इसलिए कि यह साबित हुआ और कोशिश की गई।

Answer 2

इंटरनेट आयु वितरण लॉजिस्टिक्स दो तरीकों से वसा बायनेरिज़ का विघटन करता है:

1. बिक्री के बिंदु में भौतिक वस्तुएं शामिल नहीं होती हैं और इसलिए कम SKU का पक्ष होता है, जब मामला खुदरा शेल्फ स्थान के लिए प्रतिस्पर्धा करता है और ग्राहकों को खरीदारी करने के लिए सीमित अवसर होते हैं।

2. बैंडविड्थ की लागत किसी विशेष सॉफ्टवेयर पैकेज के लिए न्यूनतम आवश्यक बिट्स देने के पक्ष में है। वायर के नीचे एक वसा बाइनरी शिपिंग करने से ग्राहक अनुभव और विक्रेता बुनियादी ढांचे की दक्षता दोनों में गिरावट आती है।

फैट बायनेरिज़ ने और अधिक समझ में आता है जब सॉफ्टवेयर लिपटे भौतिक मीडिया को सिकोड़ता था।

Comments

सॉफ्टवेयर तैनाती के लिए, बैंडविड्थ की लागत वैसे भी आजकल लगभग असंगत है। यदि यह अभी भी एक समस्या है, तो बस 5 मिनट प्रतीक्षा करें।

— रॉबर्ट हार्वे

@RobertHarvey, लेकिन वे 5 मिनट हैं जो मैं इंतजार नहीं करूंगा।

— आर्टुरो टॉरेस सैंचेज़

Answer 3

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

बस लिनक्स / x86-64 के लिए यह मुश्किल है कि बाइनरी निष्पादन को हर लिनक्स वितरण पर चलाने में सक्षम बनाने के लिए (क्योंकि यह अक्सर विशिष्ट संस्करणों के लिए बंधा होता libcहै libstdc++)। FatELF मौजूद है लेकिन बहुत सफल नहीं है।

यहां तक ​​कि एक अच्छी तरह से परिभाषित एबीआई और अनुदेश सेट के साथ, अनुकूलन विभिन्न प्रोसेसर ब्रांडों पर अलग होगा - जीसीसी के -mtune=native x86 अनुकूलन ध्वज को देखें ।

Apple आंशिक रूप से केवल वसा बायनेरिज़ होने में सफल रहा क्योंकि वे कंप्यूटिंग संसाधनों का एक बहुत ही बंद इको-सिस्टम प्रदान करते हैं।

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

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

अंत में, कई ऑपरेटिंग सिस्टम (जैसे सोर्स कोड उपलब्ध है) प्रदान करने में मदद करने के लिए कई चौखटे मौजूद हैं (जैसे स्रोत कोड उपलब्ध है), जैसे क्यूटी और पीओसीओ ।

यहां तक ​​कि एक अच्छी तरह से निर्दिष्ट बायोटेक का उपयोग करना जैसे कि जेवीएम हमेशा पोर्टेबिलिटी की गारंटी नहीं है: कुछ जावा अनुप्रयोगों को पोर्टेबल नहीं जाना जाता है (उदाहरण के लिए क्योंकि वे कुछ विशेष फ़ाइल पदानुक्रम और नामकरण की अपेक्षा करते हैं)।

BTW, कंप्यूटर सिस्टम शायद 1980 या 1990 के दशक की तुलना में (या मेनफ्रेम युग में) आज की तुलना में बहुत कम विषम हैं।

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

Comments

मैं इस धारणा पर विवाद करता हूं कि सॉफ्टवेयर को "फ्री" बनाने से यह आसानी से पोर्टेबल हो जाता है।

— रॉबर्ट हार्वे

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

— बेसिल स्ट्रायनेवविच

@RobertHarvey सिद्धांत में कोई मौलिक लिंक नहीं हो सकता है, लेकिन कई पूरी तरह से व्यावहारिक कारण हैं कि फ्री सॉफ्टवेयर इतने सारे प्लेटफार्मों में बहुत व्यापक रूप से फैल गया है और इतने सारे क्रॉस-प्लेटफॉर्म बिल्ड टूल और टूल चेन बनाए गए हैं।

— इसकी

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

— रवांग

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

— टिम पोस्ट