Linux distributions کی تاریخ اور خاندانی درخت

Linux distribution دراصل کیا ہے

Linux distributions کی تاریخ ایک خلا سے شروع ہوتی ہے: صرف Linux kernel ایسا کچھ نہیں کرتا جسے انسان استعمال کر سکے۔ یہ boot ہوتا ہے اور hardware تلاش کرتا ہے۔ پھر رک جاتا ہے۔ کسی کو 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 کو کتنے عرصے تک fixes ملیں گے۔
• لوگ: package maintainers، ایک security team، اور package خراب ہونے پر جواب دینے والا کوئی ذمہ دار۔

Kernel مشترک حصہ ہے، اس لیے دو Linux distributions ایک دوسرے کے بہت زیادہ قریب ہوتی ہیں بہ نسبت اس کے کہ ان میں سے کوئی دوسری Unix کے قریب ہو۔ Linux اور FreeBSD کو server platforms کے طور پر موازنہ کرتے وقت یہ بات ذہن میں رکھنا مفید ہے، جہاں kernel اور base userland ایک ہی project بناتا اور انہیں ایک ساتھ release کرتا ہے۔ Linux میں یہ اجزا الگ الگ upstreams سے آتے ہیں، اور distribution ہی وہ چیز ہے جو ان کے درمیان مطابقت پیدا کرتی ہے۔

تین خاندانوں میں Linux distributions کی تاریخ

1993 اور 1994 میں شروع ہونے والے تین projects نے خاندانوں کی شکل اختیار کی: Slackware، Debian اور Red Hat۔ آج VPS control panel میں موجود تقریباً ہر image ان میں سے کسی ایک کی، یا اس کی descendant، ہوتی ہے۔ Descendant package format، file layout اور عموماً release کے طریقے بھی ورثے میں لیتی ہے۔ اسی لیے branding ختم ہونے کے بعد بھی Debian derivative، Debian ہی جیسی محسوس ہوتی ہے۔

Independents کے لیے الگ سطر ضروری ہے، کیونکہ یہ کسی project سے fork نہیں ہوئے تھے۔ Arch، Gentoo، Alpine، NixOS اور Void، ہر ایک نے اپنا package manager اور اپنے اصول بنائے۔ ان میں سے دو، Arch اور Alpine، آخرکار آپ کے provider کی image list میں بھی شامل ہو گئے، لیکن اس کی وجوہات desktop سے متعلق نہیں تھیں۔

1992: distributions سے پہلے کے خاندان

