सब जिन्हें जेंटू का उपयोग करने के लिए प्रोत्साहित किया गया, वे यह जानते हैं यह लिनक्स डिस्ट्रो वह यह अत्यधिक अनुकूलन योग्य है इसको धन्यवाद पूर्व संकलित बायनेरिज़ का उपयोग नहीं करता, किसके साथ उपयोगकर्ता को सिस्टम को स्वयं संकलित करना होगा जो इसे अन्य वितरणों पर एक बड़ा लाभ देता है क्योंकि आप कंप्यूटर घटकों पर केंद्रित एक संकलन बना सकते हैं, जो इसे अधिक तरलता और प्रदर्शन प्रदान करता है।
कब से? पोर्टेज, जो कुछ उन्नत सुविधाएँ लागू करता है जैसे निर्भरता प्रबंधन, प्रशासक की पसंद के अनुसार पैकेजों की फाइन-ट्यूनिंग, ओपनबीएसडी-शैली नकली इंस्टॉलेशन, सैंडबॉक्स का निर्माण, सुरक्षित अनइंस्टॉलेशन, सिस्टम प्रोफाइल, वर्चुअल पैकेज, कॉन्फ़िगरेशन फ़ाइल प्रबंधन और एक ही पैकेज के विभिन्न संस्करणों के लिए कई स्लॉट।
लेकिन अब, यह बदल सकता है जबसे जेंटू डेवलपर्स चर्चा कर रहे हैं की संभावना सामान्य लिनक्स कर्नेल पैकेज का प्रावधान करें जिसके लिए मैन्युअल कॉन्फ़िगरेशन की आवश्यकता नहीं है संकलन के दौरान और पारंपरिक बाइनरी वितरण में प्रदान किए गए कर्नेल पैकेज के समान हैं।
कोमो समस्या का उदाहरण जब आप उपयोग करते हैं तो क्या होता है कर्नेल मापदंडों की मैन्युअल ट्यूनिंग जेंटू पर अभ्यास किया, एकीकृत सेट का अभाव है डिफ़ॉल्ट विकल्पों में से जो अद्यतन के बाद संचालन क्षमता की गारंटी देता है (मैन्युअल रूप से कॉन्फ़िगर करते समय, यदि कर्नेल बूट नहीं होता है या क्रैश होता है, तो यह स्पष्ट नहीं है कि समस्या गलत पैरामीटर सेटिंग्स या कर्नेल में बग के कारण होती है।)
कर्नेल प्राप्त करने का पारंपरिक जेंटू तरीका स्रोतों को स्थापित करना है, और फिर स्वयं को कॉन्फ़िगर और बनाना है। जो लोग इसे मैन्युअल रूप से कॉन्फ़िगर करने की कठिन प्रक्रिया से नहीं गुजरना चाहते थे, उनके लिए जेनकर्नेल का उपयोग करने के लिए एक वैकल्पिक मार्ग प्रदान किया गया था। हालाँकि, उनमें से कोई भी वेरिएंट वास्तव में बाइनरी वितरण द्वारा प्रदान किए गए कोर के बराबर प्रदान करने में सक्षम नहीं था।
डेवलपर्स एक तैयार कोर उपलब्ध कराने का इरादा रखते हैं और स्पष्ट रूप से कार्यात्मक जिसे न्यूनतम प्रयास से स्थापित किया जा सकता है (ईबिल्ड की तरह, अन्य पैकेजों के साथ सादृश्य द्वारा निर्मित) और नियमित सिस्टम अपडेट के हिस्से के रूप में पैकेज मैनेजर द्वारा स्वचालित रूप से अपडेट किया जाएगा।
वर्तमान में, sys-kernel/vanilla-kernel पैकेज के आधार पर पहले ही प्रस्तावित किया जा चुका है मुख्य कर्नेल स्रोतों से, जो जेनकर्नेल विकल्पों के एक विशिष्ट सेट के साथ पहले से उपलब्ध बिल्ड स्क्रिप्ट को पूरक करते हैं।
यदि मुझे कस्टम कर्नेल की पुरानी परंपरा को सार्वभौमिक कर्नेल पैकेज में बदलने का औचित्य सिद्ध करना है, तो मुझे उन कारणों पर चर्चा करके शुरुआत करनी चाहिए कि आप सबसे पहले कस्टम कर्नेल को कॉन्फ़िगर क्यों करना चाहते हैं।
वेनिला-कर्नेल पैकेज अभी तक इसमें केवल सोर्स कोड से असेंबलिंग शामिल है (ईबिल्ड फॉर्म में प्रस्तावित), लेकिन बाइनरी कर्नेल असेंबली उत्पन्न करने की संभावना पर भी चर्चा की गई है।
मुख्य प्रतिवाद प्रयास है। जैसा कि ऊपर उल्लेख किया गया है, मैं व्यक्तिगत रूप से अपने कर्नेल से मैन्युअल रूप से निपटने से थक गया हूं। क्या उल्लिखित संभावित लाभ कस्टम कर्नेल को कॉन्फ़िगर करने और बनाए रखने में मानव समय की हानि से अधिक है?
मैनुअल कर्नेल ट्यूनिंग के फायदों में से, इसका उल्लेख है प्रदर्शन को समायोजित करने, अनावश्यक घटकों को हटाने की क्षमता संकलन के दौरान, संकलन समय कम करें और कर्नेल आकार कम करें परिणामी (उदाहरण के लिए, एक प्रस्तावक कर्नेल के निर्माण में मॉड्यूल के साथ 44 एमबी लगता है, जबकि एक सार्वभौमिक कर्नेल को 294 एमबी लगता है)।
कमियों के बीच, ऐसा देखा गया है कॉन्फ़िगरेशन के दौरान गलती करना आसान है, अद्यतन के साथ संभावित समस्याएँ, असहिष्णुता, समस्याओं का निदान करने में कठिनाई।
की आपूर्ति संकलन बायनेरिज़ को सार्वभौमिक कोर माना जाता है, अपने आकार के कारण, संकलित होने में अधिक समय लेता है और एक तैयार कर्नेल वितरित करता है कम-शक्ति प्रणाली उपयोगकर्ताओं के जीवन को सरल बना सकता है।
हालांकि यह एक "विचार" के रूप में पाया जाता है, जेंटू डेवलपर्स वे इस संभावना से इंकार नहीं करते और वे इसके बारे में इसके बारे में बात कर रहे हैं, जबकि उपयोगकर्ताओं की ओर से, राय पहले से ही विभाजित है।
Si आप इसके बारे में और अधिक जानना चाहते हैं, आप मूल नोट से परामर्श ले सकते हैं निम्नलिखित लिंक।