मैं कुछ अलग क्षेत्रों में एक प्रौद्योगिकीविद् के रूप में काम करने के अपने अनुभव साझा करूँगा ...
(सावधानी: यह रेड हैट के बारे में एक कहानी है और मैं इसके साथ पेशेवर रूप से कैसे बड़ा हुआ)
मैंने 2000-2002 में पेशेवर रूप से लिनक्स के साथ काम करना शुरू किया। यह Red Hat और Red Hat व्यावसायिक संस्करण (6.x, 7.x, 8.0) के व्यापक अंगीकरण के दौरान था । ये मुफ्त डाउनलोड के साथ-साथ बॉक्सिंग पैक के लिए उपलब्ध थे। वे आसानी से कंप्यूटर रिटेल स्टोर में पाए जा सकते थे।
मेरे लिए, यह एक ही उत्पाद के साथ आकर्षक शौकीन और घर के उपयोगकर्ताओं को जोड़ने का लाभ था जो उद्यम में उभरने लगा था। इस समय मेरा काम कमर्शियल यूनीसेज़ (HP-UX, AIX और SCO) से ग्राहक सर्वर सिस्टम को Red Hat प्लेटफ़ॉर्म पर ले जाना था।
लागत बचत काफी थी! $ 40k Compaq ProLiant इंटेल सर्वर के साथ $ 100k + HP9000 PA-RISC सर्वर को बदलना लागत और प्रदर्शन पर एक पूर्ण जीत थी।
तो, Red Hat क्यों?
Red Hat इस बाजार में पहला था, जिसने महत्वपूर्ण व्यवसाय, विक्रेता और हार्डवेयर का समर्थन प्राप्त किया। बड़े एप्लिकेशन विक्रेताओं को देखकर Red Hat का उपयोग एक लक्ष्य प्लेटफ़ॉर्म के रूप में किया गया, जिसने डील को सील कर दिया। मेरे जैसे हॉबीस्ट उपयोगकर्ता आसानी से अपने काम के माहौल में घर पर सम्मानित किए गए कौशल को स्थानांतरित करने में सक्षम थे। समुदाय बढ़ रहा था। Slashdot , Freshmeat और LAMP ढेर शासन! यह लिनक्स के लिए एक अच्छा समय था।
इस बिंदु तक, मैं मालिकाना ईआरपी सॉफ्टवेयर समाधान के लिए एक मंच के रूप में लिनक्स वितरण के विकास और मूल्यांकन के लिए जिम्मेदार था। मैं रेड हैट से चिपक गया। हर बार, मैं एक और डिस्ट्रो ( मैंड्रेक , सुएसई , डेबियन , जेंटू ) की कोशिश करता हूं , लेकिन पैकेजिंग, हार्डवेयर समर्थन (सर्वर या बाह्य उपकरणों), ( समुदाय के आकार) या कुछ अन्य डील-ब्रेकर के साथ मुद्दों को ढूंढूंगा।
एक उदाहरण: मैं Digi सीरियल विस्तार PCI-X कार्ड और Esker VSIfax उत्पादन फैक्स सॉफ्टवेयर के साथ संगठन Compaq / HP ProLiant हार्डवेयर का उपयोग कर रहा था । बाद के दो में केवल Red Hat ऑपरेटिंग सिस्टम के लिए ड्राइवर समर्थन था। कुछ मामलों में, सॉफ़्टवेयर केवल बाइनरी या आरपीएम फॉर्म में वितरित किया गया था, अन्य लिनक्स वेरिएंट पर आसान उपयोग को छोड़कर।
सूचना प्रौद्योगिकी की दुनिया में गति मायने रखती है
कोई भी ऐसा नहीं होना चाहता जो खोने के समाधान या परियोजना की सिफारिश करता है जो अंततः अनाथ हो जाता है, इसलिए आप सुरक्षित विकल्पों के साथ चिपके रहते हैं। मैं एक प्रौद्योगिकी स्टैक का प्रबंधन कर रहा था जिसे मज़बूती से काम करने की ज़रूरत थी और समर्थन की कई परतें थीं। उस बिंदु पर एक अलग वितरण चुनना बस होगा। किया गया। गैर जिम्मेदार।
रेड हैट हनीमून मेरे लिए 2003 में सॉफ्टवेयर के पेशेवर संस्करणों के बंद होने के साथ समाप्त हुआ । Red Hat Enterprise Linux प्रतिस्थापन था और काफी सामान के साथ आया था ... लागत (महंगी सदस्यता-आधारित मॉडल), पहुंच (उपयोगकर्ता आधार और समुदाय को सिकोड़ना) और भविष्य के बारे में सामान्य भ्रम ...
मैंने विकल्प की तलाश शुरू की, जेंटू, डेबियन और SuSE का पुनर्मूल्यांकन किया। मुझे हमारी प्रौद्योगिकी स्टैक के सभी घटकों पर सही समर्थन नहीं मिल सका। मुझे रेड हैट इकोसिस्टम के साथ चिपके रहने के लिए मजबूर किया गया ... रेड हैट एंटरप्राइज लिनक्स के साथ जुड़े जंगली लागत-शिफ्ट के कारण, मैंने अपने जीवन के अंत के वर्षों के लिए एक उच्च-संशोधित Red Hat 8.0 चलाया । यह तब तक नहीं था जब तक कि RHEL क्लोन परिपक्व नहीं हुए ( व्हाइटबॉक्स लिनक्स , और बाद में, CentOS ) कि मैंने अपने मानक से हटकर एक वास्तविक कदम तैयार किया।
रेड हैट डेरिवेटिव के प्रमुख लाभ था और है भुगतान किया RHEL संस्करणों के साथ बाइनरी अनुकूलता। आरएचईएल और सेंटोस और इसके विपरीत के बीच जगह में रूपांतरण करना भी संभव है। मैंने तब तक RHEL जैसी प्रणालियों के साथ काम करना जारी रखा जब तक कि मैंने अगला कैरियर नहीं बनाया ...
मैंने बाद में खुद को उच्च-आवृत्ति वित्तीय ट्रेडिंग उद्योग में पाया , जहां मैं महत्वपूर्ण स्वचालित ट्रेडिंग सिस्टम के लिए अनुसंधान और विकास और लिनक्स इंजीनियरिंग के लिए जिम्मेदार था। सावधान परीक्षण और ट्यूनिंग के माध्यम से, इस दुनिया में जोर गति थी । फिर से, हार्डवेयर समर्थन महत्वपूर्ण था। मेरे पास विशिष्ट नेटवर्क कार्ड , विशेष हार्डवेयर होगा, सर्वर हार्डवेयर या एप्लिकेशन लाइब्रेरी जो केवल आरएचईएल या आरएचईएल जैसी प्रणालियों के लिए प्रमाणित थे। यहां तक कि ऐसे मामलों में जहां चीजें अन्य लिनक्स वेरिएंट के लिए संकलित की जा सकती हैं, सामुदायिक कारक उत्पन्न हुआ। जब मैं उस बिंदु पर था जहां मुझे एक समस्या पर शोध करने की आवश्यकता थी, तो यह अक्सर एक ऐसा मुद्दा था जिसे रेड हैट बुग्जिला रिपोर्टों में नोटों या टिप्पणियों से पता लगाया जा सकता था, या कभी-कभी, मैं बस अगले रिलीज के लिए एक पैच या अनुरोध प्रस्तुत करता हूं। ।
जैसा कि मैंने कम विलंबता नेटवर्किंग और कर्नेल ट्यूनिंग में तल्लीन करना शुरू किया, मैंने स्टॉक आरएचईएल कर्नेल और आरएचईएल एमआरजी रियलटाइम कर्नेल को विच्छेदित करना शुरू कर दिया । मैंने देखा कि जब रिलीज में कितना काम होता है ... एक वेनिला kern.org कर्नेल को 200+ पैच। टिप्पणी पढ़ें और नोट करें। आपके पास छोटी-छोटी चीजें हो सकती हैं जैसे कि sysctlएक्सपोजर या अधिक सॅन डिफाल्ट लागू। रेड हैट लोगों को इन मुद्दों को पैच करने, परीक्षण करने और ठीक करने के लिए भुगतान करता है। मैंने अन्य लिनक्स वितरणों से समान प्रतिबद्धता नहीं देखी ... इस तथ्य को जोड़ें कि एंटरप्राइज़ प्लेटफ़ॉर्म को वास्तविक सुरक्षा, बगफ़िक्स और बैकपोर्ट समर्थन के लिए वर्षों तक गारंटी दी जाती है ।
इसलिए मैं अंततः एक अन्य वित्तीय फर्म में चला गया, जो सर्वर और डेस्कटॉप पर लगभग ऑल-जेंटू था ... यह मेरे लिए एक आपदा थी। Red Hat और CentOS दुनिया से आने पर, मुझे Gentoo सेटअप के साथ कई स्थिरता और प्रबंधन समस्याओं का सामना करना पड़ा। संस्करण नियंत्रण सबसे बड़ा मुद्दा था, लेकिन सामुदायिक समर्थन में कमी और वास्तविक परीक्षण की कमी भी चिंता थी। मैंने आरएचईएल को पर्यावरण में पेश करना शुरू कर दिया क्योंकि हमारे तीसरे पक्ष के कुछ सॉफ्टवेयरों को इसकी आवश्यकता थी ...
लेकिन एक समस्या थी ... मेरे डेवलपर्स को जेंटू के लिए इस्तेमाल किया गया था और कोर पुस्तकालयों और एप्लिकेशन संस्करणों के लिए अपेक्षाकृत आसान उन्नयन पथ थे। वे निश्चित प्रमुख संस्करणों को समायोजित करने के लिए समायोजित नहीं कर सकते थे जो Red Hat Enterprise Linux मानकीकृत हैं। विकास और रिलीज की प्रक्रिया इस सवाल से त्रस्त थी कि GLIBC 2.7 को RHEL 5.x पर क्यों नहीं बनाया जा सकता है या एक निश्चित संकलक या लाइब्रेरी संस्करण क्यों उपलब्ध नहीं है। जब यह बताया गया कि आरएचईएल / सेंटोस के प्रमुख संस्करणों के बीच उन्नयन के लिए अनिवार्य रूप से पूर्ण रीबिल्ड की आवश्यकता होती है , तो वे समाधान में बहुत अधिक आत्मविश्वास खो देते हैं।
इस बिंदु पर, मैंने महसूस किया कि रेड हैट उन डेवलपर्स के लिए बहुत धीमी गति से आगे बढ़ रहा था जो रक्तस्राव / अग्रणी-किनारे पर होना चाहते थे। आरएचईएल 6.x एक बहुत ही आवश्यक और स्वागत योग्य उन्नयन था, लेकिन एक बार जब मैं स्टार्टअप और फर्मों के साथ साक्षात्कार करना शुरू कर दिया, तो यह विषय और अधिक स्पष्ट हो गया, जो कि DevOps सिद्धांतों के लिए सदस्यता ले ली ।
आज ...
डेवलपर्स और लिनक्स उपयोगकर्ताओं की बढ़ती संख्या गैर-रेड हैट, गैर-सुसी, गैर-उद्यम लिनक्स वातावरण से आ रही है।
- वे उबंटू या डेबियन का उपयोग कर रहे हैं ...
- उन्हें पुराने स्कूल के हार्डवेयर या बड़े विक्रेता के समर्थन से निपटने की जरूरत नहीं थी।
- वे ग्राउंड-अप (स्व-समर्थित) से अपने आवेदन लिख रहे हैं।
- वर्चुअलाइजेशन और क्लाउड-कंप्यूटिंग एब्स्ट्रैक्ट हार्डवेयर लेयर, इसलिए फंकी RAID कंट्रोलर ड्राइवर्स, PCI-X पेरिफेरल्स या बाइनरी-डिस्ट्रीब्यूटेड मैनेजमेंट एजेंट्स की चिंता राडार पर भी नहीं है।
- ये उपयोगकर्ता उपकरण और उपयोगकर्ता क्षेत्र चाहते हैं, जिसके वे आदी हैं।
तो एक विरोधाभास है ... इन उपयोगकर्ताओं को समझ में नहीं आता है कि वे आवेदन या पुस्तकालय संस्करणों पर प्रतिबंधित क्यों होंगे। पुराने स्कूल प्रशासक अभी भी नए प्रतिमान को समायोजित कर रहे हैं । तर्क जो धर्म में निहित प्रतीत होते हैं, वे वास्तव में केवल कार्य हैं कि कैसे लोगों ने अपने संबंधित कौशल विकसित किए।
मैंने आज एक बहुत ही वरिष्ठ DevOps Linux इंजीनियर पद के लिए नौकरी का विज्ञापन देखा जो पढ़ा:
डेबियन-आधारित लिनक्स वितरण में कुशल-से-विशेषज्ञ होना चाहिए (उबंटू और वेरिएंट ठीक। रेड हैट पास करने योग्य , लेकिन महत्वपूर्ण नहीं )
इसलिए मुझे लगता है कि यह दोनों तरीकों से काम करता है ... मैं नौकरी के अवसरों से दूर चला गया हूं क्योंकि जिन 800 सेंटोस सर्वर का मैं प्रबंधन कर रहा हूं वे उबंटू में परिवर्तित होने के लिए स्लेटेड थे। निश्चित रूप से, लिनक्स लिनक्स है ... लेकिन मुझे नहीं लगा कि मैं उतना प्रभावी हो सकता हूं जितना मैं हो सकता हूं ... मैंने डेबियन इंस्टॉलेशन के साथ ठोकर खाई है और कामना की है कि आरपीएम-आधारित डिस्ट्रो उपयोग में थे। मेरे पास विभिन्न प्लेटफार्मों की योग्यता के बारे में गर्म तर्क हैं (आमतौर पर सूची के निचले हिस्से में जेंटू रखकर)।
तो आपके पर्यावरण के लिए क्या सही है? निर्भर करता है। मैं उन फर्मों में रहा हूँ जहाँ सिस्टम इंजीनियर निर्णय लेते हैं, साथ ही साथ संगठन जहाँ डेवलपर्स राजा होते हैं। मुझे लगता है कि सबसे अच्छी व्यवस्था तब होती है जब डेवलपर्स और सिस्टम का समर्थन करने वाले लोग मंच पर सहमत होते हैं। लेकिन इसके बाहर, दीर्घकालिक समर्थन, प्रयोज्य, समुदाय के बारे में सोचें और जो आपके एप्लिकेशन को सबसे उपयुक्त तरीके से स्टैक करता है।
एक प्रतिभाशाली डेवलपर को आरएचईएल-जैसे या डेबियन जैसे वातावरण में काम करने में सक्षम होना चाहिए। और अच्छी तरह से, विकास प्लेटफार्मों को उत्पादन पर्यावरण को प्रतिबिंबित करना चाहिए। तुम वहाँ से जाओ ...