MCC Interim Linux فروری 1992 میں Manchester Computing Centre میں Owen Le Blanc نے تیار کیا۔ اس میں kernel اور GNU (GNU's not Unix) tools کو menu-driven installer کے ساتھ floppy images کے ایک جوڑے میں شامل کیا گیا۔ یہ اس لیے بنایا گیا تھا کہ یہ کام ہاتھ سے کرنے میں ایک دن لگتا تھا۔

SLS (Softlanding Linux System) کو Peter MacDonald نے 1992 میں جاری کیا۔ اس میں X (the X Window System) اور TCP/IP networking بھی شامل کی گئی۔ لفظ distribution آج جس معنی میں استعمال ہوتا ہے، اس کی بنیاد SLS نے رکھی۔ تاہم اس میں bugs بہت تھے اور اس کی maintenance بھی سست تھی۔ 1993 میں دو افراد نے الگ الگ طور پر اسے درست کرنے کا فیصلہ کیا۔ ایک نے اسے دوبارہ build کیا۔ دوسرے نے تحریری اصولوں کے ساتھ نئے سرے سے آغاز کیا۔

Slackware، 1993: اب بھی جاری ہونے والا قدیم ترین خاندان

Patrick Volkerding نے Slackware 1.00 کو 16 July 1993 کو جاری کیا۔ یہ 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 میں جاری ہوا۔

یہ خاندان محدود ہے۔ 1990s کے وسط میں SUSE کی ابتدائی releases Slackware پر بنائی گئی تھیں، لیکن بعد میں project نے YaST اور پھر RPM package format کے ساتھ اپنی الگ سمت اختیار کر لی۔ آخری بات لوگوں کو الجھاتی ہے۔ SUSE اور openSUSE، RPM packages استعمال کرتے ہیں، لیکن یہ Red Hat derivatives نہیں ہیں۔ Format منتقل ہوا، نسب نہیں۔

Debian، 1993: ایک سماجی معاہدہ اور تین suite پر مشتمل pipeline

Ian Murdock نے Slackware کے اعلان کے تین ہفتے بعد، 16 August 1993 کو Debian کا اعلان کیا۔ وجہ بھی وہی تھی۔ اس نام میں ان کی شریکِ حیات Debra اور ان کے اپنے نام کو ملایا گیا ہے۔ Debian Manifesto جنوری 1994 میں جاری ہوا اور اس میں بنیادی شرائط طے کی گئیں: اس distribution کی دیکھ بھال کسی کمپنی کے بجائے رضاکار کھلے طور پر کریں گے۔

Debian نے بعد میں یہ شرائط تحریری شکل میں مرتب کیں۔ Debian Social Contract اور DFSG (Debian free software guidelines) جولائی 1997 میں منظور کیے گئے، اور 1998 میں DFSG، Open Source Definition کی بنیاد بنا۔ ایک distribution میں شامل کیے جانے والے اجزا طے کرنے کے لیے لکھی گئی دستاویز نے پوری صنعت کے لیے ایک licence category متعین کر دی۔ اسی وجہ سے آپ کے sources.list میں components ہوتے ہیں: main میں وہ software ہوتا ہے جو guidelines پوری کرتا ہے، جبکہ contrib اور non-free میں وہ software ہوتا ہے جو یہ شرائط پوری نہیں کرتا۔ Debian 12 میں non-free-firmware بھی شامل کیا گیا، تاکہ wireless card والے laptop کو software تلاش کرنے کی دشواری کے بغیر install کیا جا سکے۔

Tooling اس وراثت کا دوسرا حصہ ہے۔ dpkg ایک package install کرتا ہے اور کسی dependency کے missing ہونے پر عمل روک کر dpkg: dependency problems prevent configuration of دکھاتا ہے۔ APT (advanced package tool)، جو 1999 میں Debian 2.1 کے ساتھ default بنا، وہ layer ہے جو طے کرتی ہے کہ مزید کیا fetch کرنا ہے اور کس ترتیب سے کرنا ہے۔ ہر Debian derivative میں موجود ہر apt command اسی کام سے نکلی ہے۔

Release machine میں تین suites اور ایک اصول ہے۔ Maintainer package کو unstable میں upload کرتا ہے، جس کا مستقل codename sid ہے۔ اگر package release architectures پر build ہو جائے اور کوئی نیا release-critical bug نہ ملے تو ایک script تقریباً 5 سے 10 دن بعد اسے testing میں منتقل کر دیتی ہے۔ اس کے بعد testing freeze ہو جاتی ہے، release team باقی مسائل حل کرتی ہے، اور bug list کافی مختصر ہونے پر stable release کی جاتی ہے۔ یہ کسی مقررہ تاریخ پر نہیں ہوتا۔ اسی لیے Debian stable پرانا دکھائی دیتا ہے لیکن قابلِ اعتماد طور پر کام کرتا ہے: freeze کے وقت version numbers رک جاتے ہیں، جبکہ security fixes ان versions میں backport کی جاتی رہتی ہیں۔

Governance بھی تحریری طور پر متعین ہے، جس میں منتخب project leader اور binding general resolutions شامل ہیں۔ 2014 میں اسی نظام نے systemd کو default init system منتخب کیا۔ اختلاف کرنے والے افراد نے Devuan fork کیا، جس کی پہلی release 2017 میں ہوئی۔ بڑے derivatives میں 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 میں خرید لیا، اور دونوں نے مل کر پہلا Linux کاروبار قائم کیا جو software فروخت کرنے کے بجائے support فراہم کرتا تھا۔ Red Hat کے shares 11 August 1999 کو public ہوئے۔ IBM نے July 2019 میں تقریباً 34 billion dollars کے عوض کمپنی کا acquisition مکمل کیا، اس لیے جس distribution کے خلاف زیادہ تر enterprise software کی certification کی جاتی ہے، وہ تب سے IBM کی ملکیت ہے۔

دیرپا technical contribution RPM (Red Hat package manager) ہے، جسے Erik Troan اور Marc Ewing نے 1995 میں Red Hat Linux 2.0 کے لیے لکھا تھا۔ RPM اپنی dependencies بیان کرتا ہے، اور یہ ایک spec file سے تیار ہوتا ہے؛ spec file ایک build recipe ہے جسے کوئی بھی چلا سکتا ہے۔ یہی دوسری خصوصیت بعد میں Red Hat کی enterprise product کی آزادانہ rebuilds کو ممکن بنانے کی بنیادی وجہ بنی۔

2003 میں Red Hat Linux 9 اصل سلسلے کی آخری release تھی۔ کمپنی نے اسے دو حصوں میں تقسیم کر دیا: November 2003 میں Fedora Core 1 کو تیز رفتار community release کے طور پر، اور RHEL (Red Hat Enterprise Linux) کو سست رفتار paid release کے طور پر۔ RHEL کا آغاز 2002 میں Advanced Server 2.1 کے طور پر ہوا تھا۔ وجہ واضح ہے۔ ایک ہی product نئی versions آزمانے کی جگہ بھی نہیں بن سکتا اور وہ platform بھی نہیں ہو سکتا جسے کوئی bank دس سال تک بغیر تبدیلی کے چلاتا رہے۔ دونوں حصے باہم مربوط ہیں: RHEL major version کسی Fedora release سے branch ہوتی ہے، اسے stable بنایا جاتا ہے، پھر freeze کر دیا جاتا ہے۔ package tool بھی اسی schedule پر آگے بڑھا: 2000s میں yum سے 2015 میں Fedora کے default کے طور پر dnf تک، جبکہ دونوں کے نیچے rpm موجود تھا۔

CentOS نے مفت RHEL rebuild بننا کیوں چھوڑ دیا

CentOS نے 2004 میں ایک سادہ مقصد کے ساتھ آغاز کیا: Red Hat کے جاری کردہ source packages لینا، trademarks ہٹانا، انہیں دوبارہ build کرنا، اور نتیجہ مفت فراہم کرنا۔ یہ ایک دہائی تک default مفت server distribution بنا رہا، اور Red Hat نے 2014 میں اس project کو اپنے ادارے میں شامل کر لیا۔

8 December 2020 کو Red Hat نے اعلان کیا کہ CentOS Linux 8، شائع کردہ تاریخ سے 8 سال پہلے، 31 December 2021 کو ختم ہو جائے گا، اور یہ نام CentOS Stream کے طور پر جاری رہے گا۔ Stream rebuild نہیں ہے۔ یہ وہ branch ہے جس سے RHEL کی minor releases تیار کی جاتی ہیں، اس لیے یہ RHEL سے پیچھے نہیں بلکہ آگے چلتی ہے۔ جس machine کو آپ کئی سال تک برقرار رکھنا چاہتے ہیں، اس کے لیے آگے چلنا غلط سمت ہے، کیونکہ آپ کو تبدیلیاں Red Hat کے paying customers سے پہلے ملتی ہیں۔

2021 میں دو rebuilds سامنے آئیں۔ Rocky Linux کا آغاز Gregory Kurtzer نے کیا، جو CentOS کے co-founder تھے۔ AlmaLinux کی funding CloudLinux نے کی۔ June 2023 میں Red Hat نے RHEL sources کو CentOS Stream اور اپنے customer portal کے علاوہ ہر جگہ publish کرنا بند کر دیا۔ Rocky کا مقصد identical rebuilds بنانا برقرار رہا۔ AlmaLinux نے اپنا مقصد ABI (application binary interface) compatibility میں تبدیل کر لیا۔ اس کا مطلب ہے کہ RHEL کے لیے built software چلتا ہے، لیکن یہ ضمانت نہیں ہوتی کہ bugs کی فہرست ہر سطر میں یکساں ہو۔ اسی سال بعد میں Oracle، SUSE اور CIQ نے shared sources publish کرنے کے لیے OpenELA قائم کیا۔

اگر کسی provider کی image list میں اب بھی CentOS لکھا ہو تو اس پر build کرنے سے پہلے معلوم کریں کہ اس سے مراد کون سا CentOS ہے۔

cat /etc/os-release

NAME="CentOS Stream" ایک rolling development branch ہے جو RHEL سے آگے چلتی ہے۔ NAME="AlmaLinux" یا NAME="Rocky Linux" ایک rebuild ہے جو اس کے پیچھے چلتی ہے، اور اس کے لیے 10 سال کی مدت دستیاب ہوتی ہے۔

Ubuntu، 2004: ایک calendar پر Debian unstable کی snapshot

Ubuntu 4.10 کو Mark Shuttleworth کی مالی معاونت سے 20 October 2004 کو release کیا گیا۔ Debian کے ساتھ اس کا تعلق جذباتی نہیں بلکہ عملی ہے۔ ہر cycle کا آغاز Debian unstable سے packages کو نئی Ubuntu release میں import کرنے سے ہوتا ہے۔ یہ imports cycle کے دوران Debian Import Freeze تک جاری رہتے ہیں، اور اس کے بعد Ubuntu اپنی تبدیلیاں برقرار رکھتا ہے۔ Ubuntu کے بہت سے packages، Debian package اور اس میں کیے گئے ایک delta پر مشتمل ہوتے ہیں، اور changelog میں اس کی وضاحت موجود ہوتی ہے۔

دوسرا پہلو calendar ہے۔ Debian اس وقت release ہوتی ہے جب وہ تیار ہو۔ Ubuntu April اور October میں release ہوتی ہے، اور version number تاریخ ظاہر کرتا ہے: 24.04، April 2024 میں release ہوئی۔ ہر دوسرے April کی release LTS (long term support) ہوتی ہے۔ Provider جب Ubuntu کو کسی qualifier کے بغیر درج کرتا ہے تو عموماً اسی release کی مراد ہوتی ہے۔ Server کے لیے ان دونوں میں سے کون سی release موزوں ہے، اس کا مکمل جائزہ Ubuntu LTS اور interim releases کے درمیان انتخاب میں ہے، جبکہ ایک LTS سے اگلی LTS پر منتقل ہونے کا اپنا طریقہ کار ہے، جس کی تفصیل 24.04 سے 26.04 upgrade میں دی گئی ہے۔

ایک تفصیل ہر سال server admins کی توجہ حاصل کرتی ہے۔ Ubuntu کا archive components میں تقسیم ہے۔ main کو Canonical مکمل support window کے دوران maintain کرتا ہے۔ universe کو community maintain کرتی ہے، اور اس کی security coverage ایک مختلف وعدہ ہے۔ apt install اس فرق کے بارے میں کچھ نہیں دکھاتا۔ ایک command سے یہ معلوم ہو جاتا ہے:

apt-cache policy nginx

/main پر ختم ہونے والی repository line کا مطلب ہے کہ اس package کی ذمہ داری Canonical کی security team کے پاس ہے۔ /universe پر ختم ہونے والی line کا مطلب ہے کہ یہ ذمہ داری community کی ہے۔ Internet-facing ہر چیز کے لیے اسے check کریں۔

Arch، 2002: rolling releases اور جزوی upgrade کی لاگت

Judd Vinet نے 11 March 2002 کو Arch 0.1 جاری کیا۔ اس میں package manager اس نے خود لکھا تھا، pacman، اور build recipes سادہ shell scripts ہیں۔ Arch میں versioned releases بالکل نہیں ہوتیں۔ Install media انہی rolling repositories کے تاریخ زدہ snapshots ہوتے ہیں۔ اس لیے 2019 میں install کیا گیا اور ہر ہفتے update ہونے والا machine اسی Arch پر چلتا ہے جس پر آج install کیا گیا machine چلتا ہے۔ AUR (Arch user repository) میں users کی فراہم کردہ build recipes ہوتی ہیں۔ یہ reviewed packages نہیں بلکہ recipes ہیں۔ اس لیے انہیں چلانے سے پہلے PKGBUILD پڑھنا کام کا لازمی حصہ ہے۔

Rolling میں failure کی صرف ایک قسم ہے، اور ہر بار اس کی وجہ خود پیدا کی جاتی ہے۔ pacman -Sy foo کے ذریعے ایک single package install کرنے سے package database refresh ہوتا ہے۔ اس کے بعد ایک نیا binary install ہوتا ہے جو disk پر موجود libraries سے نئی libraries کے خلاف linked ہوتا ہے۔ پھر programs اس طرح fail ہوتے ہیں:

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

Supported operation pacman -Syu ہے، جو ہر چیز کو ایک ساتھ update کرتا ہے۔ Project ایسی news entries بھی شائع کرتا ہے جن میں بتایا جاتا ہے کہ بعض upgrades سے پہلے manual intervention ضروری ہے۔ انہیں پڑھے بغیر upgrade چلانے سے machine boot نہ ہونے کی حالت میں رہ سکتی ہے۔

اس وجہ سے Arch ایسے server کے لیے موزوں انتخاب نہیں جسے آپ نظرانداز کرنے کا ارادہ رکھتے ہوں۔ ہر ہفتے update کیا جانے والا box ٹھیک رہتا ہے۔ لیکن ایک سال بعد صرف ایک بار update کیا جانے والا box تمام زیر التوا interventions ایک ہی run میں آپ کے سامنے لے آتا ہے۔

Alpine: ایک چھوٹی distribution جسے containers نے مقبول بنایا

Alpine کا آغاز تقریباً 2005 میں LEAF (Linux embedded appliance framework) کے fork کے طور پر ہوا۔ LEAF خود Linux Router Project سے نکلا تھا۔ Natanael Copa نے Alpine کو desktops کے بجائے appliances کے لیے بنایا۔ یہ عام userland کے بیشتر حصوں کو تبدیل کرتا ہے: GNU C library کے بجائے musl، GNU core utilities کے بجائے BusyBox، systemd کے بجائے OpenRC، اور package manager کے طور پر apk۔ 2014 میں Alpine 3.0 وہ release تھا جس میں musl پر منتقلی ہوئی۔

Containers نے اسے مقبول بنایا۔ 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 کے لیے بنائے گئے prebuilt wheels، musl پر install نہیں ہوتے۔ اس لیے pip source سے compile کرنے کی کوشش کرتا ہے اور compiler install نہ ہونے پر رک جاتا ہے۔ 2021 کے musllinux wheel standard نے ان projects کے لیے یہ مسئلہ حل کر دیا جو ایسے wheels publish کرتے ہیں، باقی کسی کے لیے نہیں۔

VPS پر host operating system کے طور پر Alpine کم وقت میں install ہو جاتا ہے اور تیزی سے update ہوتا ہے، لیکن یہ آپ کو اس راستے سے ہٹا دیتا ہے جسے زیادہ تر documentation فرض کرتی ہے۔ ہر وہ guide جو آپ کو systemctl enable چلانے کو کہتی ہے، اسے rc-update add میں translate کرنا پڑتا ہے۔

غیر تغیر پذیر generation: atomic updates اور image based servers

جدید ترین branch package list کے بجائے update model تبدیل کرتی ہے۔ ostree based system /usr کو read only رکھتا ہے۔ update ایک مکمل نئی filesystem tree ہوتی ہے، جو download اور stage ہونے کے بعد اگلے reboot پر فعال کی جاتی ہے۔ پچھلی tree boot entry کے طور پر برقرار رہتی ہے، اس لیے خراب update کو پرانی tree میں reboot کر کے واپس کیا جا سکتا ہے۔

Fedora Silverblue نے 2018 میں یہ طریقہ desktop تک پہنچایا، اور Fedora CoreOS نے 2019 میں اسے servers تک پہنچایا؛ یہ Red Hat کے 2018 میں CoreOS خریدنے کے بعد ہوا۔ Flatcar Container Linux نے 2020 میں اصل Container Linux کی retirement کے بعد اس کا سلسلہ جاری رکھا۔ openSUSE MicroOS btrfs snapshots اور transactional-update کے ذریعے اسی نتیجے تک پہنچتا ہے۔ 2024 میں Red Hat نے RHEL میں image based mode شامل کیا، جو bootc پر مبنی ہے۔ اس mode میں operating system ایک container image کے طور پر ship ہوتا ہے اور machine کو نئے tag کی طرف point کر کے update کیا جاتا ہے۔ Talos Linux اس تصور کو مزید آگے لے جاتا ہے اور shell اور SSH مکمل طور پر ختم کر دیتا ہے۔ Machine کو API کے ذریعے configure کیا جاتا ہے، اس لیے login کرنے کے لیے کچھ موجود نہیں ہوتا۔ NixOS، جو پہلی بار 2007 میں release ہوا، مختلف راستہ اختیار کرتا ہے۔ پورا system ایک declarative configuration سے build ہوتا ہے، اور پچھلی generations boot کے لیے دستیاب رہتی ہیں۔

آپ کا provider غالباً ان میں سے کوئی system one click image کے طور پر فراہم نہیں کرتا، کیونکہ ان systems کو SSH کے ذریعے administrator کی جانب سے files edit کرنے کے بجائے پہلے boot پر Ignition یا cloud-init سے configure کیے جانے کی توقع ہوتی ہے۔ یہ systems بہت سی یکساں machines میں فائدہ دیتے ہیں۔ آپ اس صورت حال میں اس وقت ہوتے ہیں جب آپ ایک ہی وقت میں متعدد Linux servers manage کر رہے ہوں اور ضروری ہو کہ ہر machine کے بارے میں ثابت کیا جا سکے کہ وہ دوسری machines جیسی ہی ہے۔

ایک release کتنے عرصے تک supported رہتی ہے؟

Release policy وہ حصہ ہے جس کے ساتھ آپ distribution استعمال کرتے ہوئے سب سے زیادہ عرصے تک کام کرتے ہیں، اور اسے عموماً سالوں کی تعداد کی صورت میں شائع کیا جاتا ہے۔ موجودہ server releases میں سے 5 کے لیے support windows یہ ہیں۔

[
  {
    "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 سال تک برقرار رکھتی ہے۔ 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 سالہ window سے مطابقت رکھتا ہے۔ یہی اس کے rebuilds کے وجود کی بنیادی وجہ ہے۔

Arch کی اس فہرست میں کوئی row نہیں ہے، کیونکہ rolling distribution کی کوئی مخصوص release نہیں ہوتی جسے support کیا جائے۔ Arch کے لیے اہم بات یہ ہے کہ آپ کسی machine کو کتنے عرصے تک unattended چھوڑ سکتے ہیں، اور یہ مدت ہفتوں میں ناپی جاتی ہے۔

آپ کی VPS image فہرست ایسی کیوں دکھائی دیتی ہے

کوئی provider وہ images جاری کرتا ہے جنہیں customers نام سے طلب کرتے ہیں اور جو اس کے hypervisor پر unattended طور پر install ہو جاتی ہیں۔ اسی لیے تقریباً ہر فہرست Ubuntu LTS اور Debian stable سے شروع ہوتی ہے، RHEL کے مطابق certified software استعمال کرنے والوں کے لیے AlmaLinux یا Rocky شامل کرتی ہے، اور Alpine، Arch اور Fedora کو صفحے پر مزید نیچے رکھتی ہے۔ جب آپ سمجھ لیتے ہیں کہ VPS کیا ہے اور image disk تک کیسے پہنچتی ہے تو یہ pattern واضح ہو جاتا ہے: provider ایسے operating systems منتخب کر رہا ہے جو unattended install مکمل کر لیں اور اوسط customer کے server رکھنے کی مدت سے زیادہ عرصے تک supported رہیں۔

یہ انتخاب آپ کو صرف package manager تک محدود نہیں کرتا۔ یہ طے کرتا ہے کہ آپ تین سال بعد کون سا upgrade چلائیں گے، اور مختلف families میں یہ طریقہ بالکل مختلف ہوتا ہے۔ Debian اور Ubuntu موجودہ installation پر major upgrades support کرتے ہیں۔ Red Hat family انہیں leapp کے ذریعے چلاتی ہے۔ Arch میں upgrade نہیں ہوتا کیونکہ اس میں version نہیں ہوتا۔ Alpine میں /etc/apk/repositories میں ترمیم کر کے apk upgrade --available چلایا جاتا ہے۔ یہ انتخاب یہ بھی طے کرتا ہے کہ third-party repository شامل کیے بغیر آپ کون سا software install کر سکتے ہیں، CVE (common vulnerabilities and exposures) entry آپ کے زیرِ استعمال کسی component پر آنے کے بعد patch کون جاری کرے گا، اور آپ کا future software کس init system اور C library کی موجودگی فرض کرے گا۔

اس کا ایک اور اثر بھی ہے جسے کم اہم سمجھنا آسان ہے۔ انٹرنیٹ پر لکھی گئی زیادہ تر ہدایات Debian family یا Red Hat family کے طریقے کو فرض کرتی ہیں، اس لیے ان دونوں سے باہر کی family منتخب کرنے کا مطلب ہے کہ machine کی پوری مدتِ استعمال میں ہدایات کا ترجمہ کرنا پڑے گا۔ ایسی family منتخب کریں جس کی release policy اس بات سے مطابقت رکھتی ہو کہ آپ server کو کتنی بار manage کرنا چاہتے ہیں، پھر اسی پر قائم رہیں۔ اوپر سے packages تبدیل کرنا آسان ہے۔ ان کے نیچے distribution تبدیل کرنے کا مطلب box کو دوبارہ build کرنا ہے۔

FAQ

میرا server Linux کی کس distribution family میں ہے؟

cat /etc/os-release چلائیں۔ ID field distribution کا نام بتاتی ہے اور ID_LIKE اس کی family کا نام بتاتی ہے، اس لیے Ubuntu machine ID_LIKE=debian اور AlmaLinux machine ID_LIKE="rhel centos fedora" رپورٹ کرتی ہے۔ Package manager بھی اس کی شناخت کا ایک ذریعہ ہے۔ apt اور dpkg کا مطلب Debian family ہے، dnf اور rpm کا مطلب Red Hat family ہے، apk کا مطلب Alpine ہے، اور pacman کا مطلب Arch ہے۔

کیا CentOS اب بھی RHEL کا مفت version ہے؟

نہیں۔ CentOS Linux 8، جو اس نام کا آخری rebuild تھا، 31 December 2021 کو ختم ہو گیا، اور CentOS Linux 7 اپنی life کے اختتام پر 30 June 2024 کو پہنچا۔ باقی رہ جانے والا project، CentOS Stream، وہ branch ہے جس سے RHEL کی minor releases تیار کی جاتی ہیں، اس لیے اس میں تبدیلیاں RHEL سے پہلے آتی ہیں، بعد میں نہیں۔ پرانے کردار کی جگہ لینے والے مفت rebuilds AlmaLinux اور Rocky Linux ہیں، اور دونوں کے لیے دس سالہ support 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> اس میں شامل تبدیلیوں کی فہرست دکھاتا ہے۔ Debian server کی security کا اندازہ اس کے version numbers سے لگانے پر ہر بار غلط نتیجہ نکلتا ہے۔

کیا مجھے VPS پر Arch جیسی rolling release چلانی چاہیے؟

صرف اس صورت میں جب آپ اسے مقررہ schedule کے مطابق update کریں گے۔ Rolling distribution یہ فرض کرتی ہے کہ ہر machine موجودہ package set پر آ جائے گی، اس لیے pacman -Sy foo کے ذریعے ایک package update کرنے سے libraries کے versions آپس میں مختلف رہ سکتے ہیں اور cannot open shared object file جیسی errors آ سکتی ہیں۔ pacman -Syu باقاعدگی سے چلائیں، ہر run سے پہلے project کی news page پڑھیں، اور system stable رہے گا۔ اسے ایک سال تک چھوڑ دیں تو پہلا upgrade خطرناک ہو جائے گا۔

Immutable یا atomic distribution حقیقت میں کیا تبدیل کرتی ہے؟

یہ تبدیل کرتی ہے کہ updates کب apply ہوں اور انہیں واپس کیسے undo کیا جائے۔ /usr read-only mount ہوتا ہے، update کو مکمل نئی tree کے طور پر stage کیا جاتا ہے، اور reboot پر switch ہوتا ہے؛ پچھلی tree کو rollback کے لیے boot entry کے طور پر محفوظ رکھا جاتا ہے۔ اس طرح machine یا تو مکمل طور پر updated ہوتی ہے یا مکمل طور پر updated نہیں ہوتی، اور درمیان کی کوئی نامکمل state نہیں رہتی۔ آپ files کو براہ راست edit کر کے software install کرنے کی سہولت چھوڑ دیتے ہیں، اس لیے applications containers یا layered packages میں منتقل ہو جاتی ہیں۔