Linux distributions चा इतिहास आणि त्यांची family tree

प्रत्यक्षात Linux distribution म्हणजे काय

Linux distribution चा इतिहास एका उणिवेपासून सुरू होतो: Linux kernel स्वतःहून एखादी व्यक्ती वापरू शकेल असे काहीही करत नाही. तो boot होतो आणि hardware शोधतो. त्यानंतर तो थांबतो. कोणीतरी userland जोडणे, software कसे install आणि update करायचे हे ठरवणे आणि अनेक वर्षे त्यातील त्रुटी दुरुस्त करत राहण्याची जबाबदारी घेणे आवश्यक असते. Distribution म्हणजे या निवडींचा संच आणि त्यानंतरही हे काम सुरू ठेवणारा समुदाय.

त्याचे पाच भाग असतात. यांपैकी कोणताही एक भाग बदलला, तर बहुतांश binaries समान असल्या तरी वेगळी distribution तयार होते:

• प्रकल्पाने निवडलेला version असलेला kernel, त्यात जोडलेले 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 एकमेकांच्या अधिक जवळ असतात; त्यांपैकी कोणतीही distribution दुसऱ्या Unix च्या तुलनेत तितकी जवळची नसते. Linux आणि FreeBSD चे server platforms म्हणून तुलनात्मक स्वरूप पाहताना ही बाब लक्षात ठेवणे उपयुक्त ठरते. FreeBSD मध्ये kernel आणि base userland एकाच प्रकल्पाद्वारे तयार करून एकत्र release केले जातात. Linux मध्ये हे भाग स्वतंत्र upstream projects कडून येतात. त्यांना परस्पर सुसंगत बनवणारी गोष्ट म्हणजे distribution.

Linux वितरणांच्या तीन कुटुंबांचा इतिहास

1993 आणि 1994 मध्ये सुरू झालेले तीन प्रकल्प पुढे स्वतंत्र कुटुंबे बनले: Slackware, Debian आणि Red Hat. आज VPS control panel मधील जवळजवळ प्रत्येक image यांपैकी एक असते किंवा त्यांपैकी एखाद्या वितरणाची descendant असते. descendant मध्ये package format, file layout आणि सामान्यतः release पद्धती वारशाने येतात. त्यामुळे branding काढून टाकल्यानंतरही Debian derivative वापरताना Debian सारखाच अनुभव येतो.

स्वतंत्र वितरणांसाठी स्वतंत्र उल्लेख आवश्यक आहे, कारण त्यांचा उगम कोणत्याही दुसऱ्या वितरणाच्या fork मधून झाला नाही. Arch, Gentoo, Alpine, NixOS आणि Void यांनी आपापले package manager आणि आपापले नियम तयार केले. त्यांपैकी Arch आणि Alpine ही दोन वितरणे शेवटी तुमच्या provider च्या image list मध्ये आली. यामागील कारणांचा desktop शी संबंध नव्हता.

1992: families येण्यापूर्वीच्या distributions

