सिस्टमड "दुर्भावनापूर्ण" है? [बन्द है]


11

डेबियन और ज़ुबंटू के बारे में चर्चा करने वाले कुछ फ़ोरम ऑनलाइन पर जाते हुए, मैंने कुछ उपयोगकर्ताओं को देखा जो इस लाइन को हस्ताक्षर क्षेत्र में जोड़ते हैं:

... कोई प्रणाली के साथ ...

इस लाइन को गर्व के साथ दिखाया गया है (यह मुझे लगता है)।

से विकिपीडिया :

systemd सिस्टम प्रबंधन डेमॉन, लाइब्रेरी और यूटिलिटी का एक सूट है जिसे लिनक्स कंप्यूटर ऑपरेटिंग सिस्टम के लिए केंद्रीय प्रबंधन और कॉन्फ़िगरेशन प्लेटफॉर्म के रूप में डिज़ाइन किया गया है।

तो systemdयह एक बुरी बात नहीं लगती है, इसलिए लोग गर्व के साथ लिखते हैं कि वे इसका उपयोग नहीं करते हैं?

कर सकते हैं systemdखतरनाक है, या आप के लिए सिर्फ बुरा हो सकता है?


1
क्या आपने उस विकिपीडिया लेख के एडॉप्शन और रिसेप्शन भाग को पढ़ा है ? इसमें कई लेखों के संदर्भ हैं कि कुछ लोगों को यह पसंद क्यों नहीं है।
लीजए

जवाबों:


8

नहीं, यह न तो आपके लिए खतरनाक है और न ही बुरा। तुम init युद्धों की एक छोटी सी लड़ाई पर ठोकर खाई है । मैं इस बारे में विस्तार से नहीं बताऊंगा लेकिन, संक्षेप में, स्थिति इस प्रकार है।

लिनक्स अपने जीवनकाल में ज्यादातर समय sysvinit का उपयोग करता रहा है। यह पुराना है और इसमें सुविधाओं की कमी है और एक बात जो सभी को बहुत पसंद है, वह यह है कि इसे बदलने की जरूरत है। हालांकि, कोई भी इस पर सहमत नहीं हो सकता है कि इसे किस रूप में बदलना चाहिए। विभिन्न विकल्प प्रस्तावित किए गए थे, जिनमें शामिल हैं - लेकिन निम्नलिखित तक सीमित नहीं हैं:

ये दोनों अपने तरीके से अच्छे हैं और दूसरों में बुरे। जैसा कि अक्सर geek दुनिया में होता है, जो कि init प्रणाली (या तो उन दो या अन्य में से एक) को चुनने के लिए एक धार्मिक युद्ध के समान कुछ हो गया।

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

खुशी से, init युद्ध नीचे उतर रहे हैं और अब अपने प्रमुख अतीत कर रहे हैं। अधिकांश लिनक्स वितरणों ने स्विच करने का निर्णय लिया है systemd। यहां तक ​​कि कैननिकल के उबंटू, उनके पीछे के बल होने के बावजूद upstart। इसलिए, आज, systemdवास्तव में जेंटू (छवि स्रोत ) को छोड़कर, सभी बहुत बड़ी गड़बड़ियों के लिए पसंद की init प्रणाली है :

यहाँ छवि विवरण दर्ज करें


6

क्या आपने विकिपीडिया लेख पढ़ा है जिसे आपने जोड़ा है? विशेष रूप से, तीसरा पैराग्राफ।

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

" इतिहास और विवाद " शीर्षक के नीचे एक बड़ा खंड भी है ।


4

यह इस बात पर निर्भर करता है कि आप क्या दुर्भावनापूर्ण मानते हैं। उदाहरण के लिए। suckless.org इसे दुर्भावनापूर्ण मानता है:

http://suckless.org/sucks/systemd

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

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


4
आपको यह क्यों कहना चाहिए
mikeserv

1
@mikeserv: चूसना रहित पृष्ठ पर "क्योंकि" बहुत सारे हैं। :) और विकिपीडिया पृष्ठ में (स्पार्कवाक द्वारा उत्तर में उद्धृत)। मुझे लगता है कि यह बहुत जटिल है और सिस्टम पर "केंद्रीकृत" नियंत्रण भी प्रदान करता है। कोर डंप, लॉग आदि को डीबी पर संग्रहित किया जाता है। क्या होगा अगर मेरी एफएस विफल हो जाती है और डीबी दूषित हो जाता है - देखने के लिए और अधिक लॉग नहीं। गुदा करने के लिए और अधिक कोर फाइलें नहीं। सादा फ़ाइल भंडारण स्वाभाविक रूप से ऐसे मामलों में बेहतर विफलता लचीलापन प्रदान करता है। तो, हाँ - क्यों?!?
एलेक्स

coredumps और log को पत्रिकाओं और / या syslog, कंसोल, अन्य, को लिखा जा सकता है, मैं इससे असहमत नहीं हूँ , लेकिन यह जटिल हो सकता है , लेकिन मुझे नहीं लगता कि यह सीधे दुर्भावनापूर्ण अनुवाद करता है , और मुझे नहीं लगता कि यह उत्तर उस अनुवाद का समर्थन करता है।
मिकसेर्व

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

1
यह कहते हुए कि यह विशेष रूप से सिस्टमड के साथ मामला है, लेकिन स्वतंत्र सबसिस्टम का संयोजन वास्तव में विफलता प्रतिरोध बढ़ा सकता है । एक सूक्ष्म कर्नेल की तुलना एक सूक्ष्म कर्नेल कर्नेल से करें। आइए प्रदर्शन को नजरअंदाज करें और असफलता प्रतिरोध को देखें। जो विफलताओं के लिए अधिक प्रतिरोधी है: (संभावित बड़े) घटकों का एक संयोजन, अच्छी तरह से परिभाषित इंटरफेस के माध्यम से एक दूसरे के साथ बातचीत करना; या कोड का एक बड़ा एकल द्रव्यमान, जहां सब कुछ दुर्घटना से किसी भी चीज के लिए स्वतंत्र है? मुझे लगता है कि यह तर्क दिया जा सकता है कि ठीक से किया गया, माइक्रोआर्किटेक्चर विकल्प अधिक विफलता-प्रतिरोधी है।
बजे एक सीवीएन

3

उतना दुर्भावनापूर्ण नहीं जितना शायद दफ्तरी।

डिजाइनर अपनी दृष्टि से इतने भरे होते हैं कि वे उन चीजों को समझने में असफल होते हैं जो POSIX- प्रकार सिस्टम को महान बनाते हैं।

"जो लोग यूनिक्स को नहीं समझते हैं, वे इसे खराब तरीके से मजबूत करने के लिए निंदा करते हैं।"

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