Long Term Support Releases पर पुनर्विचार

परंपरागत रूप से Long Term Support operating system releases enterprise deployments का मुख्य आधार रही हैं। यह IBM, Oracle, Microsoft, Suse और Red Hat द्वारा उपयोग किया जाने वाला model है और कई दशकों पहले support offerings की शुरुआत से ही operating systems के आसपास की पारंपरिक सोच रही है।

अतीत में servers और desktop operating system releases दोनों के लिए इस model का पालन करना सामान्य था, लेकिन Linux space में विशेष रूप से हमने देखा कि जहाँ कम औपचारिक उत्पाद अधिक rapid, unsupported या केवल unstructured releases के साथ प्रयोग करने के लिए स्वतंत्र थे, वहाँ यह हिलने लगा। Primary product space में, openSuse, Fedora और Ubuntu ने short term support offerings या rapid release offerings प्रदान कीं। वर्षों में मापे गए release cycles और एक दशक के करीब पहुंचने वाले support cycles के बजाय उन्होंने release cycles को महीनों और support को केवल महीनों या कुछ वर्षों तक छोटा किया।

Desktop space में, मुख्य रूप से stability पर focus करने के बजाय जो servers पर सामान्य था, जल्दी नए features और applications प्राप्त करना अक्सर समझ में आता था और यह अतिरिक्त लाभ लाया कि new technologies या approaches को faster release cycle products पर long term support server products में integrated होने से पहले test किया जा सकता था। उदाहरण के लिए, Fedora उन technologies के लिए एक proving ground है जो अपने आप को साबित करने के बाद Red Hat Enterprise Linux releases में अपना रास्ता बनाएंगी। Fedora का उपयोग करके, end users को जल्दी features मिलते हैं, RHEL technologies के बारे में पहले जानने का मौका मिलता है और Red Hat को critical servers पर deploy करने से पहले बड़े पैमाने पर उत्पादों का test करने का अवसर मिलता है।

समय के साथ short term releases की stability में नाटकीय रूप से सुधार हुआ है और तेजी से इन systems को server systems के लिए viable options के रूप में देखा जाता है। ये systems नए enhancements, features और upgrades जल्दी प्राप्त करते हैं जिसे अक्सर फायदेमंद माना जाता है।

किसी भी operating system का एक प्रमुख लाभ उनका support ecosystem है, जिसमें वे packages और libraries शामिल हैं जो base operating system के हिस्से के रूप में supported और प्रदान की जाती हैं। Long term releases के साथ, हम अक्सर release के जीवनकाल में critical packages को नाटकीय रूप से पुराना होते देखते हैं जो performance, compatibility और extreme cases में security के साथ भी समस्याएं पैदा कर सकता है। यह स्पष्ट रूप से long term release operating systems के users को पुराने components की सीमाओं के साथ जीना जारी रखने या नए components को स्वयं integrate करने के बीच चुनाव करने के लिए मजबूर करता है जो अक्सर long term release उत्पाद के मूलभूत मूल्य को तोड़ देता है।

क्योंकि long term release का लक्ष्य stability और integration testing करना है, LTS की सीमाओं को “work around” करने के लिए उत्पाद के भीतर components को बदलने का मतलब है कि उन components को LTS तरीके से नहीं treat किया जा रहा है और vendor से integration testing अब संभवतः नहीं हो रही है, या यदि हो रही है, तो उसी degree तक नहीं। प्रभाव में, जो होता है वह यह है कि यह एक self-built short term release उत्पाद बन जाता है लेकिन legacy core components और कम oversight के साथ।

वास्तव में, अधिकांश मायनों में, ऐसा करना सीधे short term release उत्पाद पर जाने से भी बुरा है। Short term या rapid release उत्पाद का उपयोग करने से vendor assumed testing और integration बनाए रख सकता है, बस एक faster release और support cycle के साथ, ताकि long term release concept का सामान्य मूल्य बना रहे और operating system के सभी components के साथ, न केवल कुछ, को update किया जाए। यह partial LTS model की तुलना में अधिक standardization, industry testing और shared knowledge और integration की अनुमति देता है।