MCC Interim Linux फेब्रुवारी 1992 मध्ये Manchester Computing Centre येथे Owen Le Blanc यांनी assemble केले. त्यामध्ये kernel आणि GNU (GNU's not Unix) tools दोन floppy images मध्ये menu-driven installer सह ठेवले होते. हे आवश्यक होते, कारण ते काम हाताने केल्यास एक दिवसाचा कामाचा वेळ लागत असे.

Peter MacDonald यांनी 1992 मध्ये release केलेल्या SLS (Softlanding Linux System) ने आणखी पुढे जाऊन X (the X Window System) आणि TCP/IP networking जोडले. distribution या शब्दाचा आजचा अर्थ रूढ होण्यामागे SLS हे कारण आहे. त्यात bugs देखील होते आणि त्याची maintenance संथ होती. त्यामुळे 1993 मध्ये दोन व्यक्तींनी स्वतंत्रपणे त्यात सुधारणा करण्याचे ठरवले. त्यांपैकी एकाने ते पुन्हा build केले. दुसऱ्याने लिखित नियमांपासून नव्याने सुरुवात केली.

Slackware, 1993: आजही releases करणारी सर्वात जुनी family

Patrick Volkerding यांनी 16 July 1993 रोजी Slackware 1.00 release केले. ते SLS वर आधारित होते आणि त्यातील bugs काढून टाकण्यात आले होते. Slackware चे आजही maintenance केले जाते. त्यामुळे ती आजही अस्तित्वात असलेली सर्वात जुनी Linux distribution आहे.

Slackware package हा त्यात install script असलेला compressed tar archive असतो. Dependency resolution होत नाही. तुमच्या नवीन package ला आवश्यक असलेली library disk वर आधीपासून आहे का, हे काहीही तपासत नाही. या एका निर्णयाचा पुढील सर्व रचनेवर परिणाम झाला. Tool dependencies resolve करत नसेल, तर shipped set रचनेनुसारच सुसंगत असला पाहिजे. त्यामुळे releases दुर्मिळ आणि सावध पद्धतीने केले जातात. Slackware 15.0 हे 14.2 नंतर सहा वर्षांनी, February 2022 मध्ये आले.

ही family लहान आहे. 1990 च्या दशकाच्या मध्यातील SUSE चे सुरुवातीचे releases Slackware वर आधारित होते. त्यानंतर project ने YaST आणि पुढे RPM package format स्वीकारून स्वतंत्र मार्ग निवडला. शेवटचा भाग अनेकांना गोंधळात टाकतो. SUSE आणि openSUSE RPM packages वापरतात. त्या Red Hat derivatives नाहीत. Format पुढे गेला. Lineage गेला नाही.

Debian, 1993: सामाजिक करार आणि तीन suite असलेली release pipeline

Ian Murdock यांनी 16 August 1993 रोजी Debian ची घोषणा केली. Slackware नंतर तीन आठवड्यांनी आणि त्याच कारणासाठी ही घोषणा झाली. या नावात त्यांच्या सहकारी Debra यांच्या नावाचा आणि त्यांच्या स्वतःच्या नावाचा संयोग आहे. Debian Manifesto जानेवारी 1994 मध्ये प्रसिद्ध झाला आणि त्यात अटी स्पष्ट करण्यात आल्या: हे distribution कंपनीकडून नव्हे, तर स्वयंसेवकांकडून मुक्तपणे देखभाल केले जाईल.

त्यानंतर Debian ने या अटी लेखी स्वरूपात निश्चित केल्या. Debian Social Contract आणि DFSG (Debian free software guidelines) जुलै 1997 मध्ये स्वीकारले गेले. 1998 मध्ये DFSG हे Open Source Definition चे आधार बनले. एका distribution मध्ये काय समाविष्ट असावे हे निश्चित करण्यासाठी लिहिलेल्या दस्तऐवजाने अखेरीस संपूर्ण उद्योगासाठी license ची एक category निश्चित केली. तुमच्या sources.list मध्ये components असण्याचे हेच कारण आहे: main मध्ये guidelines पूर्ण करणारे software असते, contrib आणि non-free मध्ये त्या पूर्ण न करणारे software असते, आणि Debian 12 मध्ये non-free-firmware जोडले गेले, जेणेकरून wireless card असलेल्या laptop वर अनेक ठिकाणी शोधाशोध न करता installation करता येईल.

Tooling हा दुसरा महत्त्वाचा वारसा आहे. dpkg एक package install करते आणि काहीतरी missing असल्यास installation नाकारते; तेव्हा dpkg: dependency problems prevent configuration of प्रदर्शित केले जाते. 1999 मध्ये Debian 2.1 पासून default झालेले APT (advanced package tool) हे आणखी काय आणि कोणत्या क्रमाने fetch करायचे ते ठरवणारे layer आहे. प्रत्येक Debian derivative मधील प्रत्येक apt command या कामातून विकसित झाले आहे.

Release machine मध्ये तीन suites आणि एक नियम आहे. Maintainer package unstable मध्ये upload करतो. त्याचा permanent codename sid आहे. Release architectures वर package build झाले आणि नवीन release critical bug आढळला नाही, तर साधारण 5 ते 10 दिवसांनंतर script package testing मध्ये migrate करते. त्यानंतर testing freeze केली जाते. Release team उरलेल्या समस्यांचे निराकरण करते आणि bug list पुरेशी लहान झाल्यावर stable release केले जाते. हे एखाद्या निश्चित तारखेला होत नाही. त्यामुळे Debian stable जुने दिसते आणि विश्वसनीयपणे कार्य करते: freeze वेळी version numbers थांबतात, पण security fixes त्यात backport केले जातात.

Governance देखील लेखी स्वरूपात निश्चित आहे. यात निवडून दिलेला project leader आणि बंधनकारक general resolutions यांचा समावेश आहे. 2014 मध्ये या यंत्रणेने systemd ला default init system म्हणून निवडले. याला असहमत असलेल्या लोकांनी Devuan fork केले आणि त्याचे पहिले release 2017 मध्ये झाले. हा बदल करणारे Debian पहिले distribution नव्हते आणि शेवटचेही नव्हते. हा बदल वारंवार का झाला, तसेच कोणते आक्षेप नंतर योग्य ठरले, याचा मागोवा systemd ने SysV init ची जागा कशी घेतली याच्या विवरणात घेतला आहे. यापासून निर्माण झालेले मोठे descendants म्हणजे Ubuntu, Raspberry Pi OS, Proxmox VE, Kali आणि Linux Mint.

Red Hat, 1994: RPM, त्यानंतर Fedora आणि RHEL मध्ये विभाजन

Marc Ewing ने Halloween 1994 च्या सुमारास पहिले Red Hat Linux जारी केले. Bob Young यांच्या कंपनीने ते 1995 मध्ये विकत घेतले. त्यानंतर दोघांनी software विकण्याऐवजी support विकणारा पहिला Linux व्यवसाय उभारला. Red Hat 11 August 1999 रोजी सार्वजनिक कंपनी झाली. IBM ने July 2019 मध्ये सुमारे 34 billion dollars ला कंपनीचे acquisition पूर्ण केले. त्यामुळे बहुतेक enterprise software ज्या distribution विरुद्ध प्रमाणित केले जाते, ती distribution तेव्हापासून IBM च्या मालकीची आहे.

दीर्घकाळ टिकलेले तांत्रिक योगदान म्हणजे RPM (Red Hat package manager). Erik Troan आणि Marc Ewing यांनी ते 1995 मध्ये Red Hat Linux 2.0 साठी लिहिले. RPM मध्ये त्याच्या dependencies घोषित केलेल्या असतात. ते spec file पासून तयार केले जाते. ही अशी build recipe आहे जी कोणीही चालवू शकतो. या दुसऱ्या वैशिष्ट्यामुळे Red Hat च्या enterprise product ची स्वतंत्रपणे पुन्हा build केलेली रूपे नंतर शक्य झाली.

2003 मधील Red Hat Linux 9 ही मूळ मालिकेतील शेवटची आवृत्ती होती. कंपनीने तिचे दोन भाग केले: November 2003 मध्ये जलद community release म्हणून Fedora Core 1, आणि 2002 मध्ये Advanced Server 2.1 म्हणून सुरू झालेले RHEL (Red Hat Enterprise Linux) हे संथ, सशुल्क product. कारण स्पष्ट आहे. नवीन आवृत्त्यांची चाचणी केली जाते असे ठिकाण आणि एखादी bank दहा वर्षे कोणताही बदल न करता चालवते असे platform, ही दोन्ही भूमिका एकाच product ला निभावता येत नाहीत. हे दोन्ही भाग परस्पर जोडलेले आहेत: RHEL major version एखाद्या Fedora release मधून branch केली जाते, ती stabilise केली जाते आणि नंतर freeze केली जाते. Package tool देखील त्याच वेळापत्रकानुसार बदलले: 2000s मधील yum पासून 2015 मध्ये Fedora चे default असलेल्या dnf पर्यंत; दोन्हींच्या खाली rpm होते.

CentOS ने मोफत RHEL rebuild म्हणून काम करणे का थांबवले

CentOS ची सुरुवात 2004 मध्ये एका साध्या उद्देशाने झाली: Red Hat ने प्रकाशित केलेली source packages घ्या, त्यांवरील trademarks काढा, त्या पुन्हा build करा आणि तयार झालेला परिणाम मोफत वितरित करा. एक दशकभर ते मोफत server distribution चे default बनले. 2014 मध्ये Red Hat ने हा project आपल्या संस्थेत समाविष्ट केला.

8 December 2020 रोजी Red Hat ने जाहीर केले की CentOS Linux 8 चे वितरण 31 December 2021 रोजी थांबवले जाईल. ही तारीख आधी प्रकाशित केलेल्या तारखेपेक्षा आठ वर्षे आधीची होती. तसेच CentOS हे नाव CentOS Stream म्हणून पुढे सुरू राहील, असेही जाहीर करण्यात आले. Stream हा rebuild नाही. RHEL minor releases ज्या branch मधून तयार केल्या जातात, ती branch म्हणजे Stream. त्यामुळे तो RHEL च्या मागे नसून पुढे चालतो. एखादे machine अनेक वर्षे वापरण्याचा तुमचा उद्देश असेल, तर पुढे चालणारी branch चुकीची निवड आहे. कारण Red Hat च्या paying customers ना बदल मिळण्यापूर्वीच ते बदल तुम्हाला मिळतात.

2021 मध्ये दोन rebuilds उपलब्ध झाले. CentOS चे सह-संस्थापक Gregory Kurtzer यांनी Rocky Linux सुरू केले. AlmaLinux ला CloudLinux ने funding दिली. June 2023 मध्ये Red Hat ने RHEL sources CentOS Stream आणि आपल्या customer portal व्यतिरिक्त इतर कोणत्याही ठिकाणी प्रकाशित करणे थांबवले. Rocky चे लक्ष्य identical rebuilds तयार करणेच राहिले. AlmaLinux ने आपले उद्दिष्ट ABI (application binary interface) compatibility असे बदलले. याचा अर्थ RHEL साठी build केलेले software चालते; परंतु bug list प्रत्येक ओळीत तंतोतंत जुळेल, अशी हमी नसते. त्याच वर्षी नंतर Oracle, SUSE आणि CIQ यांनी shared sources प्रकाशित करण्यासाठी OpenELA स्थापन केले. 2003 मधील विभाजनापासून 2023 मधील source बदलापर्यंतचा आणि सध्या प्रत्येक rebuild कशाची हमी देतो याचा संपूर्ण क्रम Red Hat, CentOS, Rocky आणि AlmaLinux यांचा अधिक सविस्तर आढावा येथे दिला आहे.

एखाद्या provider च्या image list मध्ये अजूनही CentOS असे लिहिले असेल, तर त्यावर build करण्यापूर्वी ते नेमके कोणते CentOS आहे हे शोधा.

cat /etc/os-release

NAME="CentOS Stream" ही RHEL कडे नेणारी rolling development branch आहे. NAME="AlmaLinux" किंवा NAME="Rocky Linux" हा तिच्यामागे चालणारा rebuild आहे आणि त्यासाठी दहा वर्षांचा कालावधी उपलब्ध असतो.

Ubuntu, 2004: दिनदर्शिकेवर Debian unstable चा snapshot

Ubuntu 4.10 हे Mark Shuttleworth यांच्या निधीतून 20 October 2004 रोजी released झाले. Debian सोबतचे त्याचे नाते भावनिक नसून यांत्रिक आहे. प्रत्येक cycle ची सुरुवात Debian unstable मधून नवीन Ubuntu release मध्ये packages import करून होते. हे imports cycle च्या मध्यावर होणाऱ्या Debian Import Freeze पर्यंत सुरू राहतात. त्यानंतर Ubuntu स्वतःचे बदल करते. अनेक Ubuntu packages म्हणजे Debian package सोबतचा एक delta असतो. कोणता delta आहे हे changelog मध्ये नमूद केलेले असते.

दुसरा भाग म्हणजे release calendar. Debian तयार झाल्यावर release करते. Ubuntu April आणि October मध्ये release होते. Version number ही तारीख दर्शवते: 24.04 हे April 2024 मध्ये released झाले. प्रत्येक दुसरा April release हा LTS (long term support) असतो. Provider Ubuntu कोणत्याही qualifier शिवाय सूचीबद्ध करते, तेव्हा त्याचा अर्थ LTS असतो. Server वर या दोनपैकी कोणता release वापरायचा, हा Ubuntu LTS आणि interim releases मधील निवडीचा मुख्य विषय आहे. एका LTS वरून पुढील LTS कडे जाण्यासाठी स्वतंत्र procedure आहे. त्याचे वर्णन 24.04 ते 26.04 upgrade मध्ये केले आहे.

दरवर्षी server admins च्या लक्षात येणारा एक तपशील आहे. Ubuntu चे archive components मध्ये विभागलेले आहे. main हे पूर्ण support window साठी Canonical maintain करते. universe हे community maintain करते. त्याचे security coverage वेगळ्या आश्वासनावर आधारित असते. apt install मध्ये हा फरक दिसत नाही. तो पाहण्यासाठी एक command वापरा:

apt-cache policy nginx

/main ने समाप्त होणाऱ्या repository line चा अर्थ त्या package ची जबाबदारी Canonical च्या security team कडे आहे. /universe ने समाप्त होणाऱ्या line चा अर्थ ती जबाबदारी community कडे आहे. इंटरनेटला सामोरे जाणाऱ्या कोणत्याही गोष्टीसाठी हे तपासा.

Arch, 2002: rolling releases आणि partial upgrade ची किंमत

Judd Vinet यांनी 11 March 2002 रोजी स्वतः लिहिलेल्या package manager pacman आणि साध्या shell scripts असलेल्या build recipes सह Arch 0.1 जारी केले. Arch मध्ये versioned releases मुळीच नाहीत. Install media हे त्याच rolling repositories चे दिनांकित snapshots असतात. त्यामुळे 2019 मध्ये install करून दर आठवड्याला update केलेले machine आणि आज install केलेले machine एकच Arch चालवतात. AUR (Arch user repository) मध्ये users ने योगदान दिलेल्या build recipes असतात. त्या reviewed packages नसतात. त्यामुळे त्या चालवण्यापूर्वी PKGBUILD वाचणे हे कामाचा भाग आहे.

Rolling model मध्ये एक failure mode आहे. तो प्रत्येक वेळी स्वतःच्या चुकीमुळे निर्माण होतो. pacman -Sy foo वापरून एकच package install केल्यास package database refresh होते आणि disk वरील libraries पेक्षा नवीन libraries विरुद्ध linked असलेली एक नवीन binary install होते. त्यानंतर programs अशा प्रकारे fail होतात:

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

समर्थित operation pacman -Syu आहे. ते सर्वकाही एकत्र update करते. काही upgrades करण्यापूर्वी manual intervention आवश्यक असल्याचे सांगणाऱ्या news entries project कडून प्रसिद्ध केल्या जातात. त्या न वाचता upgrade चालवल्यास machine boot न होण्याची शक्यता असते.

यामुळे दुर्लक्ष करण्याची योजना असलेल्या server साठी Arch हा खराब पर्याय ठरतो. दर आठवड्याला update केलेला box योग्य प्रकारे चालतो. एकदा update करून वर्षभराने पुन्हा update केलेला box मात्र चुकलेल्या सर्व interventions एकाच run मध्ये तुमच्यासमोर आणतो.

Alpine: containers मुळे प्रसिद्ध झालेली लहान distribution

Alpine ची सुरुवात सुमारे 2005 मध्ये LEAF (Linux embedded appliance framework) च्या fork म्हणून झाली. LEAF स्वतः Linux Router Project मधून विकसित झाले होते. Natanael Copa ने Alpine desktops ऐवजी appliances साठी तयार केले. Alpine ने नेहमीच्या userland मधील बहुतांश घटक बदलले: GNU C library ऐवजी musl, GNU core utilities ऐवजी BusyBox, systemd ऐवजी OpenRC आणि package manager म्हणून apk. 2014 मधील Alpine 3.0 हा musl कडे स्थलांतर करणारा release होता.

Containers मुळे Alpine लोकप्रिय झाले. Alpine base layer चा आकार Debian किंवा Ubuntu base च्या तुलनेत खूपच लहान असतो. त्यामुळे 2016 पासून ते सामान्य base image बनले. Alpine कधीही install न केलेले अनेक लोक ते दररोज वापरू लागले.

याची किंमत अशी आहे की musl हे glibc नाही. हा फरक परस्पर असंबंधित वाटणाऱ्या bugs मध्ये दिसतो. glibc शी linked असलेला binary Alpine वर अशा संदेशासह fail होतो की लोक आधीपासून उपलब्ध असलेली file शोधू लागतात:

sh: ./myapp: not found

Program उपलब्ध आहे. मात्र त्याचा ELF interpreter उपलब्ध नाही, कारण glibc loader अनुपस्थित आहे. Python हा आणखी एक नेहमीचा अनपेक्षित भाग आहे: manylinux साठी build केलेले prebuilt wheels musl वर install होत नाहीत. त्यामुळे pip source पासून compile करण्याकडे वळते आणि compiler install केलेला नसल्यास थांबते. 2021 मधील musllinux wheel standard ने ही समस्या ते wheels publish करणाऱ्या projects साठी सोडवली; इतरांसाठी नाही.

VPS वरील host operating system म्हणून Alpine लहान आकारात install होते आणि जलद updates मिळवते. मात्र बहुतेक documentation ज्या पद्धतीची गृहीत धरते, त्यापेक्षा वेगळ्या मार्गावर ते तुम्हाला आणते. प्रत्येक guide मध्ये systemctl enable चालवण्यास सांगितले असल्यास, त्याचे rc-update add मध्ये रूपांतर करावे लागते.

अपरिवर्तनीय generation: atomic updates आणि image आधारित servers

नवीन branch package list ऐवजी update model बदलतो. ostree आधारित system /usr read only ठेवतो. Update म्हणजे संपूर्ण नवीन filesystem tree असतो. तो download करून staged केला जातो आणि पुढील reboot वेळी switch केला जातो. मागील tree boot entry म्हणून ठेवला जातो. त्यामुळे खराब update झाल्यास जुन्या tree मध्ये reboot करून तो पूर्ववत करता येतो.

Fedora Silverblue ने 2018 मध्ये ही पद्धत desktop वर आणली. Red Hat ने 2018 मध्ये CoreOS खरेदी केल्यानंतर Fedora CoreOS ने 2019 मध्ये ती servers साठी आणली. 2020 मध्ये Container Linux retire झाल्यानंतर Flatcar Container Linux ने मूळ Container Linux ची परंपरा पुढे चालू ठेवली. openSUSE MicroOS btrfs snapshots आणि transactional-update द्वारे त्याच परिणामापर्यंत पोहोचते. 2024 मध्ये Red Hat ने RHEL मध्ये bootc वर आधारित image आधारित mode जोडला. या mode मध्ये operating system container image म्हणून ships होते आणि machine ला नवीन tag कडे point करून update केले जाते. Talos Linux यापेक्षा पुढे जाते आणि shell तसेच SSH पूर्णपणे काढून टाकते. Machine API द्वारे configure केली जाते, त्यामुळे त्यात log in करण्यासाठी काहीही उपलब्ध नसते. 2007 मध्ये प्रथम release झालेले NixOS वेगळ्या मार्गाने त्याच परिणामापर्यंत पोहोचते. संपूर्ण system एका declarative configuration मधून build केले जाते आणि मागील generations bootable राहतात.

तुमचा provider यापैकी कोणतेही system one click image म्हणून देत नसण्याची शक्यता आहे. कारण administrator ने SSH द्वारे files edit करण्याऐवजी first boot वेळी Ignition किंवा cloud-init द्वारे configuration करणे अपेक्षित असते. अनेक समान machines वर ही पद्धत उपयुक्त ठरते. तुम्ही एकाच वेळी अनेक Linux servers manage करत असताना आणि प्रत्येक server इतरांसारखाच आहे हे पडताळून पाहण्याची गरज असताना हीच परिस्थिती असते.

एका release साठी support किती काळ उपलब्ध असतो?

Release policy हा distribution चा असा भाग आहे, ज्यासोबत तुम्ही सर्वाधिक काळ काम करता. ती साधारणपणे वर्षांच्या संख्येत प्रकाशित केली जाते. सध्या उपलब्ध असलेल्या 5 server 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 देते. त्यामुळे वारंवार rebuild केली जाणारी container image म्हणून ती, दीर्घकाळ न बदलता ठेवलेल्या host पेक्षा अधिक योग्य ठरते. Debian ची security team stable release साठी सुमारे 3 वर्षे support देते. त्यानंतर LTS team सामान्य architectures साठी एकूण सुमारे 5 वर्षांपर्यंत support चालू ठेवते. Ubuntu LTS मध्ये main मधील packages साठी 5 वर्षे support मिळते. Ubuntu Pro subscription घेतल्यास हा कालावधी 10 वर्षांपर्यंत वाढतो. काही मोजक्या machines साठी वैयक्तिक वापराकरिता तो विनामूल्य आहे. RHEL 10 मध्ये 10 वर्षांचा support कालावधी प्रकाशित केला आहे. Paid extended life cycle support add-on मुळे तो 13 वर्षांपर्यंत वाढतो. AlmaLinux 10 subscription शिवाय RHEL च्या 10 वर्षांच्या support कालावधीशी जुळते. Rebuilds उपलब्ध असण्याचे हेच मुख्य कारण आहे.

Arch साठी येथे स्वतंत्र row नाही, कारण rolling distribution ला support करायची release नसते. Arch साठी महत्त्वाचा कालावधी म्हणजे तुम्ही machine किती काळ न बदलता ठेवू शकता. तो कालावधी आठवड्यांत मोजला जातो.

तुमची VPS image list अशी का दिसते

Provider ग्राहक नावाने मागणी करत असलेल्या आणि त्याच्या hypervisor वर unattended पद्धतीने install होणाऱ्या images उपलब्ध करून देतो. त्यामुळे जवळजवळ प्रत्येक list ची सुरुवात Ubuntu LTS आणि Debian stable पासून होते. RHEL विरुद्ध certified असलेले software वापरणाऱ्यांसाठी AlmaLinux किंवा Rocky जोडले जातात. Alpine, Arch आणि Fedora list मध्ये पुढे दिसतात. VPS म्हणजे काय आणि image disk पर्यंत कशी पोहोचते हे समजल्यावर ही रचना स्पष्ट होते: provider अशा operating systems ची निवड करतो, जी unattended install यशस्वीरीत्या पूर्ण करतात आणि बहुतेक ग्राहक server ठेवतात त्यापेक्षा जास्त काळ supported राहतात.

ही निवड केवळ package manager पर्यंत मर्यादित नसते. तीन वर्षांनी तुम्ही कोणता upgrade कराल हे ती ठरवते, आणि प्रत्येक family मध्ये upgrade पद्धत पूर्णपणे वेगळी असते. Debian आणि Ubuntu मध्ये in-place major upgrades समर्थित असतात. Red Hat family मध्ये ते leapp द्वारे केले जातात. Arch मध्ये version नसल्यामुळे upgrade नसतो. Alpine मध्ये /etc/apk/repositories संपादित करून apk upgrade --available चालवले जाते. या निवडीमुळे third-party repository जोडल्याशिवाय कोणते software install करता येईल, तुम्ही चालवत असलेल्या software मधील एखाद्या घटकावर CVE (common vulnerabilities and exposures) entry आल्यावर patch कोण release करेल, तसेच तुमच्या भविष्यातील software ला कोणता init system आणि C library उपलब्ध आहे असे गृहीत धरता येईल, हेही ठरते.

आणखी एक परिणाम कमी लेखणे सोपे असते. Internet वर लिहिलेली बहुतेक उत्तरे Debian family किंवा Red Hat family मधील पद्धत गृहीत धरतात. त्यामुळे या दोन्हींपेक्षा वेगळी family निवडल्यास machine च्या संपूर्ण आयुष्यभर instructions चे रूपांतर करावे लागते. तुम्ही server किती वेळा हाताळण्यास तयार आहात, त्याला अनुरूप release policy असलेली family निवडा आणि तीच वापरत राहा. त्यावरील packages बदलणे सोपे असते. त्याखालील distribution बदलण्यासाठी box पुन्हा build करावा लागतो.

FAQ

माझा सर्व्हर कोणत्या Linux distribution family मध्ये आहे?

cat /etc/os-release चालवा. ID field distribution चे नाव दाखवते आणि ID_LIKE तिची family दाखवते. त्यामुळे Ubuntu मशीन ID_LIKE=debian दाखवते आणि AlmaLinux मशीन ID_LIKE="rhel centos fedora" दाखवते. Package manager हा family ओळखण्याचा दुसरा मार्ग आहे. apt आणि dpkg यांचा अर्थ Debian family, dnf आणि rpm यांचा अर्थ Red Hat family, apk चा अर्थ Alpine आणि pacman चा अर्थ Arch असा होतो.

CentOS ही अजूनही RHEL ची विनामूल्य आवृत्ती आहे का?

नाही. त्या नावाची शेवटची rebuild असलेली CentOS Linux 8 ची देखभाल 31 December 2021 रोजी संपली आणि CentOS Linux 7 ची support lifecycle 30 June 2024 रोजी संपली. उरलेला प्रकल्प, CentOS Stream, हा RHEL minor releases तयार करण्यासाठी वापरला जाणारा branch आहे. त्यामुळे त्यात RHEL पेक्षा नंतर नव्हे, तर आधी बदल येतात. जुन्या भूमिकेची जागा घेणाऱ्या विनामूल्य rebuilds म्हणजे AlmaLinux आणि Rocky Linux. दोन्हींसाठी दहा वर्षांची support window आहे.

Debian stable मध्ये version numbers इतके जुने का असतात?

कारण fixes येत राहतात, पण version number freeze केला जातो. Debian नवीन upstream release समाविष्ट करण्याऐवजी security patches त्याने release केलेल्या version मध्ये backport करते. त्यामुळे 2.4.57-2+deb13u1 असे दिसणाऱ्या package मध्ये मागील आठवड्यात प्रकाशित केलेला fix असू शकतो. Upstream version नंतरचा suffix हा Debian revision असतो आणि apt changelog <package> त्यात समाविष्ट केलेले बदल दाखवते. Version numbers पाहून Debian server ची security ठरवणे प्रत्येक वेळी चुकीचा निष्कर्ष देते.

VPS वर Arch सारखी rolling release चालवावी का?

तुम्ही ती ठराविक वेळापत्रकानुसार update करणार असाल, तरच. Rolling distribution मध्ये प्रत्येक मशीन current package set शी सुसंगत राहणे अपेक्षित असते. त्यामुळे pacman -Sy foo वापरून एक package update केल्यास libraries विसंगत राहू शकतात आणि cannot open shared object file सारख्या errors येऊ शकतात. pacman -Syu नियमितपणे चालवा आणि प्रत्येक run पूर्वी project news page वाचा. असे केल्यास system stable राहते. ते एक वर्ष तसेच ठेवले, तर पहिला upgrade धोकादायक ठरतो.

Immutable किंवा atomic distribution प्रत्यक्षात काय बदलते?

Updates कधी लागू होतात आणि ते पूर्ववत कसे करायचे, हे बदलते. /usr read only mount केले जाते. Update पूर्ण नवीन tree म्हणून stage केले जाते आणि reboot वेळी switch केले जाते. Rollback साठी मागील tree boot entry म्हणून ठेवले जाते. त्यामुळे मशीन पूर्णपणे updated किंवा पूर्णपणे not updated अशा स्थितीत असते; अर्धवट लागू झालेली स्थिती राहत नाही. Files in place संपादित करून software install करण्याची पद्धत सोडावी लागते. त्यामुळे applications containers किंवा layered packages मध्ये हलवावी लागतात.