किसी भी अंतर-निर्भर प्रणालियों में मूल रूप से दो विकल्प होते हैं। अमूर्तता और एकीकरण। (मैं जानबूझकर तकनीकी शब्दों का उपयोग नहीं कर रहा हूं)। एब्स्ट्रेक्शन के साथ, आप कह रहे हैं कि जब आप किसी एपीआई को कॉल करते हैं, जबकि एपीआई के पीछे कोड बदल सकता है, तो परिणाम हमेशा एक ही होगा। उदाहरण के लिए जब हम कहते हैं कि fs.open()हमें परवाह नहीं है कि क्या यह एक नेटवर्क ड्राइव, एक एसएसडी या एक हार्ड ड्राइव है, तो हमें हमेशा एक ओपन फाइल डिस्क्रिप्टर मिलेगा जिसके साथ हम सामान कर सकते हैं। "एकीकरण" के साथ लक्ष्य एक चीज़ करने के लिए "सबसे अच्छा" तरीका प्रदान करना है, भले ही तरीका बदल जाए। उदाहरण के लिए, डिस्क पर फ़ाइल की तुलना में नेटवर्क शेयर के लिए फ़ाइल खोलना अलग हो सकता है। आधुनिक लिनक्स डेस्कटॉप में दोनों ही तरीकों का काफी इस्तेमाल किया जाता है।
डेवलपर्स के दृष्टिकोण से यह "किसी भी संस्करण के साथ काम करता है" या "एक विशिष्ट संस्करण के साथ काम करता है" का सवाल है। इसका एक बड़ा उदाहरण OpenGL है। अधिकांश गेम ओपनजीएल के एक विशिष्ट संस्करण के साथ काम करने के लिए तैयार हैं। इससे कोई फर्क नहीं पड़ता कि आप स्रोत से संकलन कर रहे हैं। यदि खेल को ओपन 1.1 का उपयोग करने के लिए लिखा गया था और आप इसे 3.x पर चलाने की कोशिश कर रहे हैं, तो आपके पास अच्छा समय नहीं होगा। स्पेक्ट्रम के दूसरे छोर पर, कुछ कॉलों से, काम करने की उम्मीद की जाती है, चाहे कुछ भी हो। उदाहरण के लिए, मैं कॉल करना चाहता fs.open()हूं मुझे परवाह नहीं है कि मैं किस कर्नेल संस्करण पर हूं। मुझे सिर्फ एक फाइल डिस्क्रिप्टर चाहिए।
हर तरह से फायदे हैं। एकीकरण पश्चगामी संगतता की कीमत पर "नई" सुविधाएँ प्रदान करता है। जबकि अमूर्तता "नई" कॉल पर स्थिरता प्रदान करती है। हालांकि यह ध्यान रखना महत्वपूर्ण है कि यह प्राथमिकता का मामला है, संभावना नहीं।
वास्तव में अच्छे कारण के बिना एक सांप्रदायिक दृष्टिकोण से, एक जटिल प्रणाली में अमूर्तता हमेशा बेहतर होती है। उदाहरण के लिए, कल्पना करें कि fs.open()कर्नेल संस्करण के आधार पर अलग तरीके से काम किया जाए। फिर एक साधारण फ़ाइल सिस्टम इंटरैक्शन लाइब्रेरी को कई सौ अलग-अलग "खुली फ़ाइल" विधियों (या शायद ब्लॉक) की आवश्यकता होगी। जब एक नया कर्नेल संस्करण सामने आया, तो आप "अपग्रेड" करने में सक्षम नहीं होंगे, आपको अपने द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर के हर एक टुकड़े का परीक्षण करना होगा। कर्नेल 6.2.2 (नकली) आपके पाठ संपादक को तोड़ सकता है।
कुछ वास्तविक दुनिया उदाहरणों के लिए OSX उपयोगकर्ता स्थान को तोड़ने की परवाह नहीं करता है। वे "अमूर्त" से अधिक बार "एकीकरण" का लक्ष्य रखते हैं। और हर बड़े ओएस अपडेट में, चीजें टूट जाती हैं। यह नहीं कहना है कि एक तरीका बेहतर है तो दूसरा। यह एक विकल्प और डिजाइन निर्णय है।
सबसे महत्वपूर्ण बात, लिनक्स इको-सिस्टम भयानक ओपनसोर्स परियोजनाओं से भरा है, जहां लोग या समूह अपने खाली समय में प्रोजेक्ट पर काम करते हैं, या क्योंकि उपकरण उपयोगी है। इसे ध्यान में रखते हुए, दूसरा मज़ेदार होना बंद हो जाता है और पीआईए होना शुरू हो जाता है, जो डेवलपर्स कहीं और चले जाएंगे।
उदाहरण के लिए, मैंने एक पैच सबमिट किया BuildNotify.py। इसलिए नहीं कि मैं परोपकारी हूं, बल्कि इसलिए कि मैं उपकरण का उपयोग करता हूं, और मुझे एक सुविधा चाहिए थी। यह आसान था, इसलिए यहाँ, एक पैच है। यदि यह जटिल होता, या बोझिल होता, तो मैं उपयोग नहीं करता BuildNotify.pyऔर मुझे कुछ और मिल जाता। अगर हर बार एक कर्नेल अपडेट सामने आया तो मेरा टेक्स्ट एडिटर टूट गया, मैं बस एक अलग ओएस का उपयोग करूंगा। समुदाय में मेरा योगदान (हालांकि छोटा है) जारी रहेगा या मौजूद नहीं होगा, और इसी तरह।
इसलिए, डिजाइन का निर्णय अमूर्त प्रणाली कॉल के लिए किया गया था, ताकि जब मैं ऐसा करूं तो fs.open()यह सिर्फ काम करे। इसका मतलब है कि लोकप्रियता हासिल करने के fs.openबाद लंबे समय तक बनाए रखना fs.open2()।
ऐतिहासिक रूप से, यह सामान्य रूप से POSIX सिस्टम का लक्ष्य है। "यहां कॉल और अपेक्षित रिटर्न मान हैं, आप बीच का पता लगाते हैं।" पोर्टेबिलिटी कारणों के लिए फिर से। लिनुस उस पद्धति का उपयोग करने का विकल्प क्यों चुनता है, यह उसके मस्तिष्क के लिए आंतरिक है, और आपको उसे यह जानने के लिए कहना होगा कि वास्तव में क्यों। यदि यह मुझे था, लेकिन मैं एक जटिल प्रणाली पर एकीकरण पर अमूर्तता का चयन करूंगा।