Linux distributions का इतिहास और उनका विकास

Linux distribution वास्तव में क्या है

Linux distributions का इतिहास एक कमी से शुरू होता है: Linux kernel अपने आप में ऐसा कुछ नहीं करता जिसे कोई व्यक्ति उपयोग कर सके। यह बूट होता है और हार्डवेयर को ढूंढता है। फिर यह रुक जाता है। किसी को इसमें userland जोड़ना पड़ता है, यह चुनना पड़ता है कि software कैसे install और update होगा, और वर्षों तक इसे ठीक करते रहने का वादा करना पड़ता है। एक distribution उन विकल्पों का समूह है, साथ ही उन लोगों का समूह है जो बाद में इसे बनाए रखते हैं।

इसके पाँच भाग होते हैं। इनमें से किसी एक को भी बदलने पर आपको एक अलग distribution मिलता है, भले ही अधिकांश binaries मेल खाती हों:

• एक kernel, जिसे project ने एक विशेष version पर चुना हो, और जिसमें उनके द्वारा जोड़े गए patches और drivers हों।
• एक userland: C library, shell, init system, और standard commands।
• एक package format, और उसे install करने वाला tool।
• एक release policy: क्या बदल सकता है, कितनी बार, और प्रत्येक release को कितने समय तक ठीक रखा जाएगा।
• लोग: package maintainers, एक security team, और कोई ऐसा व्यक्ति जो package के खराब होने पर जवाब दे सके।

Kernel साझा हिस्सा है, इसलिए दो Linux distributions एक-दूसरे के इतने करीब होते हैं जितने कि वे किसी अन्य Unix के करीब नहीं होते। जब आप server platforms के रूप में Linux और FreeBSD की तुलना करते हैं, तो इस बात को ध्यान में रखना महत्वपूर्ण है, जहाँ kernel और base userland एक ही project द्वारा बनाए जाते हैं और एक साथ release किए जाते हैं। Linux पर ये हिस्से अलग-अलग upstreams से आते हैं, और distribution वह माध्यम है जो उन्हें एक साथ काम करने के लिए सहमत करता है।

Linux distributions का तीन परिवारों में इतिहास

1993 और 1994 में शुरू हुए तीन प्रोजेक्ट्स आगे चलकर परिवार बने: Slackware, Debian और Red Hat। आज VPS कंट्रोल पैनल में मौजूद लगभग हर image इन्हीं में से एक है या इनकी वंशज है। एक वंशज अपने पूर्वज के package format, file layout और आमतौर पर release habits को विरासत में प्राप्त करती है, यही कारण है कि branding हटा देने के बाद भी एक Debian derivative, Debian जैसा ही महसूस होता है।

स्वतंत्र distributions अपनी अलग श्रेणी के हकदार हैं, क्योंकि उन्होंने किसी को fork नहीं किया था। Arch, Gentoo, Alpine, NixOS और Void में से प्रत्येक ने अपना package manager और अपने नियम स्वयं लिखे। इनमें से दो, Arch और Alpine, अंततः आपके provider की image list में शामिल हो गए, जिसके कारण desktop से संबंधित नहीं थे।

1992: परिवारों से पहले के डिस्ट्रिब्यूशन

