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

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

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

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

• एक kernel, उस version पर जिसे project ने चुना है, उन 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 एक-दूसरे के काफी करीब होते हैं, जबकि कोई भी Linux distribution किसी अन्य Unix के इतना करीब नहीं होता। जब आप server platforms के रूप में Linux और FreeBSD की तुलना करते हैं, तो इस बात को ध्यान में रखना महत्वपूर्ण है, जहाँ kernel और base userland एक ही project द्वारा बनाए जाते हैं और एक साथ release किए जाते हैं। Linux पर ये हिस्से अलग-अलग upstreams से आते हैं, और distribution वह चीज है जो उन्हें एक साथ काम करने के लिए सहमत करती है।

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

1993 और 1994 में शुरू हुए तीन प्रोजेक्ट्स आगे चलकर परिवार बने: Slackware, Debian और Red Hat। आज VPS कंट्रोल पैनल में मौजूद लगभग हर इमेज या तो इनमें से एक है या इनकी वंशज है। एक वंशज अपने पूर्वज के पैकेज फॉर्मेट, फाइल लेआउट और आमतौर पर रिलीज की आदतों को विरासत में लेती है, यही कारण है कि ब्रांडिंग हटा देने के बाद भी एक Debian derivative बिल्कुल Debian जैसा ही महसूस होता है।

स्वतंत्र (independents) वितरण अपनी अलग श्रेणी के हकदार हैं, क्योंकि उन्होंने किसी को fork नहीं किया था। Arch, Gentoo, Alpine, NixOS और Void, इन सभी ने अपने स्वयं के पैकेज मैनेजर और अपने नियम खुद लिखे। इनमें से दो, Arch और Alpine, अंततः आपके प्रोवाइडर की इमेज लिस्ट में शामिल हो गए, जिसके कारण डेस्कटॉप से संबंधित नहीं थे।

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

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

1992 में Peter MacDonald द्वारा release किया गया SLS (Softlanding Linux System) और आगे बढ़ा और इसमें 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 फरवरी 2022 में आया, जो 14.2 के छह साल बाद था।

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

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

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

Debian ने फिर इन शर्तों को लिखित रूप दिया। Debian Social Contract और DFSG (Debian free software guidelines) को July 1997 में अपनाया गया, और 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 पुराना दिखता है और बेहतर काम करता है: फ्रीज होने पर वर्जन नंबर रुक जाते हैं जबकि सुरक्षा फिक्स उनमें बैकपोर्ट किए जाते रहते हैं।

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

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

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

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

2003 में आया Red Hat Linux 9 मूल श्रृंखला का अंतिम संस्करण था। कंपनी ने इसे दो भागों में विभाजित कर दिया: नवंबर 2003 में Fedora Core 1 को एक तेज़ community release के रूप में, और RHEL (Red Hat Enterprise Linux) को, जो 2002 में Advanced Server 2.1 के रूप में शुरू हुआ था, एक धीमी और सशुल्क (paid) सेवा के रूप में। इसका कारण स्पष्ट है। एक ही product वह स्थान नहीं हो सकता जहाँ नए versions का परीक्षण हो और साथ ही वह platform भी हो जिसे एक बैंक दस वर्षों तक बिना किसी बदलाव के चलाए। ये दोनों भाग आपस में जुड़े हुए हैं: RHEL का एक major version Fedora के एक release से branch होता है, स्थिर (stabilize) होता है, और फिर freeze कर दिया जाता है। package tool भी इसी schedule पर आगे बढ़ा, 2000 के दशक में yum से लेकर 2015 में Fedora के default के रूप में dnf तक, और दोनों के आधार में rpm रहा।

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