शायद operating systems के लिए long term support के मूल्य पर पुनर्विचार करने का समय आ गया है। बहुत लंबे समय से, ऐसा लगता है, इस approach का मूल्य केवल assumed और followed किया गया था, और निश्चित रूप से इसकी खूबियाँ थीं और हैं; लेकिन operating system की दुनिया इस approach के पहली बार introduce होने के बाद से बदल गई है। Updates की आवश्यकता बढ़ गई है जबकि kernels और libraries जैसी चीजों की change rates में नाटकीय रूप से कमी आई है। अधिक powerful servers ने compatibility को stack में ऊपर ले जाया है और software को OS के लिए लिखने के बजाय इसे अक्सर किसी specific version की language या run time या अन्य abstraction layer के लिए लिखा जाता है।

Shorter release cycles का मतलब है कि systems को features, top to bottom, अधिक बार मिलते हैं। “Major” releases के बीच updates छोटे और कम impactful होते हैं। Updates से changes अधिक incremental होते हैं, एक अधिक organic learning और adaptation curve प्रदान करते हैं। और सबसे महत्वपूर्ण, carefully tested और integrated system components को third party द्वारा provided versions से बदलने की आवश्यकता effectively अनसुनी हो जाती है।

Software vendors के लिए stability long term releases के लिए एक मूल्य बनी हुई है और लंबे समय तक long term releases के उपयोग की आवश्यकता का कारण बनेगी। लेकिन system administrator के लिए, इस approach का मूल्य घटता दिख रहा है और मुझे व्यक्तिगत रूप से लगता है कि हाल के वर्षों में एक inflection point मिला है। पहले दो या तीन साल packages के update होने का इंतजार करना expected और normal लगता था, लेकिन आज यह अनावश्यक रूप से बोझिल लगता है। यह increasingly सामान्य लगता है कि higher level components को newer underlying components की आवश्यकता के साथ बनाया गया है; एक expectation है कि operating systems या तो अधिक current होंगे या OS के portions को बाकी हिस्सों से अलग update किया जाएगा।

Containerization technologies पर भारी निर्भरता कुछ तरीकों से इस trend को reverse कर सकती है, लेकिन ऐसे तरीकों से जो हमेशा एक साथ long term releases के मूल्य को कम करते हैं। Containerization base operating system में व्यापक capabilities की आवश्यकता को कम करती है जिससे improved kernel, filesystem, driver और container support के लिए अधिक बार और अधिक प्रभावी ढंग से update करना आसान हो जाता है, जबकि libraries और अन्य dependencies को containers में छोड़ दिया जाता है जिससे उन applications को जिन्हें long term support dependencies की जरूरत है, उन्हें उस तरह पूरा किया जा सके और जो applications newer components से लाभ उठा सकती हैं उन्हें उस तरह संबोधित किया जा सके।

बेशक virtualization ने systems के rapid recovery और duplication को trivial बनाकर long term support models के मूल्य को कम करने में एक भूमिका निभाई है। Stability जिसकी हमें long term support releases की आवश्यकता है, उसे partially virtualization layer द्वारा संबोधित किया जाता है; hardware abstraction बहुत महत्वपूर्ण तरीकों से driver stability में सुधार करता है। उसी भावना में, devops style support models भी long term support की आवश्यकता को कम करते हैं और server ecosystems को अधिक agile और flexible बनाते हैं। System administration paradigms में trends अधिक modern operating systems को favour करती जा रही हैं।

समय बताएगा कि trends उस दिशा में जारी रहती हैं जिस दिशा में वे जा रही हैं। मेरे लिए, पिछला साल एक आँख खोलने वाला रहा है जिसमें मैंने अपने workloads को बहुत लंबे समय तक support उत्पादों के लिए दशक भर के दृढ़ समर्थन से rapid release वाले उत्पादों पर स्थानांतरित किया है और मुझे यह कहना होगा कि मैं इस बदलाव से बहुत खुश हूँ।