MCC Interim Linux फरवरी 1992 में सामने आया, जिसे Manchester Computing Centre में Owen Le Blanc द्वारा तैयार किया गया था। इसने kernel और GNU (GNU's not Unix) टूल्स को दो floppy images पर एक menu-driven installer के साथ रखा। इसका अस्तित्व इसलिए था क्योंकि मैन्युअल रूप से ऐसा करने में एक दिन का काम लगता था।

SLS (Softlanding Linux System), जिसे 1992 में Peter MacDonald द्वारा release किया गया, ने इससे आगे बढ़कर X (the X Window System) और TCP/IP नेटवर्किंग को जोड़ा। SLS ही वह कारण है कि distribution शब्द का आज जो अर्थ है, वह क्यों है। यह buggy भी था और इसका रखरखाव धीमा था, और 1993 में दो लोगों ने अलग-अलग इसे ठीक करने का निर्णय लिया। एक ने इसे फिर से बनाया। दूसरे ने लिखित नियमों के साथ शुरुआत से काम शुरू किया।

Slackware, 1993: सबसे पुराना परिवार जो अभी भी उपलब्ध है

Patrick Volkerding ने 16 July 1993 को Slackware 1.00 release किया, जिसे SLS से बनाया गया था और उसमें से bugs हटा दिए गए थे। इसका रखरखाव आज भी जारी है, जो इसे Linux distribution का सबसे पुराना जीवित परिवार बनाता है।

Slackware package एक compressed tar archive होता है जिसके अंदर एक install script होती है। इसमें dependency resolution नहीं होता है: कोई भी यह जांच नहीं करता है कि आपके नए package को जिस library की आवश्यकता है, वह disk पर पहले से मौजूद है या नहीं। इसी एक निर्णय ने बाकी सब कुछ निर्धारित किया। यदि tool dependencies को resolve नहीं करेगा, तो जो set उपलब्ध कराया गया है उसे निर्माण के समय ही सुसंगत होना चाहिए, इसलिए releases दुर्लभ और रूढ़िवादी रहती हैं। Slackware 15.0, 14.2 के छह साल बाद, February 2022 में आया।

यह परिवार छोटा है। 1990 के दशक के मध्य में SUSE के शुरुआती releases Slackware पर आधारित थे, इससे पहले कि यह project YaST और बाद में RPM package format के साथ अपने रास्ते पर चला गया। यह अंतिम हिस्सा लोगों को भ्रमित करता है। SUSE और openSUSE, RPM packages का उपयोग करते हैं, और वे Red Hat के derivatives नहीं हैं। format ने यात्रा की, लेकिन lineage (वंशावली) ने नहीं।

Debian, 1993: एक सोशल कॉन्ट्रैक्ट और तीन सुइट वाली पाइपलाइन

Ian Murdock ने 16 अगस्त 1993 को Debian की घोषणा की, जो Slackware के तीन सप्ताह बाद और उसी कारण से आई थी। यह नाम उनकी पार्टनर Debra और उनके खुद के नाम को जोड़कर बना है। जनवरी 1994 में Debian Manifesto आया जिसने शर्तें तय कीं: इस डिस्ट्रिब्यूशन को किसी कंपनी द्वारा नहीं, बल्कि स्वयंसेवकों द्वारा खुले तौर पर मेंटेन किया जाएगा।

इसके बाद Debian ने शर्तें लिखित रूप में तैयार कीं। जुलाई 1997 में Debian Social Contract और DFSG (Debian free software guidelines) को अपनाया गया, और 1998 में DFSG ही Open Source Definition का आधार बना। एक डिस्ट्रिब्यूशन में क्या शामिल होना चाहिए, यह तय करने के लिए लिखा गया दस्तावेज़ अंततः पूरे उद्योग के लिए एक लाइसेंस श्रेणी को परिभाषित करने वाला बन गया। यही कारण है कि आपके sources.list में अलग-अलग घटक हैं: main में वह सॉफ्टवेयर होता है जो गाइडलाइन्स को पूरा करता है, contrib और non-free में वह होता है जो नहीं करता, और Debian 12 ने non-free-firmware को जोड़ा ताकि वायरलेस कार्ड वाला लैपटॉप बिना किसी परेशानी के इंस्टॉल हो सके।

टूलिंग इसकी दूसरी विरासत है। dpkg एक पैकेज इंस्टॉल करता है और कुछ भी गायब होने पर मना कर देता है, साथ ही dpkg: dependency problems prevent configuration of प्रिंट करता है। APT (advanced package tool), जो 1999 में Debian 2.1 के साथ डिफ़ॉल्ट बना, वह लेयर है जो यह तय करती है कि और क्या लाना है और किस क्रम में। हर Debian आधारित सिस्टम पर हर apt कमांड उसी कार्य से निकली है।

रिलीज़ मशीन में तीन सुइट और एक नियम है। एक मेंटेनर unstable में अपलोड करता है, जिसका कोडनेम हमेशा sid रहता है। एक स्क्रिप्ट लगभग 5 से 10 दिनों के बाद पैकेज को testing में माइग्रेट कर देती है, यदि वह रिलीज़ आर्किटेक्चर पर बिल्ड हो गया हो और उसमें कोई नया रिलीज़ क्रिटिकल बग न आया हो। इसके बाद testing फ्रीज़ हो जाती है, रिलीज़ टीम बाकी बचे काम को पूरा करती है, और जब बग लिस्ट काफी छोटी हो जाती है तो stable रिलीज़ होती है। यह किसी तारीख पर आधारित नहीं है। यही कारण है कि Debian stable पुराना दिखता है और बेहतर काम करता है: फ्रीज़ के समय वर्ज़न नंबर रुक जाते हैं जबकि सुरक्षा सुधार (security fixes) उनमें बैकपोर्ट किए जाते रहते हैं।

गवर्नेंस भी लिखित रूप में है, जिसमें एक निर्वाचित प्रोजेक्ट लीडर और बाध्यकारी जनरल रेजोल्यूशन होते हैं। 2014 में उस मशीनरी ने systemd को डिफ़ॉल्ट init सिस्टम के रूप में चुना, और जिन लोगों ने असहमति जताई उन्होंने Devuan को फोर्क किया, जिसने 2017 में अपनी पहली रिलीज़ दी। Debian इस बदलाव को करने वाला न तो पहला डिस्ट्रिब्यूशन था और न ही आखिरी, और ऐसा बार-बार क्यों होता रहा, साथ ही वे आपत्तियां जो सही साबित हुईं, उन्हें systemd ने SysV init की जगह कैसे ली, इसका विवरण में देखा जा सकता है। इसके बड़े वंशजों में Ubuntu, Raspberry Pi OS, Proxmox VE, Kali और Linux Mint शामिल हैं।

Red Hat, 1994: RPM, और फिर Fedora तथा RHEL में विभाजन

Marc Ewing ने 1994 में Halloween के आसपास पहला Red Hat Linux जारी किया। Bob Young की कंपनी ने 1995 में इसे खरीद लिया, और दोनों ने मिलकर Linux का पहला ऐसा व्यवसाय खड़ा किया जो सॉफ्टवेयर के बजाय सपोर्ट बेचता था। Red Hat 11 August 1999 को सार्वजनिक (public) हुई। IBM ने जुलाई 2019 में लगभग 34 बिलियन डॉलर में इस कंपनी का अधिग्रहण पूरा किया, इसलिए वह वितरण (distribution) जिसके लिए अधिकांश एंटरप्राइज सॉफ्टवेयर प्रमाणित (certified) होते हैं, तब से IBM की संपत्ति है।

इसका स्थायी तकनीकी योगदान RPM (Red Hat package manager) है, जिसे 1995 में Red Hat Linux 2.0 के लिए Erik Troan और Marc Ewing ने लिखा था। एक RPM अपनी निर्भरताओं (dependencies) को घोषित करता है, और इसे एक spec file से तैयार किया जाता है, जो एक ऐसी build recipe है जिसे कोई भी चला सकता है। यही दूसरी विशेषता है जिसने बाद में Red Hat के एंटरप्राइज उत्पाद के स्वतंत्र पुनर्निर्माण (independent rebuilds) को संभव बनाया।

2003 में आया Red Hat Linux 9 मूल श्रृंखला का अंतिम संस्करण था। कंपनी ने इसे दो भागों में विभाजित कर दिया: नवंबर 2003 में Fedora Core 1 को तेज कम्युनिटी रिलीज के रूप में, और RHEL (Red Hat Enterprise Linux) को, जो 2002 में Advanced Server 2.1 के रूप में शुरू हुआ था, धीमे भुगतान वाले संस्करण के रूप में। इसका कारण स्पष्ट है। एक ही उत्पाद वह स्थान नहीं हो सकता जहाँ नए संस्करणों का परीक्षण हो और साथ ही वह प्लेटफॉर्म भी हो जिसे एक बैंक दस वर्षों तक बिना किसी बदलाव के चलाए। ये दोनों भाग आपस में जुड़े हुए हैं: एक RHEL प्रमुख संस्करण Fedora रिलीज से निकलता है, स्थिर होता है, और फिर फ्रीज कर दिया जाता है। पैकेज टूल भी इसी समय-सारणी पर आगे बढ़ा, 2000 के दशक में yum से लेकर 2015 में Fedora के डिफ़ॉल्ट के रूप में dnf तक, और दोनों के नीचे rpm का उपयोग होता रहा।

CentOS ने RHEL का मुफ्त रीबिल्ड होना क्यों बंद कर दिया

CentOS की शुरुआत 2004 में एक सरल कार्य के साथ हुई थी: Red Hat द्वारा प्रकाशित source packages को लेना, उनके trademarks हटाना, उन्हें rebuild करना और परिणाम को मुफ्त में उपलब्ध कराना। एक दशक तक यह डिफ़ॉल्ट मुफ्त सर्वर डिस्ट्रिब्यूशन बना रहा और 2014 में Red Hat ने इस प्रोजेक्ट को अपने अधीन ले लिया।

8 दिसंबर 2020 को Red Hat ने घोषणा की कि CentOS Linux 8 का अंत 31 दिसंबर 2021 को होगा, जो कि घोषित तिथि से आठ साल पहले था, और यह नाम CentOS Stream के रूप में जीवित रहेगा। Stream एक रीबिल्ड नहीं है। यह वह ब्रांच है जिससे RHEL के minor releases तैयार किए जाते हैं, इसलिए यह RHEL के पीछे चलने के बजाय उससे आगे चलता है। जिस मशीन को आप वर्षों तक चलाना चाहते हैं, उसके लिए 'आगे' चलना गलत दिशा है, क्योंकि आपको Red Hat के भुगतान करने वाले ग्राहकों से पहले बदलाव मिलते हैं।

2021 में दो रीबिल्ड सामने आए। Rocky Linux की शुरुआत Gregory Kurtzer ने की, जो CentOS के सह-संस्थापक थे। AlmaLinux को CloudLinux द्वारा वित्तपोषित किया गया था। जून 2023 में Red Hat ने CentOS Stream और अपने कस्टमर पोर्टल के अलावा कहीं भी RHEL sources प्रकाशित करना बंद कर दिया। Rocky ने समान रीबिल्ड के लक्ष्य को बनाए रखा। AlmaLinux ने अपना लक्ष्य बदलकर ABI (application binary interface) कम्पैटिबिलिटी कर लिया, जिसका अर्थ है कि RHEL के लिए बनाया गया सॉफ़्टवेयर उस पर चलता है, बिना इस वादे के कि बग लिस्ट लाइन-दर-लाइन मेल खाती है। Oracle, SUSE और CIQ ने उस वर्ष के अंत में OpenELA की स्थापना की ताकि साझा sources प्रकाशित किए जा सकें। 2003 के विभाजन से लेकर 2023 के सोर्स बदलाव तक और प्रत्येक रीबिल्ड अब क्या वादा करता है, इस पूरे घटनाक्रम को Red Hat, CentOS, Rocky और AlmaLinux के विस्तृत विवरण में देखा जा सकता है।

यदि किसी प्रोवाइडर की इमेज लिस्ट में अभी भी CentOS लिखा है, तो उस पर कुछ भी बनाने से पहले यह पता लगा लें कि उसका क्या अर्थ है।

cat /etc/os-release

NAME="CentOS Stream" एक रोलिंग डेवलपमेंट ब्रांच है जो RHEL का आधार है। NAME="AlmaLinux" या NAME="Rocky Linux" एक रीबिल्ड है जो इसका अनुसरण करता है, जिसमें दस साल की समय-सीमा होती है।

Ubuntu 20.04: Debian unstable का एक कैलेंडर-आधारित स्नैपशॉट

Ubuntu 4.10 को 20 अक्टूबर 2004 को जारी किया गया था, जिसे Mark Shuttleworth द्वारा वित्तपोषित किया गया था। Debian के साथ इसका संबंध भावनात्मक से अधिक यांत्रिक है। प्रत्येक चक्र की शुरुआत Debian unstable से नए Ubuntu release में पैकेज आयात करने के साथ होती है। ये आयात चक्र के बीच में आने वाले Debian Import Freeze तक चलते हैं, और उसके बाद Ubuntu अपने स्वयं के बदलाव लागू करता है। कई Ubuntu पैकेज, Debian पैकेज और एक डेल्टा (delta) का मिश्रण होते हैं, और changelog में यह जानकारी दी जाती है।

इसका दूसरा पहलू कैलेंडर है। Debian तब जारी होता है जब वह तैयार होता है। Ubuntu अप्रैल और अक्टूबर में जारी होता है, और version number तारीख के आधार पर होता है: 24.04 अप्रैल 2024 में आया था। हर दूसरा अप्रैल release एक LTS (long term support) होता है, और जब कोई प्रदाता बिना किसी अतिरिक्त विवरण के Ubuntu को सूचीबद्ध करता है, तो उसका अर्थ यही होता है। सर्वर पर दोनों में से कौन सा उपयोग करना है, यह Ubuntu LTS और interim releases के बीच चयन का मुख्य विषय है, और एक LTS से अगले LTS पर जाने की अपनी प्रक्रिया है, जो 24.04 से 26.04 अपग्रेड में वर्णित है।

एक विवरण जो हर साल सर्वर एडमिन को उलझाता है, वह है Ubuntu archive का घटकों (components) में विभाजित होना। main को पूरे support window के लिए Canonical द्वारा बनाए रखा जाता है। universe समुदाय द्वारा प्रबंधित है, और इसकी सुरक्षा कवरेज का वादा अलग है। apt install इन दोनों के बीच के अंतर के बारे में कोई जानकारी नहीं देता है। एक कमांड इसे स्पष्ट करती है:

apt-cache policy nginx

/main पर समाप्त होने वाली repository line का अर्थ है कि उस पैकेज की जिम्मेदारी Canonical की सुरक्षा टीम की है। /universe पर समाप्त होने वाली line का अर्थ है कि इसकी जिम्मेदारी समुदाय की है। इंटरनेट के सामने आने वाली किसी भी सेवा के लिए इसकी जाँच अवश्य करें।

Arch, 2002: rolling releases और partial upgrade की कीमत

Judd Vinet ने 11 March 2002 को Arch 0.1 release किया, जिसमें उन्होंने स्वयं द्वारा लिखा गया package manager, pacman, और plain shell scripts के रूप में build recipes का उपयोग किया। Arch में कोई versioned releases नहीं होते हैं। Install media केवल rolling repositories के दिनांकित snapshots होते हैं, इसलिए 2019 में install की गई और हर हफ्ते update होने वाली मशीन आज install की गई मशीन जैसा ही Arch चला रही है। AUR (Arch user repository) में उपयोगकर्ताओं द्वारा योगदान दी गई build recipes होती हैं। ये केवल recipes हैं, न कि review किए गए packages, इसलिए उन्हें चलाने से पहले PKGBUILD को पढ़ना काम का हिस्सा है।

Rolling release का एक विफलता मोड (failure mode) है, जो हर बार स्वयं द्वारा आमंत्रित किया जाता है। pacman -Sy foo के साथ एक single package install करने पर package database refresh हो जाती है और फिर एक ऐसी नई binary install होती है जो डिस्क पर मौजूद libraries से अधिक नए version पर आधारित होती है। इसके बाद programs इस तरह विफल हो जाते हैं:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

समर्थित ऑपरेशन pacman -Syu है, जो सब कुछ एक साथ update करता है। यह project ऐसी news entries भी पोस्ट करता है जो बताती हैं कि कुछ upgrades से पहले manual intervention की आवश्यकता है, और उन्हें पढ़े बिना upgrade चलाने से मशीन boot न होने की स्थिति में आ सकती है।

यह Arch को ऐसे सर्वर के लिए एक खराब विकल्प बनाता है जिसे आप अनदेखा करने की योजना बना रहे हैं। साप्ताहिक रूप से update होने वाली मशीन ठीक है। एक साल बाद एक बार update की जाने वाली मशीन आपको एक ही बार में वे सभी छूटे हुए interventions दे देगी जिन्हें आपने नजरअंदाज किया था।

Alpine: एक छोटा डिस्ट्रीब्यूशन जिसे कंटेनरों ने प्रसिद्ध बनाया

Alpine की शुरुआत लगभग 2005 में LEAF (Linux embedded appliance framework) के एक फोर्क के रूप में हुई थी, जो स्वयं Linux Router Project से निकला था। Natanael Copa ने इसे डेस्कटॉप के बजाय उपकरणों (appliances) के लिए बनाया था। यह अधिकांश सामान्य userland को बदल देता है: GNU C library के स्थान पर musl, GNU core utilities के स्थान पर BusyBox, systemd के स्थान पर OpenRC, और पैकेज मैनेजर के रूप में apk का उपयोग करता है। 2014 में आया Alpine 3.0 वह रिलीज़ था जिसमें musl को अपनाया गया था।

कंटेनरों ने इसे लोकप्रिय बना दिया। एक Alpine बेस लेयर का आकार Debian या Ubuntu बेस की तुलना में बहुत छोटा होता है, इसलिए 2016 के बाद से यह एक सामान्य बेस इमेज बन गया। बहुत से लोग जो कभी Alpine इंस्टॉल नहीं करते थे, वे भी इसे हर दिन चलाते थे।

इसकी कीमत यह है कि musl, glibc नहीं है, और यह अंतर उन बग्स के रूप में सामने आता है जो असंबंधित लगते हैं। glibc के साथ लिंक की गई एक बाइनरी Alpine पर एक ऐसे संदेश के साथ विफल हो जाती है जो लोगों को एक ऐसी फाइल खोजने के लिए प्रेरित करता है जो पहले से ही वहां मौजूद है:

sh: ./myapp: not found

प्रोग्राम मौजूद है। इसका ELF इंटरप्रेटर मौजूद नहीं है, क्योंकि glibc का लोडर अनुपस्थित है। Python एक और नियमित आश्चर्य है: manylinux के लिए बनी प्रीबिल्ट व्हील्स musl पर इंस्टॉल नहीं होंगी, इसलिए pip सोर्स से कंपाइल करने पर वापस चला जाता है और तब रुक जाता है जब कोई कंपाइलर इंस्टॉल नहीं होता है। 2021 के musllinux व्हील स्टैंडर्ड ने उन प्रोजेक्ट्स के लिए इसे ठीक कर दिया जो उन व्हील्स को प्रकाशित करते हैं, बाकी किसी के लिए नहीं।

VPS पर होस्ट ऑपरेटिंग सिस्टम के रूप में, Alpine छोटा इंस्टॉल होता है और तेजी से अपडेट होता है, लेकिन यह आपको उस रास्ते से हटा देता है जिसे अधिकांश डॉक्यूमेंटेशन मानकर चलते हैं। हर गाइड जो आपको systemctl enable चलाने के लिए कहती है, उसे rc-update add में अनुवादित करने की आवश्यकता होती है।

अपरिवर्तनीय पीढ़ी: एटॉमिक अपडेट और इमेज-आधारित सर्वर

नवीनतम शाखा पैकेज सूची के बजाय अपडेट मॉडल को बदलती है। एक ostree-आधारित सिस्टम /usr को read only रखता है। एक अपडेट एक पूर्ण नया फाइलसिस्टम ट्री होता है, जिसे डाउनलोड और स्टेज किया जाता है, और अगले रीबूट पर उस पर स्विच किया जाता है। पिछला ट्री बूट एंट्री के रूप में बना रहता है, इसलिए खराब अपडेट को पुराने ट्री में रीबूट करके ठीक किया जा सकता है।

Fedora Silverblue ने 2018 में इसे डेस्कटॉप पर पेश किया और 2018 में Red Hat द्वारा CoreOS को खरीदने के बाद, 2019 में Fedora CoreOS इसे सर्वर पर ले आया। 2020 में जब Container Linux को रिटायर किया गया, तो Flatcar Container Linux ने मूल Container Linux को जारी रखा। openSUSE MicroOS btrfs स्नैपशॉट्स और transactional-update के माध्यम से उसी स्थिति तक पहुँचता है। 2024 में Red Hat ने RHEL में एक इमेज-आधारित मोड जोड़ा, जो bootc पर निर्मित है, जहाँ ऑपरेटिंग सिस्टम एक कंटेनर इमेज के रूप में आता है और मशीन को एक नए टैग पर पॉइंट करके अपडेट किया जाता है। Talos Linux सबसे आगे है और शेल तथा SSH को पूरी तरह से हटा देता है: मशीन को एक API के माध्यम से कॉन्फ़िगर किया जाता है, इसलिए लॉग इन करने के लिए कुछ भी नहीं होता है। NixOS, जिसे पहली बार 2007 में रिलीज़ किया गया था, एक अलग दिशा से आता है। पूरा सिस्टम एक घोषणात्मक कॉन्फ़िगरेशन से बनाया गया है, और पिछली पीढ़ियाँ बूट करने योग्य बनी रहती हैं।

आपका प्रदाता शायद इनमें से किसी को भी वन-क्लिक इमेज के रूप में पेश नहीं करता है, क्योंकि वे उम्मीद करते हैं कि इन्हें SSH पर फाइलों को संपादित करने वाले एडमिनिस्ट्रेटर के बजाय Ignition या cloud-init द्वारा पहले बूट पर कॉन्फ़िगर किया जाएगा। ये कई समान मशीनों पर लाभ देते हैं, जो कि वह स्थिति है जिसमें आप तब होते हैं जब आप एक साथ कई Linux सर्वर प्रबंधित कर रहे होते हैं और आपको प्रत्येक को दूसरे के समान सिद्ध करने की आवश्यकता होती है।

एक release कितने समय तक supported रहता है?

Release policy वह हिस्सा है जिसके साथ आप सबसे लंबे समय तक काम करते हैं, और इसे वर्षों की संख्या के रूप में प्रकाशित किया जाता है। यहाँ 5 वर्तमान सर्वर releases के लिए समय-सीमा दी गई है।

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine प्रत्येक 3.x branch को 2 वर्षों तक support करता है, इसीलिए यह ऐसे container image के लिए बेहतर है जिसे आप अक्सर rebuild करते हैं, न कि ऐसे host के लिए जिसे आप लंबे समय तक बिना छुए छोड़ देते हैं। Debian की security team एक stable release को लगभग 3 वर्षों तक cover करती है, और इसके बाद LTS team सामान्य architectures को कुल मिलाकर लगभग 5 वर्षों तक support देती है। Ubuntu LTS आपको main में मौजूद packages के लिए 5 वर्ष देता है, और Ubuntu Pro subscription इसे बढ़ाकर 10 वर्ष कर देता है, जो व्यक्तिगत उपयोग के लिए सीमित मशीनों पर मुफ्त है। RHEL 10 10 वर्षों की घोषणा करता है, जिसे paid extended life cycle support add-on बढ़ाकर 13 कर देता है। AlmaLinux 10 बिना किसी subscription के RHEL की 10 वर्षों की समय-सीमा का पालन करता है, और यही इन rebuilds के अस्तित्व का मुख्य कारण है।

Arch के लिए यहाँ कोई row नहीं है, क्योंकि एक rolling distribution में support करने के लिए कोई निश्चित release नहीं होता। Arch के लिए जो संख्या मायने रखती है वह यह है कि आप किसी मशीन को कितने समय तक बिना अपडेट किए छोड़ सकते हैं, और इसे सप्ताहों में मापा जाता है।

आपकी VPS इमेज लिस्ट ऐसी क्यों दिखती है

एक प्रदाता उन इमेजेस को उपलब्ध कराता है जिन्हें ग्राहक नाम से मांगते हैं और जो उनके हाइपरवाइजर पर बिना किसी मानवीय हस्तक्षेप के इंस्टॉल हो जाती हैं। यही कारण है कि लगभग हर लिस्ट Ubuntu LTS और Debian stable के साथ शुरू होती है, उन लोगों के लिए AlmaLinux या Rocky जोड़ती है जिनका सॉफ्टवेयर RHEL के लिए प्रमाणित है, और Alpine, Arch तथा Fedora को लिस्ट में नीचे रखती है। एक बार जब आप जान जाते हैं कि VPS क्या है और इमेज डिस्क तक कैसे पहुँचती है, तो यह पैटर्न स्पष्ट हो जाता है: प्रदाता ऐसे ऑपरेटिंग सिस्टम चुन रहा है जो unattended install के बाद सही ढंग से काम करते हैं और औसत ग्राहक द्वारा सर्वर रखने की अवधि से अधिक समय तक सपोर्टेड रहते हैं।

यह चुनाव आपको केवल एक पैकेज मैनेजर से अधिक के लिए प्रतिबद्ध करता है। यह उस अपग्रेड को निर्धारित करता है जिसे आप तीन साल बाद चलाएंगे, और ये परिवार के आधार पर पूरी तरह से अलग होते हैं। Debian और Ubuntu इन-प्लेस मेजर अपग्रेड का समर्थन करते हैं। Red Hat परिवार इन्हें leapp के माध्यम से चलाता है। Arch का कोई अपग्रेड नहीं होता क्योंकि इसका कोई वर्जन नहीं होता। Alpine का तरीका /etc/apk/repositories को एडिट करना और apk upgrade --available चलाना है। यह चुनाव यह भी तय करता है कि आप बिना किसी थर्ड-पार्टी रिपॉजिटरी को जोड़े कौन सा सॉफ्टवेयर इंस्टॉल कर सकते हैं, जब आपके द्वारा चलाए जा रहे किसी सॉफ्टवेयर में CVE (common vulnerabilities and exposures) एंट्री आती है तो पैच कौन जारी करता है, और आपका भविष्य का सॉफ्टवेयर किस init सिस्टम और C लाइब्रेरी को मौजूद मानेगा।

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

FAQ

मेरा सर्वर किस Linux distribution परिवार का है?

cat /etc/os-release चलाएं। ID फ़ील्ड distribution का नाम बताती है और ID_LIKE उसके परिवार का नाम, इसलिए एक Ubuntu मशीन ID_LIKE=debian रिपोर्ट करती है और एक AlmaLinux मशीन ID_LIKE="rhel centos fedora" रिपोर्ट करती है। पैकेज मैनेजर भी इसका एक संकेत है। apt और dpkg का मतलब Debian परिवार है, dnf और rpm का मतलब Red Hat परिवार है, apk का मतलब Alpine है, और pacman का मतलब Arch है।

क्या CentOS अभी भी RHEL का एक मुफ्त संस्करण है?

नहीं। CentOS Linux 8, जो उस नाम का अंतिम रीबिल्ड था, 31 December 2021 को समाप्त हो गया, और CentOS Linux 7 का जीवनकाल 30 June 2024 को समाप्त हो गया। जीवित प्रोजेक्ट, CentOS Stream, वह शाखा है जिससे RHEL के माइनर रिलीज़ बनाए जाते हैं, इसलिए इसमें बदलाव RHEL से पहले आते हैं, बाद में नहीं। पुरानी भूमिका लेने वाले मुफ्त रीबिल्ड AlmaLinux और Rocky Linux हैं, और दोनों ही दस साल के सपोर्ट विंडो के साथ आते हैं।

Debian stable इतने पुराने वर्ज़न नंबर क्यों देता है?

क्योंकि वर्ज़न नंबर स्थिर रहता है जबकि सुधार आते रहते हैं। Debian अपने रिलीज़ किए गए वर्ज़न में सुरक्षा पैच को बैकपोर्ट करता है, न कि नए अपस्ट्रीम रिलीज़ को इम्पोर्ट करता है, इसलिए जो पैकेज 2.4.57-2+deb13u1 दिखाता है, उसमें पिछले सप्ताह प्रकाशित सुधार शामिल हो सकते हैं। अपस्ट्रीम वर्ज़न के बाद का सफ़िक्स Debian रिवीज़न है, और apt changelog <package> यह बताता है कि इसमें क्या शामिल किया गया है। वर्ज़न नंबरों के आधार पर Debian सर्वर की सुरक्षा का आकलन करना हमेशा गलत परिणाम देता है।

क्या मुझे VPS पर Arch जैसी रोलिंग रिलीज़ चलानी चाहिए?

केवल तभी जब आप इसे एक निश्चित शेड्यूल पर अपडेट करेंगे। एक रोलिंग डिस्ट्रीब्यूशन यह मानकर चलता है कि हर मशीन वर्तमान पैकेज सेट पर है, इसलिए pacman -Sy foo के साथ एक पैकेज को अपडेट करने से लाइब्रेरी बेमेल हो सकती हैं और cannot open shared object file जैसी त्रुटियां आ सकती हैं। नियमित रूप से pacman -Syu चलाएं, प्रत्येक रन से पहले प्रोजेक्ट न्यूज़ पेज पढ़ें, और सिस्टम स्थिर रहेगा। यदि आप इसे एक साल के लिए छोड़ देते हैं, तो पहला अपग्रेड जोखिम भरा हो जाता है।

एक immutable या atomic डिस्ट्रीब्यूशन वास्तव में क्या बदलता है?

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