बाकी सिस्टम को छोड़ते हुए लिनक्स कर्नेल को अपडेट करना


25

मैं एक OpenBSD उपयोगकर्ता हूं। में OpenBSD पूछे जाने वाले प्रश्न यह कहते हैं:

OpenBSD एक पूर्ण प्रणाली है, जिसका उद्देश्य सिंक में रखा जाना है। यह एक कर्नेल प्लस उपयोगिताओं नहीं है जिन्हें एक दूसरे से अलग से अपग्रेड किया जा सकता है।

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

सिंक कर्नेल, बेस सिस्टम और / या 3 पार्टी पैकेज से बाहर होना मुद्दों का एक संभावित स्रोत है और अधिक या कम आपको आधिकारिक मेलिंग सूचियों से कोई भी गंभीर सहायता प्राप्त करने से अयोग्य घोषित करता है।

मैं इसके साथ काफी ठीक हूं। वास्तव में, यह एक कारण है कि मैं ओपनबीएसडी का उपयोग करता हूं। यह सिस्टम को एक सुसंगत इकाई बनाता है और इससे मुझे इसका मानसिक अवलोकन बनाने में आसानी होती है।

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

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

कौन या क्या गारंटी देता है कि लिनक्स सिस्टम के विभिन्न सबसिस्टम एक-दूसरे से स्वतंत्र रूप से अपडेट होने के बावजूद एक-दूसरे के साथ सहयोग करने में सक्षम हैं?

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


मैं "लिनक्स वितरण" के लिए शॉर्टहैंड के रूप में "लिनक्स" का उपयोग करता हूं, कर्नेल + उपयोगिताओं।


यह कहने का एक और तरीका है कि ओपनबीएसडी का केवल एक ही वितरण है। एक नियमित लिनक्स सिस्टम पर कई ग्रब मेनू प्रविष्टियां पहले के कर्नेल में वापस गिरने के लिए होती हैं, जो कि (आमतौर पर) नवीनतम किसी कारण से बूट नहीं हो सकती हैं।
थोरबजोरन रावन एंडरसन

जवाबों:


29

लिनस टॉर्वाल्ड्स के पास कर्नेल परिवर्तनों के खिलाफ एक बहुत मजबूत राय है जिसके परिणामस्वरूप उपयोगकर्ता विवरण प्राप्त होते हैं (विवरण के लिए " लिनक्स कर्नेल: ब्रेकिंग यूजर स्पेस " देखें)।

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

जब यूजरस्पेस को तोड़ने के बिना मौजूदा इंटरफ़ेस को बदलना संभव नहीं है, तो अतिरिक्त सिस्टम कॉल जोड़े गए हैं जो विस्तारित कार्यक्षमता प्रदान करते हैं। यही कारण है कि सिस्टम कॉल के तीन संस्करण dupऔर दो संस्करण हैं umount

एक स्थिर उपयोगकर्ता स्थान होने की नीति यही कारण है कि कर्नेल अद्यतन शायद ही कभी उपयोगकर्ताओं के अनुप्रयोगों में समस्याएँ पैदा करते हैं और आप आमतौर पर कर्नेल के उन्नयन के बाद मुद्दों की अपेक्षा नहीं करते हैं।

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

@PeterCordes ने बताया कि अगर में एक परिवर्तन procfs या sysfs अपने वितरण स्क्रिप्ट init द्वारा इस्तेमाल किया एक आवेदन टूट जाता है, तो आप आ समस्या हो सकता था।

यह कुछ हद तक इस बात पर निर्भर करता है कि आपका वितरण कर्नेल (दीर्घकालिक समर्थन या मेनलाइन) को कैसे अपडेट करता है और फिर भी समस्याएँ अपेक्षाकृत दुर्लभ हैं क्योंकि वितरण आमतौर पर उसी समय अपडेट किए गए टूल को भेजते हैं।

@StephenKitt ने कहा कि अपग्रेड किए गए उपयोगकर्ताओं को कर्नेल के नए संस्करण की आवश्यकता हो सकती है, जिस स्थिति में सिस्टम पुराने कर्नेल के साथ बूट करने में सक्षम नहीं हो सकता है और उपयुक्त होने पर वितरण रिलीज़ नोट इसका उल्लेख करते हैं।


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

3
यहां तक ​​कि procfs ( /proc) और sysfs ( /sys) को यथासंभव स्थिर रखा जाता है, उसी के बाद "उपयोगकर्ता-स्थान को न तोड़ें" नीति / दर्शन। इसके अलावा, ioctl()डिवाइस फ़ाइलों पर कोड en.wikipedia.org/wiki/Ioctl । यह कहीं सरल प्रणाली-कॉल ABI संगतता परे चला जाता है, लेकिन जैसा कि आप कहते हैं कि जब कोई खास कारण है, बातों में परिवर्तन करना /procऔर /sys। यह अधिकांश कार्यक्रमों को सीधे नहीं तोड़ देगा, लेकिन अगर यह आपके डिस्ट्रो की इनिट स्क्रिप्ट्स द्वारा उपयोग किए गए निम्न-स्तरीय उपयोगकर्ता-स्पेस प्रोग्राम को तोड़ता है, तो आपको समस्या हो सकती है। सौभाग्य से यह दुर्लभ है।
पीटर कॉर्ड्स

