Linux distributions کی مکمل تاریخ اور ارتقاء

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

Linux distributions کی تاریخ ایک خلا سے شروع ہوتی ہے: Linux kernel بذات خود ایسا کچھ نہیں کرتا جسے کوئی عام صارف استعمال کر سکے۔ یہ بوٹ ہوتا ہے اور ہارڈویئر تلاش کرتا ہے۔ پھر یہ رک جاتا ہے۔ کسی کو اس میں userland شامل کرنا پڑتا ہے، یہ انتخاب کرنا پڑتا ہے کہ سافٹ ویئر کیسے انسٹال اور اپ ڈیٹ ہوگا، اور برسوں تک اسے ٹھیک رکھنے کا وعدہ کرنا پڑتا ہے۔ ایک distribution ان انتخابوں کا مجموعہ ہے، اور ان لوگوں کا گروہ جو بعد میں اس کی دیکھ بھال کرتے ہیں۔

اس کے پانچ حصے ہیں۔ ان میں سے کسی ایک کو بھی تبدیل کریں تو آپ کے پاس ایک مختلف distribution ہوگی، حالانکہ زیادہ تر binaries ایک جیسی ہی کیوں نہ ہوں:

• ایک kernel، جسے پروجیکٹ نے منتخب کیا ہو، ان patches اور drivers کے ساتھ جو اس نے شامل کیے ہوں۔
• ایک userland: C library، shell، init system، اور معیاری کمانڈز۔
• ایک package format، اور اسے انسٹال کرنے والا ٹول۔
• ایک release policy: کیا تبدیل ہو سکتا ہے، کتنی بار، اور ہر release کو کتنے عرصے تک ٹھیک رکھا جائے گا۔
• لوگ: package maintainers، ایک سیکیورٹی ٹیم، اور کوئی ایسا شخص جو پیکج ٹوٹنے پر جوابدہ ہو۔

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

Linux ڈسٹری بیوشنز کی تاریخ تین خاندانوں میں

1993 اور 1994 میں شروع ہونے والے تین پروجیکٹس تین خاندان بن گئے: Slackware، Debian اور Red Hat۔ آج VPS کنٹرول پینل میں موجود تقریباً ہر امیج ان میں سے ایک ہے یا ان کی اولاد ہے۔ ایک اولاد پیکیج فارمیٹ، فائل لے آؤٹ اور عام طور پر ریلیز کی عادات کو وراثت میں حاصل کرتی ہے، یہی وجہ ہے کہ برانڈنگ ہٹ جانے کے بعد بھی Debian سے ماخوذ سسٹم Debian جیسا ہی محسوس ہوتا ہے۔

آزاد ڈسٹری بیوشنز اپنی الگ حیثیت رکھتی ہیں، کیونکہ انہوں نے کسی اور سے 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 پر ایک مینو پر مبنی انسٹالر کے ساتھ فراہم کیا۔ اس کا وجود اس لیے تھا کیونکہ دستی طور پر یہ کام کرنے میں ایک دن کا وقت ضائع ہوتا تھا۔

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

Slackware، 1993: سب سے پرانا خاندان جو اب بھی جاری ہے

Patrick Volkerding نے 16 July 1993 کو Slackware 1.00 ریلیز کیا، جسے SLS سے تیار کیا گیا تھا اور اس میں موجود بگز کو دور کیا گیا تھا۔ یہ اب بھی برقرار ہے، جو اسے Linux کی سب سے پرانی زندہ تقسیم (distribution) بناتا ہے۔

Slackware پیکیج ایک کمپریسڈ tar آرکائیو ہوتا ہے جس کے اندر ایک انسٹال اسکرپٹ موجود ہوتی ہے۔ اس میں dependency resolution کا کوئی نظام نہیں ہے: کوئی بھی چیز یہ چیک نہیں کرتی کہ آپ کے نئے پیکیج کو درکار لائبریری پہلے سے ڈسک پر موجود ہے یا نہیں۔ اس ایک فیصلے نے باقی تمام چیزوں کو تشکیل دیا۔ اگر ٹول dependencies کو حل نہیں کرے گا، تو فراہم کردہ سیٹ کو ساخت کے لحاظ سے مربوط ہونا چاہیے، اسی لیے ریلیز بہت کم اور قدامت پسندانہ ہوتی ہیں۔ Slackware 15.0 فروری 2022 میں آیا، جو 14.2 کے چھ سال بعد تھا۔

