Linux distributions चा इतिहास आणि family tree

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

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

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

• Project ने निवडलेल्या version मधील kernel, त्याने जोडलेले patches आणि drivers यांसह.
• Userland: C library, shell, init system आणि standard commands.
• Package format आणि ते install करणारे tool.
• Release policy: काय बदलू शकते, बदल किती वेळा होतात आणि प्रत्येक release साठी किती काळ fixes दिले जातात.
• लोक: package maintainers, security team आणि package बिघडल्यावर उत्तर देणारी व्यक्ती.

Kernel हा सामायिक भाग असल्यामुळे दोन Linux distributions एकमेकांच्या जितक्या जवळ असतात, त्यापेक्षा कोणतीही एक distribution दुसऱ्या Unix च्या तुलनेत अधिक वेगळी असते. Linux आणि server platforms म्हणून FreeBSD यांची तुलना करताना ही गोष्ट लक्षात ठेवणे महत्त्वाचे आहे. तेथे kernel आणि base userland एकाच project कडून तयार करून एकत्र release केले जातात. Linux मध्ये हे भाग स्वतंत्र upstreams कडून येतात आणि त्यांच्यात सुसंगती निर्माण करणारी गोष्ट म्हणजे distribution.

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

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

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

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

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

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

Slackware, 1993: आजही releases करणारे सर्वात जुने कुटुंब

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 मध्ये आले.

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

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

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

त्यानंतर Debian ने या अटी लिखित स्वरूपात मांडल्या. Debian Social Contract आणि DFSG (Debian free software guidelines) जुलै 1997 मध्ये स्वीकारले गेले. 1998 मध्ये DFSG हे Open Source Definition चे आधार बनले. एका distribution मध्ये काय समाविष्ट असावे हे ठरवण्यासाठी लिहिलेल्या दस्तऐवजाने संपूर्ण उद्योगासाठी licence 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) हे आणखी कोणते packages आणायचे आणि कोणत्या क्रमाने आणायचे, हे ठरवणारे layer आहे. प्रत्येक Debian derivative मधील प्रत्येक apt command या कामातून विकसित झाले आहे.

Release machine मध्ये तीन suites आणि एक नियम आहे. Maintainer unstable मध्ये package upload करतो. unstable चे कायमचे codename sid आहे. Release architectures वर package build झाले आणि नवीन release-critical bug आढळला नाही, तर script साधारणपणे 5 ते 10 दिवसांनंतर 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 केले. Devuan चे पहिले release 2017 मध्ये झाले. मोठे 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 मध्ये विकत घेतले. त्यानंतर दोघांनी सॉफ्टवेअर विकण्याऐवजी support विकणारा पहिला Linux व्यवसाय उभारला. Red Hat 11 August 1999 रोजी सार्वजनिक कंपनी झाली. IBM ने July 2019 मध्ये सुमारे 34 billion dollars मध्ये कंपनीचे अधिग्रहण पूर्ण केले. त्यामुळे बहुतेक enterprise software ज्याच्या आधारावर प्रमाणित केले जाते, ते distribution तेव्हापासून IBM च्या मालकीचे आहे.

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

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

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

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

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

2021 मध्ये दोन rebuilds उपलब्ध झाले. CentOS चे सहसंस्थापक Gregory Kurtzer यांनी Rocky Linux सुरू केला. AlmaLinux ला CloudLinux ने निधी दिला. 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 स्थापन केले.

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

cat /etc/os-release

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

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

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

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

एक तपशील server admins चे दरवर्षी लक्ष वेधून घेतो. Ubuntu चे archive components मध्ये विभागलेले आहे. main ची संपूर्ण support window Canonical कडून देखरेख केली जाते. universe ची देखरेख community करते आणि त्याचे 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 रोजी Arch 0.1 release केले. त्यासोबत त्यांनी स्वतः लिहिलेला package manager, pacman, आणि साध्या shell scripts स्वरूपातील build recipes दिल्या. 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 आवश्यक असल्याचे project news entries मध्येही सांगते. त्या entries न वाचता upgrade चालवल्यास machine boot न होण्याची शक्यता असते.

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

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

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

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

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

sh: ./myapp: not found

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

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

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

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

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

तुमचा provider यापैकी कोणतेही system one-click image म्हणून देत नसण्याची शक्यता आहे. कारण administrator ने SSH द्वारे files edit करण्याऐवजी first boot वेळी Ignition किंवा cloud-init द्वारे configuration करणे अपेक्षित असते. अनेक समान machines वर ही पद्धत उपयुक्त ठरते. एकाच वेळी अनेक Linux servers व्यवस्थापित करत असताना आणि प्रत्येक 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 वर्षे मिळतात. Ubuntu Pro subscription मुळे हा कालावधी 10 वर्षांपर्यंत वाढतो. काही मोजक्या machines वर वैयक्तिक वापरासाठी तो विनामूल्य आहे. RHEL 10 साठी 10 वर्षांचा कालावधी प्रकाशित केला आहे. Paid extended life cycle support add-on मुळे तो 13 वर्षांपर्यंत वाढतो. AlmaLinux 10 कोणत्याही subscription शिवाय RHEL च्या 10 वर्षांच्या कालावधीशी जुळते. Rebuilds अस्तित्वात असण्याचे हेच मुख्य कारण आहे.

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

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

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

ही निवड फक्त package manager पुरती मर्यादित नसते. तीन वर्षांनी तुम्ही कोणता upgrade चालवाल हेही ती ठरवते, आणि प्रत्येक family मध्ये ही प्रक्रिया पूर्णपणे वेगळी असते. 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 करता येईल हेही ठरवते. तुम्ही वापरत असलेल्या एखाद्या घटकासाठी CVE (common vulnerabilities and exposures) entry प्रसिद्ध झाल्यावर patch कोण उपलब्ध करून देईल, तसेच भविष्यातील software कोणता init system आणि C library उपलब्ध आहे असे गृहीत धरेल, हे देखील यावर अवलंबून असते.

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

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 हे ओळखण्याचे आणखी एक साधन आहे. 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 life 30 June 2024 रोजी संपले. टिकून राहिलेला प्रकल्प CentOS Stream हा RHEL minor releases ज्या branch मधून तयार होतात ती branch आहे. त्यामुळे त्याला RHEL पेक्षा आधी changes मिळतात, नंतर नाही. जुन्या भूमिकेची जागा घेणाऱ्या विनामूल्य rebuilds म्हणजे AlmaLinux आणि Rocky Linux. दोन्हींसाठी ten year windows आहेत.

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

कारण fixes येत राहतात, पण version number freeze केले जाते. Debian नवीन upstream release आणण्याऐवजी प्रसिद्ध केलेल्या version मध्ये security patches 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 चालवावी का?

तुम्ही ती ठराविक schedule नुसार update करणार असाल, तरच. Rolling distribution मध्ये प्रत्येक मशीन current package set शी जुळलेली राहील असे गृहीत धरले जाते. त्यामुळे pacman -Sy foo वापरून एक package update केल्यास libraries मध्ये mismatch आणि 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 edit करून software install करण्याची पद्धत सोडावी लागते. त्यामुळे applications containers किंवा layered packages मध्ये हलवली जातात.