वास्तव में IIRC rfkillस्विच जैसी कुछ फ़ाइलों ने कुछ कर्नेल उन्नयन में स्थान बदल दिए हैं। तो /procऔर /syssyscall इंटरफ़ेस की तुलना में बहुत कम स्थिर हैं। सौभाग्य से, वितरण में आमतौर पर ऐसे कर्नेल उन्नयन शामिल नहीं होते हैं जब तक कि यह एक प्रमुख वितरण संस्करण अपग्रेड न हो।
रुस्लान

3
यहाँ पर विचार करने के दो पहलू हैं: कर्नेल को अपग्रेड करना, और उपयोक्ता को अपग्रेड करना। कर्नेल की एबीआई स्थिरता के लिए धन्यवाद, कर्नेल को अपग्रेड करना काफी सुरक्षित है (यहां तक ​​कि आमतौर पर /procऔर /sysपरिवर्तन - हटाने में वर्षों लगते हैं)। हालाँकि, उपयोगकर्ताओं को अपग्रेड करने के लिए एक नए कर्नेल की आवश्यकता हो सकती है, और यदि आपके पास एक नया पर्याप्त कर्नेल नहीं है, तो आप एक अनबूटेबल सिस्टम के साथ समाप्त हो सकते हैं। डिस्ट्रो रिलीज़ नोट उपयुक्त होने पर इसका उल्लेख करते हैं (ताकि डिस्ट्रो को आँख बंद करके अपग्रेड न करें, रिलीज़ नोट्स पढ़ें)।
स्टीफन किट

1
नई kernels में अधिक फ़ील्ड जोड़ने के लिए उपयोगकर्ता / फ़ाइलें और sys फ़ाइलों के लिए दिशानिर्देश हैं और उपयोगकर्ताओं को उन्हें कैसे पढ़ना चाहिए। / proc / stat उदाहरण के लिए, या / proc / meminfo। उपयोगकर्ता के अंतरिक्ष में जोड़े गए क्षेत्रों को अनदेखा करने की उम्मीद है।
ज़ैन लिंक्स

11

लिनक्स कर्नेल और लिनक्स वितरण का उपयोगकर्ता स्थान, जो ऐतिहासिक रूप से GNU परियोजना द्वारा विकसित उपयोगकर्ता उपकरणों पर हावी था, शिथिल युग्मित हैं। भाग में यह डिजाइन द्वारा है, और भाग में यह आवश्यकता के अनुसार है।

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

और @sebasth यह भी उत्कृष्ट बिंदु बनाता है कि लिनक्स कर्नेल परियोजना की एक प्रमुख नीति यह है कि इसे उपयोगकर्ता स्थान को नहीं तोड़ना चाहिए। कौन सा पाठ्यक्रम ढीले युग्मन को लागू करने वाला एक अन्य कारक है।

हालांकि, अभी भी कुछ डिग्री युग्मन है। पर्याप्त पुराने लिनक्स कर्नेल आधुनिक वितरण के साथ काम नहीं करेंगे।


2
@ यदि यह नाइट-पिकिंग है, लेकिन फ़ॉरवर्ड कम्पैटिबिलिटी प्रदान की जा सकती है, यदि उपयोगकर्ता कर्नेल गायब कर्नेल सुविधाओं के लिए उपयुक्त फ़ॉलबैक (यहां तक ​​कि डिग्रेड की गई कमियां) को लागू करता है। यह अक्सर वांछनीय या इसके लायक नहीं है, यह भी माना जाता है, लेकिन कुछ सॉफ्टवेयर ऐसा करते हैं ( glibcउदाहरण के लिए)। (लेकिन हां, यह एक गिरी वादा नहीं है, यह एक उपयोगकर्ता का वादा है।)
स्टीफन किट

7

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

सिस्टम पर वर्तमान में उपयोग किए गए पैकेज और पहले से स्थापित पैकेज में दो कर्नेल पैकेज सूट होना आम बात है। नवीनीकरण करते समय, सुनिश्चित करने के बाद कि नया संस्करण ठीक से काम करता है, सबसे पुराना हटाया जा सकता है और आपके पास अभी भी ज्ञात-सुरक्षित वापसी है। उदाहरण के लिए, Red Hat (और उसके चचेरे भाई) package-cleanup --oldkernels --count 2को यह स्वचालित रूप से करना होगा।


यहां तक ​​कि कुछ ऐसे kmod , जो आपको लगता है कि कर्नेल संस्करण से बंधे होने की आवश्यकता होगी , इसमें थोड़ा सा लेवे है जिसमें यह संस्करणों के साथ काम करेगा।
इग्नासियो वाज़क्वेज़-अब्राम्स

4

यहां सभी अच्छे तर्कों के अलावा, मैं कुछ बिंदु जोड़ सकता हूं जो मदद करेंगे।

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

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.