یہ خاندان چھوٹا ہے۔ 1990 کی دہائی کے وسط میں SUSE کی ابتدائی ریلیز Slackware پر مبنی تھیں، اس سے پہلے کہ یہ پروجیکٹ YaST اور بعد میں RPM پیکیج فارمیٹ کے ساتھ اپنے راستے پر چل پڑا۔ یہ آخری حصہ لوگوں کو الجھن میں ڈالتا ہے۔ SUSE اور openSUSE RPM پیکیجز استعمال کرتے ہیں، اور وہ Red Hat کے ماخوذ (derivatives) نہیں ہیں۔ فارمیٹ نے سفر کیا، لیکن نسب نامہ نہیں۔

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

Ian Murdock نے 16 اگست 1993 کو Debian کا اعلان کیا، جو Slackware کے تین ہفتے بعد اور اسی مقصد کے لیے کیا گیا۔ یہ نام ان کی ساتھی Debra اور ان کے اپنے نام کا مجموعہ ہے۔ جنوری 1994 میں Debian Manifesto سامنے آیا جس نے شرائط طے کیں: یہ ڈسٹری بیوشن کسی کمپنی کے بجائے رضاکاروں کے ذریعے کھلے عام برقرار رکھی جائے گی۔

اس کے بعد Debian نے شرائط کو تحریری شکل دی۔ Debian Social Contract اور DFSG (Debian free software guidelines) کو جولائی 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 پرانی نظر آتی ہے اور اچھا کام کرتی ہے: ورژن نمبرز فریز پر رک جاتے ہیں جبکہ سیکیورٹی فکسز ان میں backport ہوتے رہتے ہیں۔

گورننس بھی تحریری ہے، جس میں ایک منتخب پروجیکٹ لیڈر اور پابند جنرل ریزولوشنز شامل ہیں۔ 2014 میں اس مشینری نے systemd کو ڈیفالٹ init سسٹم کے طور پر منتخب کیا، اور جن لوگوں نے اختلاف کیا انہوں نے Devuan کو فورک کیا، جس نے 2017 میں اپنی پہلی ریلیز جاری کی۔ Debian نہ تو یہ تبدیلی کرنے والی پہلی ڈسٹری بیوشن تھی اور نہ ہی آخری، اور جن وجوہات کی بنا پر یہ ہوتا رہا، ان اعتراضات کے ساتھ جو درست ثابت ہوئے، اس اکاؤنٹ میں درج ہیں کہ کس طرح systemd نے SysV init کی جگہ لی۔ اس کے بڑے جانشینوں میں Ubuntu، Raspberry Pi OS، Proxmox VE، Kali اور Linux Mint شامل ہیں۔

Red Hat، 1994: RPM، پھر Fedora اور RHEL میں تقسیم

Marc Ewing نے 1994 میں Halloween کے قریب پہلا Red Hat Linux جاری کیا۔ Bob Young کی کمپنی نے 1995 میں اسے خریدا، اور دونوں نے مل کر Linux کا پہلا ایسا کاروبار قائم کیا جس نے سافٹ ویئر کے بجائے سپورٹ فروخت کی۔ Red Hat 11 اگست 1999 کو پبلک کمپنی بن گئی۔ IBM نے جولائی 2019 میں تقریباً 34 ارب ڈالر میں اس کمپنی کا حصول مکمل کیا، لہذا وہ ڈسٹری بیوشن جس پر زیادہ تر انٹرپرائز سافٹ ویئر تصدیق شدہ ہوتے ہیں، تب سے IBM کی ملکیت ہے۔

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