CentOS की शुरुआत 2004 में एक सरल उद्देश्य के साथ हुई थी: Red Hat द्वारा प्रकाशित source packages को लेना, उनके ट्रेडमार्क हटाना, उन्हें फिर से बनाना (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 ने उस वर्ष के अंत में साझा sources प्रकाशित करने के लिए OpenELA की स्थापना की।

यदि किसी प्रदाता की इमेज लिस्ट में अभी भी 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 रिलीज में पैकेज इम्पोर्ट करने के साथ होती है। ये इम्पोर्ट चक्र के बीच में आने वाले Debian Import Freeze तक चलते हैं, और उसके बाद Ubuntu अपने स्वयं के बदलाव लागू करता है। कई Ubuntu पैकेज, Debian पैकेज और एक डेल्टा (delta) का मिश्रण होते हैं, और changelog में इसका विवरण दिया जाता है।

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

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

apt-cache policy nginx

यदि रिपॉजिटरी लाइन /main पर समाप्त होती है, तो इसका मतलब है कि उस पैकेज की जिम्मेदारी Canonical की सुरक्षा टीम की है। यदि लाइन /universe पर समाप्त होती है, तो इसका मतलब है कि यह कम्युनिटी द्वारा प्रबंधित है। इंटरनेट का सामना करने वाली किसी भी चीज़ के लिए इसकी जाँच करें।

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

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

Rolling release में विफलता का एक ही तरीका है, और यह हर बार स्वयं द्वारा आमंत्रित होता है। pacman -Sy foo के साथ केवल एक package install करने से package database refresh हो जाती है और फिर एक नया binary install होता है जो disk पर मौजूद libraries से नए version से linked होता है। इसके बाद programs इस तरह विफल होते हैं:

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

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

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

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

Alpine की शुरुआत लगभग 2005 में LEAF (Linux embedded appliance framework) के एक फोर्क के रूप में हुई थी, जो स्वयं Linux Router Project से निकला था। Natanael Copa ने इसे डेस्कटॉप के बजाय एप्लायंसेज के लिए बनाया था। यह अधिकांश सामान्य यूजरलैंड को बदल देता है: 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 को खरीदने के बाद, Fedora CoreOS ने 2019 में इसे सर्वर पर पेश किया। 2020 में Container Linux के रिटायर होने के बाद Flatcar Container Linux ने मूल Container Linux को जारी रखा। openSUSE MicroOS btrfs स्नैपशॉट्स और transactional-update के माध्यम से उसी लक्ष्य तक पहुँचता है। 2024 में Red Hat ने RHEL में एक इमेज-आधारित मोड जोड़ा, जो bootc पर निर्मित है, जहाँ ऑपरेटिंग सिस्टम एक कंटेनर इमेज के रूप में आता है और मशीन को एक नए टैग पर पॉइंट करके अपडेट किया जाता है। Talos Linux सबसे आगे है और शेल तथा SSH को पूरी तरह से हटा देता है: मशीन को एक API के माध्यम से कॉन्फ़िगर किया जाता है, इसलिए लॉग इन करने के लिए कुछ भी नहीं होता है। NixOS, जिसे पहली बार 2007 में रिलीज़ किया गया था, एक अलग दिशा से आता है। पूरा सिस्टम एक घोषणात्मक (declarative) कॉन्फ़िगरेशन से बनाया गया है, और पिछली जनरेशन बूट करने योग्य बनी रहती हैं।

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

FAQ

एक release को कितने समय तक support किया जाता है?

Release policy वह हिस्सा है जिसके साथ आप किसी distribution पर सबसे लंबे समय तक रहते हैं, और इसे वर्षों की संख्या के रूप में प्रकाशित किया जाता है। यहाँ 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 के लिए यहाँ कोई पंक्ति नहीं है, क्योंकि एक rolling distribution में support करने के लिए कोई release नहीं होती। Arch के लिए जो संख्या मायने रखती है वह यह है कि आप किसी मशीन को कितने समय तक बिना छुए छोड़ सकते हैं, और इसे सप्ताहों में मापा जाता है।

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

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

यह चुनाव आपको केवल एक पैकेज मैनेजर से अधिक के लिए प्रतिबद्ध करता है। यह उस अपग्रेड को निर्धारित करता है जिसे आप तीन साल बाद चलाएंगे, और ये परिवार के आधार पर पूरी तरह से अलग होते हैं। Debian और Ubuntu इन-प्लेस मेजर अपग्रेड का समर्थन करते हैं। Red Hat परिवार इन्हें leapp के माध्यम से चलाता है। Arch में कोई अपग्रेड नहीं होता क्योंकि इसका कोई वर्जन नहीं होता। Alpine का तरीका /etc/apk/repositories को एडिट करना और apk upgrade --available को चलाना है। यह चुनाव यह भी तय करता है कि आप बिना किसी थर्ड-पार्टी रिपॉजिटरी को जोड़े कौन सा सॉफ्टवेयर इंस्टॉल कर सकते हैं, जब आपके द्वारा चलाए जा रहे किसी सॉफ्टवेयर में CVE (कॉमन वल्नेरेबिलिटीज़ एंड एक्सपोज़र) एंट्री आती है तो पैच कौन जारी करता है, और आपका भविष्य का सॉफ्टवेयर किस 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 माउंट किया जाता है, एक अपडेट को एक पूर्ण नए ट्री के रूप में स्टेज किया जाता है, और स्विच रीबूट पर होता है, जिसमें पिछला ट्री रोलबैक के लिए बूट एंट्री के रूप में रखा जाता है। आपको एक ऐसी मशीन मिलती है जो या तो पूरी तरह से अपडेटेड होती है या बिल्कुल नहीं, जिसमें आधा-अधूरा अपडेट होने की स्थिति नहीं होती। आप फ़ाइलों को सीधे एडिट करके सॉफ़्टवेयर इंस्टॉल करने की सुविधा खो देते हैं, इसलिए एप्लिकेशन कंटेनरों में या लेयर्ड पैकेज में चले जाते हैं।