2003 میں Red Hat Linux 9 اصل لائن کا آخری ورژن تھا۔ کمپنی نے اسے دو حصوں میں تقسیم کر دیا: نومبر 2003 میں Fedora Core 1 کو تیز رفتار کمیونٹی ریلیز کے طور پر، اور RHEL (Red Hat Enterprise Linux) کو، جس کا آغاز 2002 میں Advanced Server 2.1 کے طور پر ہوا تھا، ایک سست رفتار اور معاوضہ لینے والے پروڈکٹ کے طور پر۔ اس کی وجہ واضح ہے۔ ایک پروڈکٹ بیک وقت وہ جگہ نہیں ہو سکتی جہاں نئے ورژنز آزمائے جائیں اور وہ پلیٹ فارم بھی نہیں ہو سکتی جسے ایک بینک دس سال تک بغیر کسی تبدیلی کے چلائے۔ یہ دونوں حصے آپس میں جڑے ہوئے ہیں: RHEL کا ایک بڑا ورژن Fedora کی ریلیز سے شاخ بن کر نکلتا ہے، مستحکم ہوتا ہے، اور پھر فریز (freeze) ہو جاتا ہے۔ پیکیج ٹول اسی شیڈول پر آگے بڑھا، 2000 کی دہائی میں yum سے لے کر 2015 میں Fedora کے ڈیفالٹ کے طور پر dnf تک، جبکہ دونوں کے نیچے rpm موجود رہا۔

CentOS ایک مفت RHEL ری بلڈ کیوں نہیں رہا

CentOS کا آغاز 2004 میں ایک سادہ مقصد کے ساتھ ہوا: Red Hat کی شائع کردہ سورس پیکجز لیں، ٹریڈ مارکس ہٹائیں، انہیں دوبارہ تعمیر (rebuild) کریں، اور نتیجہ مفت فراہم کریں۔ ایک دہائی تک یہ ڈیفالٹ مفت سرور ڈسٹری بیوشن رہی، اور 2014 میں Red Hat نے اس پروجیکٹ کو اپنے اندرونی انتظام میں لے لیا۔

8 دسمبر 2020 کو Red Hat نے اعلان کیا کہ CentOS Linux 8 کا اختتام 31 دسمبر 2021 کو ہوگا، جو کہ شائع شدہ تاریخ سے 8 سال پہلے تھا، اور یہ کہ یہ نام CentOS Stream کے طور پر زندہ رہے گا۔ Stream ایک ری بلڈ نہیں ہے۔ یہ وہ برانچ ہے جہاں سے RHEL کے مائنر ریلیزز تیار کیے جاتے ہیں، لہذا یہ RHEL کے پیچھے چلنے کے بجائے اس سے آگے چلتی ہے۔ ایسی مشین کے لیے جسے آپ برسوں تک برقرار رکھنا چاہتے ہیں، آگے چلنا غلط سمت ہے، کیونکہ آپ کو تبدیلیاں Red Hat کے ادائیگی کرنے والے صارفین سے پہلے موصول ہوتی ہیں۔

2021 میں دو ری بلڈز سامنے آئے۔ Rocky Linux کی شروعات Gregory Kurtzer نے کی، جو CentOS کے شریک بانی تھے۔ AlmaLinux کو CloudLinux نے فنڈ کیا۔ جون 2023 میں Red Hat نے CentOS Stream اور اپنے کسٹمر پورٹل کے علاوہ کہیں بھی RHEL سورسز شائع کرنا بند کر دیا۔ Rocky نے ہو بہو ری بلڈز پر توجہ مرکوز رکھی۔ AlmaLinux نے اپنا ہدف ABI (application binary interface) مطابقت میں تبدیل کر لیا، جس کا مطلب ہے کہ RHEL کے لیے تیار کردہ سافٹ ویئر چلتا ہے، لیکن اس بات کی ضمانت نہیں کہ بگ لسٹ لائن بہ لائن مماثل ہو۔ Oracle، SUSE اور CIQ نے اسی سال کے آخر میں OpenELA قائم کیا تاکہ مشترکہ سورسز شائع کیے جا سکیں۔ 2003 کی تقسیم سے لے کر 2023 کی سورس تبدیلی تک اور ہر ری بلڈ کے موجودہ وعدوں تک کا پورا تسلسل Red Hat، CentOS، Rocky اور AlmaLinux کی تفصیلی تاریخ میں درج ہے۔

اگر کسی پرووائیڈر کی امیج لسٹ میں اب بھی CentOS لکھا ہو، تو اس پر کام شروع کرنے سے پہلے معلوم کریں کہ اس سے ان کی کیا مراد ہے۔

cat /etc/os-release

NAME="CentOS Stream" ایک رولنگ ڈیولپمنٹ برانچ ہے جو RHEL کی بنیاد بنتی ہے۔ NAME="AlmaLinux" یا NAME="Rocky Linux" ایک ری بلڈ ہے جو اس کی پیروی کرتا ہے، جس کی مدت 10 سال ہے۔

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 اور عبوری ریلیز کے درمیان انتخاب کا مکمل موضوع ہے، اور ایک LTS سے اگلی LTS پر منتقل ہونے کا اپنا طریقہ کار ہے، جو 24.04 سے 26.04 اپ گریڈ میں بیان کیا گیا ہے۔

ایک تفصیل ہر سال سرور ایڈمنز کو الجھا دیتی ہے۔ Ubuntu کا آرکائیو مختلف اجزاء میں تقسیم ہے۔ main کو Canonical مکمل سپورٹ ونڈو کے لیے برقرار رکھتا ہے۔ universe کمیونٹی کے زیر انتظام ہے، اور اس کی سیکیورٹی کوریج کا وعدہ مختلف ہے۔ apt install اس فرق کے بارے میں کچھ نہیں بتاتا۔ ایک کمانڈ اسے واضح کرتی ہے:

apt-cache policy nginx

ایک ریپوزٹری لائن جو /main پر ختم ہوتی ہے اس کا مطلب ہے کہ Canonical کی سیکیورٹی ٹیم اس پیکج کی ذمہ دار ہے۔ ایک لائن جو /universe پر ختم ہوتی ہے اس کا مطلب ہے کہ کمیونٹی اس کی ذمہ دار ہے۔ انٹرنیٹ پر موجود ہر چیز کے لیے اس کی جانچ کریں۔

Arch، 2002: rolling releases اور partial upgrade کی قیمت

Judd Vinet نے 11 مارچ 2002 کو Arch 0.1 جاری کیا، جس میں اس کا اپنا لکھا ہوا package manager pacman اور build recipes شامل تھیں جو کہ سادہ shell scripts ہیں۔ Arch میں کوئی versioned releases نہیں ہوتی۔ انسٹالیشن میڈیا دراصل انہی rolling repositories کے وقتی snapshots ہوتے ہیں، لہذا 2019 میں انسٹال کی گئی اور ہر ہفتے اپ ڈیٹ ہونے والی مشین وہی Arch چلا رہی ہے جو آج انسٹال کی گئی مشین چلا رہی ہے۔ AUR (Arch user repository) میں صارفین کی فراہم کردہ build recipes موجود ہوتی ہیں۔ یہ recipes ہوتی ہیں، نہ کہ نظرثانی شدہ packages، لہذا کسی PKGBUILD کو چلانے سے پہلے اسے پڑھنا کام کا حصہ ہے۔

Rolling ماڈل میں ناکامی کی ایک ہی صورت ہے، اور یہ ہر بار خود پیدا کردہ ہوتی ہے۔ pacman -Sy foo کے ساتھ صرف ایک package انسٹال کرنے سے package database ریفریش ہو جاتا ہے اور پھر ایک ایسی نئی binary انسٹال ہوتی ہے جو ڈسک پر موجود libraries سے زیادہ جدید libraries کے ساتھ لنک ہوتی ہے۔ اس کے بعد پروگرامز اس طرح فیل ہوتے ہیں:

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

معاون طریقہ کار pacman -Syu ہے، جو ہر چیز کو ایک ساتھ اپ ڈیٹ کرتا ہے۔ پروجیکٹ ایسی خبریں بھی پوسٹ کرتا ہے جن میں بتایا جاتا ہے کہ کچھ اپ گریڈز سے پہلے دستی مداخلت (manual intervention) ضروری ہے، اور انہیں پڑھے بغیر اپ گریڈ چلانے سے مشین بوٹ نہ ہونے کی حالت میں جا سکتی ہے۔

یہی وجہ ہے کہ Arch ایسے سرور کے لیے ایک ناقص انتخاب ہے جسے آپ نظر انداز کرنے کا ارادہ رکھتے ہیں۔ ہفتہ وار اپ ڈیٹ ہونے والی مشین ٹھیک رہتی ہے۔ لیکن ایک سال بعد ایک بار اپ ڈیٹ کی جانے والی مشین آپ کو ایک ہی رن میں وہ تمام مداخلتیں کرنے پر مجبور کر دیتی ہے جو آپ نے چھوڑی تھیں۔

Alpine: ایک چھوٹی ڈسٹری بیوشن جسے کنٹینرز نے مشہور کیا

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

کنٹینرز نے اسے مقبول بنایا۔ Alpine کی بنیادی تہہ (base layer) Debian یا Ubuntu کی نسبت بہت چھوٹی ہوتی ہے، اس لیے 2016 کے بعد سے یہ ایک عام base image بن گئی، اور بہت سے لوگ جنہوں نے کبھی Alpine انسٹال نہیں کیا، وہ اسے روزانہ چلاتے ہیں۔

اس کی قیمت یہ ہے کہ musl، glibc نہیں ہے، اور یہ فرق ایسے بگز کی صورت میں ظاہر ہوتا ہے جن کا بظاہر کوئی تعلق نہیں لگتا۔ glibc کے ساتھ لنک شدہ بائنری Alpine پر ایک ایسے پیغام کے ساتھ ناکام ہو جاتی ہے جو لوگوں کو ایسی فائل تلاش کرنے پر مجبور کرتا ہے جو پہلے سے موجود ہوتی ہے:

sh: ./myapp: not found

پروگرام موجود ہے۔ اس کا ELF interpreter موجود نہیں ہے، کیونکہ glibc کا لوڈر غائب ہے۔ Python ایک اور معمول کی حیرانی ہے: manylinux کے لیے پہلے سے تیار شدہ wheels musl پر انسٹال نہیں ہوں گی، اس لیے pip سورس سے کمپائل کرنے کی طرف واپس جاتا ہے اور جب کوئی کمپائلر انسٹال نہ ہو تو رک جاتا ہے۔ 2021 کے musllinux wheel معیار نے ان پروجیکٹس کے لیے اس مسئلے کو حل کیا جو وہ wheels شائع کرتے ہیں، باقی کسی کے لیے نہیں۔

بطور VPS ہوسٹ آپریٹنگ سسٹم، Alpine چھوٹا انسٹال ہوتا ہے اور تیزی سے اپ ڈیٹ ہوتا ہے، اور یہ آپ کو اس راستے سے ہٹا دیتا ہے جس کا زیادہ تر دستاویزات میں فرض کیا جاتا ہے۔ ہر گائیڈ جو آپ کو systemctl enable چلانے کا کہتی ہے، اسے rc-update add میں ترجمہ کرنے کی ضرورت ہوتی ہے۔

غیر متغیر جنریشن: ایٹامک اپ ڈیٹس اور امیج بیسڈ سرورز

نئی ترین برانچ پیکیج لسٹ کے بجائے اپ ڈیٹ ماڈل کو تبدیل کرتی ہے۔ ایک ostree پر مبنی سسٹم /usr کو read-only رکھتا ہے۔ ایک اپ ڈیٹ مکمل طور پر ایک نیا فائل سسٹم ٹری ہوتا ہے، جسے ڈاؤن لوڈ اور اسٹیج کیا جاتا ہے، اور اگلی ریبوٹ پر اس پر سوئچ کر لیا جاتا ہے۔ پچھلا ٹری بوٹ انٹری کے طور پر موجود رہتا ہے، لہذا ایک خراب اپ ڈیٹ کو پرانے ٹری میں ریبوٹ کر کے واپس لیا جا سکتا ہے۔

Fedora Silverblue نے 2018 میں اسے ڈیسک ٹاپ پر متعارف کرایا اور 2018 میں Red Hat کی جانب سے CoreOS کو خریدنے کے بعد، Fedora CoreOS نے 2019 میں اسے سرورز تک پہنچایا۔ Flatcar Container Linux نے اصل Container Linux کو اس وقت جاری رکھا جب اسے 2020 میں ریٹائر کیا گیا۔ openSUSE MicroOS btrfs اسنیپ شاٹس اور transactional-update کے ذریعے اسی مقام تک پہنچتا ہے۔ 2024 میں Red Hat نے RHEL میں ایک امیج بیسڈ موڈ شامل کیا، جو bootc پر مبنی ہے، جہاں آپریٹنگ سسٹم ایک کنٹینر امیج کے طور پر آتا ہے اور مشین کو ایک نئے ٹیگ کی طرف پوائنٹ کر کے اپ ڈیٹ کیا جاتا ہے۔ Talos Linux سب سے آگے ہے اور شیل اور SSH کو مکمل طور پر ختم کر دیتا ہے: مشین کو ایک API کے ذریعے کنفیگر کیا جاتا ہے، لہذا لاگ ان کرنے کے لیے کچھ نہیں ہوتا۔ NixOS، جو پہلی بار 2007 میں ریلیز ہوا، ایک مختلف سمت سے آتا ہے۔ پورا سسٹم ایک ڈیکلیریٹو کنفیگریشن سے بنتا ہے، اور پچھلی جنریشنز بوٹ ایبل رہتی ہیں۔

آپ کا پرووائیڈر غالباً ان میں سے کوئی بھی ون کلک امیج کے طور پر پیش نہیں کرتا، کیونکہ وہ توقع کرتے ہیں کہ انہیں پہلے بوٹ پر Ignition یا cloud-init کے ذریعے کنفیگر کیا جائے گا، نہ کہ کسی ایڈمنسٹریٹر کے ذریعے SSH پر فائلیں ایڈٹ کر کے۔ یہ بہت سی ایک جیسی مشینوں پر فائدہ مند ثابت ہوتے ہیں، جو کہ وہ صورتحال ہے جس میں آپ اس وقت ہوتے ہیں جب آپ ایک ساتھ کئی Linux سرورز کا انتظام کر رہے ہوں اور آپ کو ہر ایک کو دوسرے کے بالکل مساوی ثابت کرنا ہو۔

ایک ریلیز کتنے عرصے تک سپورٹ کی جاتی ہے؟

ریلیز پالیسی ڈسٹری بیوشن کا وہ حصہ ہے جس کے ساتھ آپ سب سے زیادہ وقت گزارتے ہیں، اور اسے برسوں کی تعداد کے طور پر شائع کیا جاتا ہے۔ یہاں 5 موجودہ سرور ریلیز کے لیے سپورٹ ونڈوز دی گئی ہیں۔

[
  {
    "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 برانچ کو 2 سال تک سپورٹ کرتا ہے، اسی لیے یہ ایسے کنٹینر امیج کے لیے زیادہ موزوں ہے جسے آپ اکثر دوبارہ بناتے ہیں، نہ کہ ایسے ہوسٹ کے لیے جسے آپ تبدیل نہیں کرتے۔ Debian کی سیکیورٹی ٹیم ایک سٹیبل ریلیز کو تقریباً 3 سال تک کور کرتی ہے، اور پھر LTS ٹیم عام آرکیٹیکچرز کو مجموعی طور پر تقریباً 5 سال تک لے جاتی ہے۔ ایک Ubuntu LTS آپ کو main میں موجود پیکجز کے لیے 5 سال دیتا ہے، اور Ubuntu Pro سبسکرپشن اسے 10 سال تک بڑھا دیتی ہے، جو ذاتی استعمال کے لیے چند مشینوں پر مفت ہے۔ RHEL 10 10 سال کی مدت شائع کرتا ہے، جسے ادا شدہ ایکسٹینڈڈ لائف سائیکل سپورٹ ایڈ آن 13 تک بڑھا دیتا ہے۔ AlmaLinux 10 بغیر کسی سبسکرپشن کے 10 سال کی RHEL ونڈو کے برابر ہے، اور یہی وہ واحد وجہ ہے جس کے لیے یہ ری بلڈز موجود ہیں۔

Arch کے لیے یہاں کوئی قطار نہیں ہے، کیونکہ ایک رولنگ ڈسٹری بیوشن میں سپورٹ کرنے کے لیے کوئی ریلیز نہیں ہوتی۔ Arch کے لیے جو نمبر اہمیت رکھتا ہے وہ یہ ہے کہ آپ کتنے عرصے تک کسی مشین کو بغیر چھوئے چھوڑ سکتے ہیں، اور اسے ہفتوں میں ماپا جاتا ہے۔

آپ کی VPS امیج لسٹ ایسی کیوں دکھائی دیتی ہے

ایک پرووائیڈر ان امیجز کو فراہم کرتا ہے جن کا مطالبہ صارفین نام لے کر کرتے ہیں اور جو اس کے ہائپر وائزر پر خودکار طریقے سے انسٹال ہو جاتی ہیں۔ یہی وجہ ہے کہ تقریباً ہر فہرست کا آغاز Ubuntu LTS اور Debian stable سے ہوتا ہے، ان میں AlmaLinux یا Rocky کا اضافہ ان لوگوں کے لیے کیا جاتا ہے جن کا سافٹ ویئر RHEL کے ساتھ تصدیق شدہ ہوتا ہے، اور Alpine، Arch اور Fedora کو فہرست میں نیچے رکھا جاتا ہے۔ جب آپ یہ جان لیتے ہیں کہ VPS کیا ہے اور امیج ڈسک تک کیسے پہنچتی ہے، تو یہ پیٹرن واضح ہو جاتا ہے: پرووائیڈر ایسے آپریٹنگ سسٹمز کا انتخاب کر رہا ہے جو خودکار انسٹالیشن کے عمل سے بخوبی گزر سکیں اور اوسط صارف کے سرور رکھنے کی مدت سے زیادہ عرصے تک سپورٹڈ رہیں۔

یہ انتخاب آپ کو صرف ایک پیکیج مینیجر تک محدود نہیں کرتا۔ یہ اس اپ گریڈ کا تعین کرتا ہے جو آپ 3 سال بعد چلائیں گے، اور یہ عمل فیملی کے لحاظ سے مکمل طور پر مختلف ہوتا ہے۔ Debian اور Ubuntu ان پلیس (in-place) میجر اپ گریڈز کو سپورٹ کرتے ہیں۔ Red Hat فیملی انہیں leapp کے ذریعے چلاتی ہے۔ Arch کا کوئی اپ گریڈ نہیں ہوتا کیونکہ اس کا کوئی ورژن نہیں ہوتا۔ Alpine کا طریقہ /etc/apk/repositories کو ایڈٹ کرنا اور apk upgrade --available چلانا ہے۔ یہ انتخاب اس بات کا بھی تعین کرتا ہے کہ آپ تھرڈ پارٹی ریپوزٹری شامل کیے بغیر کون سا سافٹ ویئر انسٹال کر سکتے ہیں، جب کسی چلنے والے سافٹ ویئر میں CVE (کامن ولنریبلٹیز اینڈ ایکسپوزرز) کا اندراج ہوتا ہے تو پیچ کون جاری کرتا ہے، اور آپ کا مستقبل کا سافٹ ویئر کس init سسٹم اور C library کی موجودگی کو فرض کرے گا۔

ایک اور اثر ایسا ہے جسے کم سمجھا جاتا ہے۔ انٹرنیٹ پر لکھے گئے زیادہ تر جوابات Debian فیملی یا Red Hat فیملی کے راستے کو فرض کر کے لکھے جاتے ہیں، لہذا ان دو کے علاوہ کسی اور کا انتخاب کرنے کا مطلب ہے کہ مشین کی پوری زندگی کے دوران ہدایات کا ترجمہ کرنا۔ ایسی فیملی کا انتخاب کریں جس کی ریلیز پالیسی اس بات سے مطابقت رکھتی ہو کہ آپ کتنی بار سرور کو چھیڑنے کے لیے تیار ہیں، پھر اسی پر قائم رہیں۔ اوپر موجود پیکیجز کو تبدیل کرنا آسان ہے۔ ان کے نیچے موجود ڈسٹری بیوشن کو تبدیل کرنے کا مطلب ہے کہ پورے باکس کو دوبارہ تعمیر کرنا۔

FAQ

میرا سرور کس Linux ڈسٹری بیوشن فیملی سے تعلق رکھتا ہے؟

cat /etc/os-release چلائیں۔ ID فیلڈ ڈسٹری بیوشن کا نام بتاتی ہے اور 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 کے چھوٹے ریلیز (minor releases) بنائے جاتے ہیں، اس لیے اس میں تبدیلیاں RHEL سے پہلے آتی ہیں، بعد میں نہیں۔ پرانے کردار کو سنبھالنے والے مفت ری بلڈز AlmaLinux اور Rocky Linux ہیں، جن دونوں کے پاس 10 سالہ سپورٹ ونڈوز ہیں۔

Debian stable میں ورژن نمبر اتنے پرانے کیوں ہوتے ہیں؟

کیونکہ ورژن نمبر فریز ہو جاتا ہے جبکہ اصلاحات (fixes) آتی رہتی ہیں۔ Debian اپنے ریلیز کردہ ورژن میں سیکیورٹی پیچز کو بیک پورٹ (backport) کرتا ہے بجائے اس کے کہ نیا اپ اسٹریم ریلیز درآمد کرے، لہذا ایک پیکیج جو 2.4.57-2+deb13u1 دکھاتا ہے، اس میں پچھلے ہفتے جاری ہونے والی اصلاح شامل ہو سکتی ہے۔ اپ اسٹریم ورژن کے بعد کا لاحقہ (suffix) Debian کا ریویژن ہے، اور apt changelog <package> اس کی تفصیلات بتاتا ہے۔ Debian سرور کی سیکیورٹی کو صرف ورژن نمبروں سے جانچنا ہمیشہ غلط نتیجہ دیتا ہے۔

کیا مجھے VPS پر Arch جیسی رولنگ ریلیز چلانی چاہیے؟

صرف تب جب آپ اسے ایک شیڈول کے مطابق اپ ڈیٹ کریں۔ ایک رولنگ ڈسٹری بیوشن یہ فرض کرتی ہے کہ ہر مشین موجودہ پیکیج سیٹ پر یکساں ہے، لہذا pacman -Sy foo کے ساتھ ایک پیکیج کو اپ ڈیٹ کرنے سے لائبریریاں آپس میں مطابقت نہیں رکھتیں اور cannot open shared object file جیسی غلطیاں پیدا ہوتی ہیں۔ باقاعدگی سے pacman -Syu چلائیں، ہر بار اپ ڈیٹ سے پہلے پروجیکٹ کا نیوز پیج پڑھیں، تو سسٹم مستحکم رہتا ہے۔ اگر آپ اسے ایک سال کے لیے چھوڑ دیں تو پہلا اپ گریڈ ہی خطرناک ثابت ہوتا ہے۔

ایک immutable یا atomic ڈسٹری بیوشن اصل میں کیا تبدیل کرتی ہے؟

یہ اپ ڈیٹس کے لاگو ہونے اور انہیں واپس (undo) کرنے کے طریقے کو بدلتی ہے۔ /usr کو صرف پڑھنے کی اجازت (read-only) کے ساتھ ماؤنٹ کیا جاتا ہے، ایک اپ ڈیٹ کو مکمل نئے ٹری (tree) کے طور پر تیار کیا جاتا ہے، اور تبدیلی ری بوٹ پر ہوتی ہے، جس میں پچھلا ٹری رول بیک کے لیے بوٹ انٹری کے طور پر محفوظ رہتا ہے۔ آپ کو ایسی مشین ملتی ہے جو یا تو مکمل اپ ڈیٹ ہوتی ہے یا بالکل نہیں، اس میں ادھوری اپ ڈیٹ کی کوئی حالت نہیں ہوتی۔ آپ فائلز کو براہ راست ایڈٹ کر کے سافٹ ویئر انسٹال کرنے کی سہولت کھو دیتے ہیں، اس لیے ایپلی کیشنز کنٹینرز میں یا لیئرڈ پیکیجز میں منتقل ہو جاتی ہیں۔