Linux ডিস্ট্রিবিউশনের ইতিহাস ও বিবর্তন

Linux distribution আসলে কী

Linux distribution-এর ইতিহাস একটি শূন্যস্থান দিয়ে শুরু হয়: Linux kernel নিজে থেকে এমন কিছু করতে পারে না যা একজন ব্যবহারকারী কাজে লাগাতে পারেন। এটি বুট হয় এবং হার্ডওয়্যার খুঁজে পায়। তারপর এটি থেমে যায়। কাউকে একটি userland যোগ করতে হয়, সফটওয়্যার কীভাবে ইনস্টল এবং আপডেট হবে তা নির্ধারণ করতে হয় এবং বছরের পর বছর ধরে তা ঠিক রাখার প্রতিশ্রুতি দিতে হয়। একটি distribution হলো সেই সিদ্ধান্তগুলোর সমষ্টি, এবং সেই সাথে একদল মানুষ যারা পরবর্তীতে এর রক্ষণাবেক্ষণ করেন।

এর পাঁচটি অংশ রয়েছে। এর যেকোনো একটি পরিবর্তন করলে আপনি একটি ভিন্ন distribution পাবেন, এমনকি যখন অধিকাংশ binary মিলে যায় তবুও:

• একটি kernel, যা প্রজেক্ট কর্তৃক নির্বাচিত ভার্সনে থাকে, সাথে তাদের যোগ করা patch এবং driver।
• একটি userland: C library, shell, init system এবং স্ট্যান্ডার্ড কমান্ডসমূহ।
• একটি package format এবং এটি ইনস্টল করার টুল।
• একটি release policy: কী পরিবর্তন হতে পারে, কত ঘন ঘন হবে এবং প্রতিটি release কতদিন পর্যন্ত ঠিক রাখা হবে।
• মানুষ: package maintainer, একটি security team এবং এমন কেউ যিনি কোনো package নষ্ট হয়ে গেলে তার উত্তর দেন।

Kernel হলো সাধারণ অংশ, তাই দুটি Linux distribution একে অপরের অনেক কাছাকাছি থাকে, যা কোনো Linux distribution এবং অন্য কোনো Unix-এর মধ্যে থাকে না। আপনি যখন server platform হিসেবে Linux এবং FreeBSD-এর তুলনা করবেন, তখন এই বিষয়টি মনে রাখা জরুরি, যেখানে kernel এবং base userland একটি প্রজেক্ট দ্বারা তৈরি হয় এবং একসাথে release করা হয়। Linux-এ এই অংশগুলো আলাদা আলাদা upstream থেকে আসে এবং distribution হলো সেই মাধ্যম যা এদের মধ্যে সমন্বয় সাধন করে।

লিনাক্স ডিস্ট্রিবিউশনের তিনটি পরিবারের ইতিহাস

1993 এবং 1994 সালে শুরু হওয়া তিনটি প্রজেক্ট থেকে তিনটি পরিবারের উদ্ভব হয়: Slackware, Debian এবং Red Hat। বর্তমানে যেকোনো VPS কন্ট্রোল প্যানেলে থাকা প্রায় প্রতিটি ইমেজই এই তিনটি পরিবারের কোনো একটি বা এদের বংশোদ্ভূত। একটি ডেরিভেটিভ বা বংশোদ্ভূত ডিস্ট্রিবিউশন তার মূল ডিস্ট্রিবিউশনের প্যাকেজ ফরম্যাট, ফাইল লেআউট এবং সাধারণত রিলিজের অভ্যাসগুলো উত্তরাধিকারসূত্রে পায়। এই কারণেই ব্র্যান্ডিং সরিয়ে ফেলার পরেও একটি Debian ডেরিভেটিভ ব্যবহার করার সময় সেটি Debian-এর মতোই মনে হয়।

স্বাধীন ডিস্ট্রিবিউশনগুলো আলাদা আলোচনার দাবি রাখে, কারণ তারা অন্য কোনো ডিস্ট্রিবিউশন থেকে ফর্ক (fork) করা নয়। Arch, Gentoo, Alpine, NixOS এবং Void—এদের প্রত্যেকেই নিজস্ব প্যাকেজ ম্যানেজার এবং নিজস্ব নিয়ম তৈরি করেছে। এদের মধ্যে দুটি, Arch এবং Alpine, শেষ পর্যন্ত আপনার প্রোভাইডারের ইমেজ তালিকায় জায়গা করে নিয়েছে, যার কারণগুলো ডেস্কটপ ব্যবহারের সাথে সম্পর্কিত নয়।

1992: ডিস্ট্রিবিউশন বা পরিবারের পূর্বসূরি

1992 সালের ফেব্রুয়ারি মাসে ম্যানচেস্টার কম্পিউটিং সেন্টারের ওয়েন লে ব্লাঙ্ক (Owen Le Blanc) MCC Interim Linux তৈরি করেন। এটি কার্নেল এবং GNU (GNU's not Unix) টুলগুলোকে এক জোড়া ফ্লপি ইমেজে অন্তর্ভুক্ত করে এবং একটি মেনু-চালিত ইনস্টলার প্রদান করে। হাতে কলমে এই কাজগুলো করতে একদিন সময় লাগত বলেই এর উদ্ভব হয়েছিল।

1992 সালে পিটার ম্যাকডোনাল্ড (Peter MacDonald) কর্তৃক রিলিজ করা SLS (Softlanding Linux System) আরও এক ধাপ এগিয়ে X (the X Window System) এবং TCP/IP নেটওয়ার্কিং যুক্ত করে। distribution শব্দটি বর্তমানে যে অর্থে ব্যবহৃত হয়, তার কারণ হলো এই SLS। এটি ত্রুটিপূর্ণ ছিল এবং এর রক্ষণাবেক্ষণও ছিল ধীরগতির। 1993 সালে দুইজন ব্যক্তি আলাদাভাবে এটি ঠিক করার সিদ্ধান্ত নেন। একজন এটিকে নতুন করে তৈরি করেন। অন্যজন লিখিত নিয়ম মেনে একেবারে নতুনভাবে শুরু করেন।

Slackware, 1993: প্রাচীনতম পরিবার যা এখনো টিকে আছে

Patrick Volkerding 16 জুলাই 1993 সালে Slackware 1.00 রিলিজ করেন, যা SLS থেকে তৈরি করা হয়েছিল এবং এর ত্রুটিগুলো সংশোধন করা হয়েছিল। এটি এখনো রক্ষণাবেক্ষণ করা হয়, যা এটিকে টিকে থাকা প্রাচীনতম Linux ডিস্ট্রিবিউশন হিসেবে প্রতিষ্ঠিত করেছে।

একটি Slackware প্যাকেজ হলো একটি কম্প্রেসড tar আর্কাইভ, যার ভেতরে একটি ইনস্টল স্ক্রিপ্ট থাকে। এতে কোনো dependency resolution নেই: আপনার নতুন প্যাকেজের জন্য প্রয়োজনীয় লাইব্রেরিটি ডিস্কে আগে থেকেই আছে কি না, তা যাচাই করার কোনো ব্যবস্থা নেই। এই একটি সিদ্ধান্তই বাকি সবকিছুকে প্রভাবিত করেছে। যদি টুলটি dependency সমাধান না করে, তবে প্যাকেজ সেটটিকে গঠনগতভাবেই সামঞ্জস্যপূর্ণ হতে হয়, তাই রিলিজগুলো খুব কম এবং রক্ষণশীল হয়। Slackware 15.0 এসেছিল ফেব্রুয়ারি 2022 সালে, 14.2 রিলিজের ছয় বছর পর।

এই পরিবারটি ছোট। 1990-এর দশকের মাঝামাঝি সময়ে SUSE-এর প্রথম দিকের রিলিজগুলো Slackware-এর ওপর ভিত্তি করে তৈরি হয়েছিল, পরবর্তীতে প্রকল্পটি YaST এবং তারও পরে RPM প্যাকেজ ফরম্যাট নিয়ে নিজস্ব পথে এগিয়ে যায়। এই শেষ অংশটি মানুষকে বিভ্রান্ত করে। SUSE এবং openSUSE উভয়ই RPM প্যাকেজ ব্যবহার করে, কিন্তু তারা Red Hat-এর ডেরিভেটিভ নয়। ফরম্যাটটি স্থানান্তরিত হয়েছে, কিন্তু বংশধারাটি নয়।

Debian, 1993: একটি সামাজিক চুক্তি এবং তিনটি সুইটের পাইপলাইন

Ian Murdock 16 আগস্ট 1993 সালে Debian-এর ঘোষণা দেন, Slackware আসার তিন সপ্তাহ পর এবং একই কারণে। এই নামটি তার সঙ্গী Debra এবং তার নিজের নামের সমন্বয়ে গঠিত। 1994 সালের জানুয়ারিতে Debian Manifesto প্রকাশিত হয় এবং শর্ত নির্ধারণ করে: এই ডিস্ট্রিবিউশনটি কোনো কোম্পানির দ্বারা নয়, বরং স্বেচ্ছাসেবকদের দ্বারা উন্মুক্তভাবে পরিচালিত হবে।

এরপর Debian শর্তগুলো লিখিত আকারে প্রকাশ করে। 1997 সালের জুলাই মাসে Debian Social Contract এবং DFSG (Debian free software guidelines) গৃহীত হয় এবং 1998 সালে DFSG-ই Open Source Definition-এর ভিত্তি হয়ে ওঠে। একটি ডিস্ট্রিবিউশনে কী থাকবে তা নির্ধারণ করার জন্য লেখা একটি নথি শেষ পর্যন্ত পুরো শিল্পের জন্য একটি লাইসেন্স ক্যাটাগরি সংজ্ঞায়িত করে। আপনার sources.list-এ বিভিন্ন অংশ থাকার কারণও এটিই: main-এ সেই সফটওয়্যার থাকে যা নির্দেশিকা মেনে চলে, contrib এবং non-free-এ যা মেনে চলে না তা থাকে, এবং Debian 12-এ non-free-firmware যুক্ত করা হয়েছে যাতে ওয়্যারলেস কার্ডযুক্ত ল্যাপটপে কোনো বাড়তি ঝামেলা ছাড়াই ইনস্টলেশন সম্পন্ন করা যায়।

টুলিং হলো আরেকটি উত্তরাধিকার। dpkg একটি প্যাকেজ ইনস্টল করে এবং কোনো কিছু অনুপস্থিত থাকলে তা প্রত্যাখ্যান করে, সাথে dpkg: dependency problems prevent configuration of প্রিন্ট করে। APT (advanced package tool), যা 1999 সালে Debian 2.1-এর সাথে ডিফল্ট হিসেবে যুক্ত হয়, সেটিই সেই স্তর যা নির্ধারণ করে আর কী কী সংগ্রহ করতে হবে এবং কোন ক্রমে করতে হবে। প্রতিটি Debian ডেরিভেটিভের প্রতিটি apt কমান্ড সেই কাজেরই ফসল।

রিলিজ মেশিনে তিনটি সুইট এবং একটি নিয়ম রয়েছে। একজন মেইনটেইনার unstable-এ আপলোড করেন, যার কোডনাম স্থায়ীভাবে sid। একটি স্ক্রিপ্ট প্যাকেজটিকে প্রায় 5 থেকে 10 দিন পর testing-এ স্থানান্তর করে, যদি এটি রিলিজ আর্কিটেকচারে বিল্ড হয় এবং কোনো নতুন রিলিজ-ক্রিটিক্যাল বাগ না থাকে। এরপর testing ফ্রিজ করা হয়, রিলিজ টিম অবশিষ্ট সমস্যাগুলো সমাধান করে এবং বাগের তালিকা যথেষ্ট ছোট হলে stable রিলিজ হয়। কোনো নির্দিষ্ট তারিখের ভিত্তিতে নয়। এই কারণেই Debian stable দেখতে পুরনো মনে হলেও খুব ভালোভাবে কাজ করে: ফ্রিজ হওয়ার পর ভার্সন নম্বর আর বাড়ে না, কিন্তু নিরাপত্তা সংক্রান্ত ফিক্সগুলো সেগুলোতে ব্যাকপোর্ট করা হতে থাকে।

শাসন ব্যবস্থাও লিখিত, যেখানে একজন নির্বাচিত প্রজেক্ট লিডার এবং বাধ্যতামূলক সাধারণ রেজোলিউশন থাকে। 2014 সালে সেই প্রক্রিয়াটি systemd-কে ডিফল্ট init সিস্টেম হিসেবে বেছে নেয়, এবং যারা এর সাথে একমত ছিলেন না তারা Devuan ফর্ক করেন, যা 2017 সালে তাদের প্রথম রিলিজ প্রকাশ করে। এর বৃহত্তর বংশধরদের মধ্যে রয়েছে Ubuntu, Raspberry Pi OS, Proxmox VE, Kali এবং Linux Mint।

Red Hat, 1994: RPM, এরপর Fedora ও RHEL-এ বিভাজন

Marc Ewing 1994 সালের হ্যালোউইনের কাছাকাছি সময়ে প্রথম Red Hat Linux প্রকাশ করেন। Bob Young-এর কোম্পানি 1995 সালে এটি কিনে নেয় এবং তারা দুজনে মিলে প্রথম এমন একটি Linux ব্যবসা গড়ে তোলেন যেখানে সফটওয়্যারের বদলে সাপোর্ট বিক্রি করা হতো। 1999 সালের 11 আগস্ট Red Hat পাবলিক কোম্পানিতে পরিণত হয়। 2019 সালের জুলাই মাসে IBM প্রায় 34 বিলিয়ন ডলারে কোম্পানিটিকে অধিগ্রহণ সম্পন্ন করে, তাই যে ডিস্ট্রিবিউশনের ওপর ভিত্তি করে অধিকাংশ এন্টারপ্রাইজ সফটওয়্যার সার্টিফাইড হয়, তা তখন থেকেই IBM-এর মালিকানাধীন।

এর দীর্ঘস্থায়ী প্রযুক্তিগত অবদান হলো RPM (Red Hat package manager), যা 1995 সালে Red Hat Linux 2.0-এর জন্য Erik Troan এবং Marc Ewing তৈরি করেছিলেন। একটি RPM তার ডিপেন্ডেন্সিগুলো ঘোষণা করে এবং এটি একটি spec file থেকে তৈরি হয়, যা মূলত একটি build recipe যা যে কেউ চালাতে পারে। এই দ্বিতীয় বৈশিষ্ট্যটির কারণেই পরবর্তীতে Red Hat-এর এন্টারপ্রাইজ প্রোডাক্টের স্বাধীন রিবিল্ড তৈরি করা সম্ভব হয়েছিল।

2003 সালের Red Hat Linux 9 ছিল মূল ধারার শেষ সংস্করণ। কোম্পানি এটিকে দুই ভাগে বিভক্ত করে: 2003 সালের নভেম্বরে দ্রুতগতির কমিউনিটি রিলিজ হিসেবে Fedora Core 1 এবং 2002 সালে Advanced Server 2.1 হিসেবে শুরু হওয়া RHEL (Red Hat Enterprise Linux), যা ছিল ধীরগতির পেইড সংস্করণ। এর কারণ স্পষ্ট। একটি প্রোডাক্ট একই সাথে নতুন সংস্করণ পরীক্ষার জায়গা এবং কোনো ব্যাংকের দশ বছর ধরে অপরিবর্তিতভাবে চলার প্ল্যাটফর্ম হতে পারে না। এই দুটি অংশ একে অপরের সাথে যুক্ত: একটি RHEL মেজর ভার্সন Fedora রিলিজ থেকে শাখা হিসেবে বের হয়, স্থিতিশীল হয় এবং তারপর ফ্রিজ করা হয়। প্যাকেজ টুলটিও একই সময়সূচী মেনে এগিয়েছে, 2000-এর দশকে yum থেকে 2015 সালে Fedora-এর ডিফল্ট হিসেবে dnf-এ উন্নীত হয়েছে, যার নিচে উভয় ক্ষেত্রেই rpm কাজ করে।

কেন CentOS একটি ফ্রি RHEL রিবিল্ড হিসেবে থাকা বন্ধ করে দিয়েছে

CentOS 2004 সালে একটি সাধারণ লক্ষ্য নিয়ে যাত্রা শুরু করে: Red Hat-এর প্রকাশিত সোর্স প্যাকেজগুলো নেওয়া, ট্রেডমার্কগুলো সরিয়ে ফেলা, সেগুলো পুনরায় বিল্ড করা এবং ফলাফলটি বিনামূল্যে বিতরণ করা। এক দশক ধরে এটি ডিফল্ট ফ্রি সার্ভার ডিস্ট্রিবিউশন হিসেবে টিকে ছিল এবং 2014 সালে Red Hat প্রকল্পটিকে নিজেদের অধীনে নিয়ে নেয়।

8 ডিসেম্বর 2020 তারিখে Red Hat ঘোষণা করে যে, CentOS Linux 8-এর মেয়াদ 31 ডিসেম্বর 2021 তারিখে শেষ হবে, যা পূর্বনির্ধারিত তারিখের আট বছর আগেই। তারা জানায় যে, CentOS Stream নামে এই নামটি টিকে থাকবে। Stream কোনো রিবিল্ড নয়। এটি এমন একটি শাখা যেখান থেকে RHEL-এর মাইনর রিলিজগুলো তৈরি করা হয়, তাই এটি RHEL-এর পেছনে চলার পরিবর্তে সামনে থাকে। আপনি যদি এমন কোনো মেশিন চান যা বছরের পর বছর ব্যবহার করবেন, তবে 'সামনে থাকা' আপনার জন্য সঠিক নয়, কারণ Red Hat-এর পেইড গ্রাহকদের আগেই আপনি পরিবর্তনগুলো পেয়ে যাবেন।

2021 সালে দুটি রিবিল্ড সামনে আসে। Rocky Linux শুরু করেন Gregory Kurtzer, যিনি CentOS-এর সহ-প্রতিষ্ঠাতা ছিলেন। AlmaLinux-এর অর্থায়ন করে CloudLinux। জুন 2023 সালে Red Hat তাদের RHEL সোর্সগুলো CentOS Stream এবং তাদের কাস্টমার পোর্টাল ছাড়া অন্য কোথাও প্রকাশ করা বন্ধ করে দেয়। Rocky Linux হুবহু রিবিল্ড তৈরির লক্ষ্যেই অটল থাকে। AlmaLinux তাদের লক্ষ্য পরিবর্তন করে ABI (application binary interface) সামঞ্জস্যতার দিকে নিয়ে যায়, যার অর্থ হলো RHEL-এর জন্য তৈরি সফটওয়্যার এখানে চলবে, তবে বাগ লিস্ট হুবহু মিলবে এমন কোনো নিশ্চয়তা নেই। সেই বছরের শেষের দিকে Oracle, SUSE এবং CIQ যৌথভাবে OpenELA গঠন করে সোর্সগুলো প্রকাশ করার জন্য।

যদি কোনো প্রোভাইডারের ইমেজ লিস্টে এখনো CentOS লেখা থাকে, তবে সেখানে কোনো কিছু বিল্ড করার আগে নিশ্চিত হয়ে নিন যে তারা ঠিক কোনটি বোঝাচ্ছে।

cat /etc/os-release

NAME="CentOS Stream" হলো একটি রোলিং ডেভেলপমেন্ট শাখা যা RHEL-এর অগ্রগামী। NAME="AlmaLinux" অথবা NAME="Rocky Linux" হলো একটি রিবিল্ড যা RHEL-কে অনুসরণ করে এবং দশ বছরের সাপোর্ট উইন্ডো প্রদান করে।

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 release এবং partial upgrade-এর ঝুঁকি

Judd Vinet 11 মার্চ 2002 সালে Arch 0.1 প্রকাশ করেন। এতে ছিল তার নিজের লেখা একটি package manager, pacman, এবং build recipe হিসেবে সাধারণ shell script। Arch-এ কোনো নির্দিষ্ট version-ভিত্তিক release নেই। এর install media হলো একই rolling repository-এর তারিখযুক্ত snapshot। তাই 2019 সালে install করা এবং প্রতি সপ্তাহে update করা একটি machine, আর আজ install করা একটি machine একই Arch version চালায়। AUR (Arch user repository)-এ ব্যবহারকারীদের তৈরি করা build recipe থাকে। এগুলো কেবল recipe, যাচাইকৃত package নয়; তাই কোনো PKGBUILD চালানোর আগে তা পড়ে নেওয়া কাজের অংশ।

Rolling release-এর একটি ব্যর্থতার দিক আছে, যা মূলত ব্যবহারকারীর নিজের ভুলের কারণে ঘটে। pacman -Sy foo দিয়ে একটিমাত্র package install করলে তা package database refresh করে এবং এমন একটি নতুন binary install করে, যা ডিস্কে থাকা library-গুলোর চেয়ে নতুন library-র ওপর নির্ভরশীল। তখন program-গুলো এভাবে ব্যর্থ হয়:

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

সমর্থিত পদ্ধতি হলো pacman -Syu, যা সবকিছু একসাথে update করে। প্রকল্পটি এমন সব news entry প্রকাশ করে যেখানে বলা থাকে যে নির্দিষ্ট কিছু upgrade-এর আগে ম্যানুয়াল হস্তক্ষেপ প্রয়োজন। সেগুলো না পড়ে upgrade চালালে machine boot না-ও হতে পারে।

এই কারণে, যে server-এর দিকে আপনি নজর দেবেন না, সেটির জন্য Arch একটি ভালো পছন্দ নয়। সপ্তাহে একবার update করা machine ঠিক আছে। কিন্তু এক বছর পর একবার update করলে, মাঝখানের সব বকেয়া হস্তক্ষেপ একসাথে করতে গিয়ে আপনি বিপদে পড়বেন।

Alpine: একটি ছোট ডিস্ট্রিবিউশন যা কন্টেইনারের মাধ্যমে পরিচিতি পেয়েছে

Alpine 2005 সালের দিকে LEAF (Linux embedded appliance framework)-এর একটি ফর্ক হিসেবে যাত্রা শুরু করে, যা মূলত Linux Router Project থেকে উদ্ভূত। Natanael Copa এটিকে ডেস্কটপের পরিবর্তে অ্যাপ্লায়েন্সের জন্য তৈরি করেছিলেন। এটি প্রচলিত ইউজারল্যান্ডের বেশিরভাগ অংশ প্রতিস্থাপন করে: GNU C library-এর পরিবর্তে musl, GNU core utilities-এর পরিবর্তে BusyBox, systemd-এর পরিবর্তে OpenRC এবং প্যাকেজ ম্যানেজার হিসেবে apk ব্যবহার করে। 2014 সালের Alpine 3.0 রিলিজেই musl-এ স্থানান্তরিত হওয়ার প্রক্রিয়া সম্পন্ন হয়।

কন্টেইনার প্রযুক্তি এটিকে জনপ্রিয় করে তুলেছে। একটি Alpine বেস লেয়ারের আকার Debian বা Ubuntu বেস লেয়ারের তুলনায় অনেক কম। তাই 2016 সাল থেকে এটি একটি সাধারণ বেস ইমেজ হিসেবে ব্যবহৃত হতে থাকে এবং যারা কখনো Alpine ইনস্টল করেননি, তারাও প্রতিদিন এটি ব্যবহার করছেন।

এর অসুবিধা হলো, musl এবং glibc এক নয়, এবং এই পার্থক্যের কারণে এমন সব বাগ দেখা দেয় যা দেখে মনে হয় এগুলোর সাথে কোনো সম্পর্ক নেই। glibc-এর সাথে লিঙ্ক করা কোনো বাইনারি Alpine-এ ব্যর্থ হয় এমন একটি মেসেজ দিয়ে, যা দেখে ব্যবহারকারী এমন একটি ফাইল খুঁজতে শুরু করেন যা আসলে সেখানেই আছে:

sh: ./myapp: not found

প্রোগ্রামটি বিদ্যমান। কিন্তু এর ELF ইন্টারপ্রেটারটি নেই, কারণ glibc-এর লোডার এখানে অনুপস্থিত। Python-এর ক্ষেত্রেও নিয়মিত এমন চমক পাওয়া যায়: manylinux-এর জন্য তৈরি প্রি-বিল্ট হুইল (wheels) musl-এ ইনস্টল হবে না। তাই pip সোর্স থেকে কম্পাইল করার চেষ্টা করে এবং কোনো কম্পাইলার ইনস্টল করা না থাকলে তা বন্ধ হয়ে যায়। 2021 সালের musllinux হুইল স্ট্যান্ডার্ডটি সেইসব প্রজেক্টের জন্য এই সমস্যার সমাধান করেছে যারা এই হুইলগুলো প্রকাশ করে, অন্যদের জন্য নয়।

একটি VPS-এ হোস্ট অপারেটিং সিস্টেম হিসেবে Alpine খুব অল্প জায়গায় ইনস্টল হয় এবং দ্রুত আপডেট হয়। তবে এটি আপনাকে এমন পথে নিয়ে যায় যা বেশিরভাগ ডকুমেন্টেশনে ধরে নেওয়া হয় না। প্রতিটি গাইড যেখানে systemctl enable চালানোর কথা বলা হয়েছে, সেখানে আপনাকে তা অনুবাদ করে rc-update add হিসেবে ধরে নিতে হবে।

অপরিবর্তনীয় প্রজন্ম: অ্যাটমিক আপডেট এবং ইমেজ-ভিত্তিক সার্ভার

নতুন এই শাখাটি প্যাকেজ তালিকার পরিবর্তে আপডেট মডেল পরিবর্তন করে। একটি ostree-ভিত্তিক সিস্টেম /usr কে read only হিসেবে রাখে। একটি আপডেট হলো সম্পূর্ণ নতুন একটি ফাইলসিস্টেম ট্রি, যা ডাউনলোড ও স্টেজ করা হয় এবং পরবর্তী রিবুটের সময় সেটিতে সুইচ করা হয়। পূর্ববর্তী ট্রিটি একটি বুট এন্ট্রি হিসেবে থেকে যায়, তাই কোনো ত্রুটিপূর্ণ আপডেট হলে পুরনোটিতে রিবুট করে সহজেই তা বাতিল করা যায়।

Fedora Silverblue 2018 সালে ডেস্কটপে এই সুবিধা নিয়ে আসে এবং Red Hat 2018 সালে CoreOS কিনে নেওয়ার পর 2019 সালে Fedora CoreOS তা সার্ভারে নিয়ে আসে। 2020 সালে Container Linux বন্ধ হয়ে যাওয়ার পর Flatcar Container Linux সেটির ধারাবাহিকতা বজায় রাখে। openSUSE MicroOS btrfs স্ন্যাপশট এবং transactional-update-এর মাধ্যমে একই অবস্থানে পৌঁছায়। 2024 সালে Red Hat RHEL-এ একটি ইমেজ-ভিত্তিক মোড যুক্ত করে, যা bootc-এর ওপর ভিত্তি করে তৈরি। এখানে অপারেটিং সিস্টেমটি একটি কন্টেইনার ইমেজ হিসেবে থাকে এবং নতুন কোনো ট্যাগের দিকে নির্দেশ করে মেশিন আপডেট করা হয়। Talos Linux সবচেয়ে এগিয়ে আছে এবং তারা শেল ও SSH সম্পূর্ণভাবে সরিয়ে ফেলেছে: মেশিনটি একটি API-এর মাধ্যমে কনফিগার করা হয়, তাই লগ-ইন করার মতো কিছুই অবশিষ্ট থাকে না। 2007 সালে প্রথম মুক্তি পাওয়া NixOS ভিন্ন একটি দিক থেকে আসে। পুরো সিস্টেমটি একটি ডিক্লারেটিভ কনফিগারেশন থেকে তৈরি হয় এবং পূর্ববর্তী প্রজন্মগুলো বুটযোগ্য অবস্থায় থেকে যায়।

আপনার প্রোভাইডার সম্ভবত এগুলোর কোনোটিই এক-ক্লিক ইমেজ হিসেবে অফার করে না, কারণ তারা আশা করে যে এগুলো SSH-এর মাধ্যমে কোনো অ্যাডমিনিস্ট্রেটর ফাইল এডিট করার পরিবর্তে প্রথম বুটের সময় Ignition বা cloud-init দ্বারা কনফিগার করা হবে। অনেকগুলো অভিন্ন মেশিনের ক্ষেত্রে এগুলো কার্যকর হয়, যা আপনার বর্তমান পরিস্থিতির সাথে মিলে যায় যখন আপনি একসাথে একাধিক লিনাক্স সার্ভার পরিচালনা করছেন এবং প্রতিটি সার্ভারকে অন্যগুলোর মতোই হুবহু একই রকম নিশ্চিত করতে চান।

একটি রিলিজ কতদিন সাপোর্ট করা হয়?

রিলিজ পলিসি হলো একটি ডিস্ট্রিবিউশনের সেই অংশ যার সাথে আপনাকে দীর্ঘতম সময় থাকতে হয় এবং এটি বছরের সংখ্যা হিসেবে প্রকাশিত হয়। নিচে বর্তমান সার্ভার রিলিজগুলোর জন্য 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 কোনো সাবস্ক্রিপশন ছাড়াই RHEL-এর 10 বছরের উইন্ডো অনুসরণ করে, আর এই কারণেই এই রিবিল্ডগুলোর অস্তিত্ব রয়েছে।

Arch-এর ক্ষেত্রে এখানে কোনো সারি নেই, কারণ একটি রোলিং ডিস্ট্রিবিউশনের সাপোর্ট করার মতো কোনো নির্দিষ্ট রিলিজ থাকে না। Arch-এর ক্ষেত্রে গুরুত্বপূর্ণ বিষয় হলো আপনি একটি মেশিনকে কতদিন অপরিবর্তিত রাখতে পারবেন, যা সপ্তাহের হিসেবে পরিমাপ করা হয়।

আপনার VPS ইমেজ লিস্ট কেন এমন দেখায়

একটি প্রোভাইডার গ্রাহকদের চাহিদা অনুযায়ী ইমেজ সরবরাহ করে, যা তাদের হাইপারভাইজারে স্বয়ংক্রিয়ভাবে ইনস্টল হয়। এই কারণেই প্রায় প্রতিটি লিস্টের শুরুতে Ubuntu LTS এবং Debian stable থাকে। যারা RHEL-এর সাথে সার্টিফাইড সফটওয়্যার ব্যবহার করেন, তাদের জন্য AlmaLinux বা Rocky যোগ করা হয় এবং Alpine, Arch ও Fedora-কে তালিকার নিচের দিকে রাখা হয়। আপনি যখন VPS কী এবং ইমেজ কীভাবে ডিস্কে পৌঁছায় তা জানবেন, তখন এই প্যাটার্নটি পরিষ্কার হয়ে যাবে: প্রোভাইডার এমন অপারেটিং সিস্টেম বেছে নেয় যা স্বয়ংক্রিয় ইনস্টলেশনে টিকে থাকে এবং গড় গ্রাহকের সার্ভার ব্যবহারের সময়ের চেয়ে বেশি সময় সাপোর্ট পায়।

এই পছন্দটি আপনাকে কেবল একটি প্যাকেজ ম্যানেজারের চেয়েও বেশি কিছুর সাথে যুক্ত করে। এটি নির্ধারণ করে তিন বছর পর আপনি কোন আপগ্রেডটি চালাবেন, এবং এই প্রক্রিয়াটি অপারেটিং সিস্টেমের ফ্যামিলি অনুযায়ী সম্পূর্ণ আলাদা হয়। Debian এবং Ubuntu সরাসরি ইন-প্লেস মেজর আপগ্রেড সাপোর্ট করে। Red Hat ফ্যামিলি leapp-এর মাধ্যমে এটি পরিচালনা করে। Arch-এর কোনো আপগ্রেড নেই কারণ এর কোনো নির্দিষ্ট ভার্সন নেই। Alpine-এর ক্ষেত্রে /etc/apk/repositories এডিট করে apk upgrade --available চালাতে হয়। এই পছন্দটি আরও নির্ধারণ করে যে, কোনো থার্ড পার্টি রিপোজিটরি যোগ না করেই আপনি কোন সফটওয়্যার ইনস্টল করতে পারবেন, আপনার ব্যবহৃত সফটওয়্যারে কোনো CVE (common vulnerabilities and exposures) ধরা পড়লে কে প্যাচ সরবরাহ করবে এবং আপনার ভবিষ্যতের সফটওয়্যার কোন init system ও 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 ডিসেম্বর 2021 তারিখে শেষ হয়েছে এবং CentOS Linux 7-এর মেয়াদ 30 জুন 2024 তারিখে শেষ হয়েছে। বর্তমানের প্রজেক্ট, CentOS Stream, হলো সেই ব্রাঞ্চ যেখান থেকে RHEL-এর মাইনর রিলিজগুলো তৈরি হয়; তাই এতে RHEL-এর আগে পরিবর্তনগুলো আসে, পরে নয়। পুরনো CentOS-এর ভূমিকা পালনকারী ফ্রি রিবিল্ডগুলো হলো AlmaLinux এবং Rocky Linux, যার প্রতিটিরই দশ বছরের সাপোর্ট উইন্ডো রয়েছে।

Debian stable-এ কেন এত পুরনো ভার্সন নম্বর থাকে?

কারণ ভার্সন নম্বরটি ফ্রিজ বা স্থির রাখা হয়, কিন্তু বাগ ফিক্স বা নিরাপত্তা আপডেটগুলো নিয়মিত আসতে থাকে। Debian নতুন আপস্ট্রিম রিলিজ ইমপোর্ট করার পরিবর্তে তাদের রিলিজ করা ভার্সনেই সিকিউরিটি প্যাচগুলো ব্যাকপোর্ট করে। তাই যে প্যাকেজটি 2.4.57-2+deb13u1 দেখাচ্ছে, তাতে গত সপ্তাহে প্রকাশিত কোনো ফিক্সও থাকতে পারে। আপস্ট্রিম ভার্সনের পরের সাফিক্সটি হলো Debian রিভিশন, এবং apt changelog <package> কমান্ডটি সেই প্যাকেজে কী কী পরিবর্তন এসেছে তার তালিকা দেখায়। ভার্সন নম্বর দেখে Debian সার্ভারের নিরাপত্তা যাচাই করা সবসময়ই ভুল ফলাফল দেয়।

VPS-এ কি Arch-এর মতো রোলিং রিলিজ ব্যবহার করা উচিত?

শুধুমাত্র যদি আপনি নিয়মিত শিডিউল অনুযায়ী আপডেট করেন তবেই এটি ব্যবহার করুন। একটি রোলিং ডিস্ট্রিবিউশন ধরে নেয় যে প্রতিটি মেশিন বর্তমান প্যাকেজ সেটের সাথে সামঞ্জস্যপূর্ণ থাকবে। তাই pacman -Sy foo ব্যবহার করে একটি প্যাকেজ আপডেট করলে লাইব্রেরির অমিল দেখা দিতে পারে এবং cannot open shared object file-এর মতো এরর আসতে পারে। নিয়মিত pacman -Syu চালান এবং প্রতিটি আপডেটের আগে প্রজেক্টের নিউজ পেজটি পড়ুন, তাহলেই সিস্টেমটি স্থিতিশীল থাকবে। এক বছর আপডেট না করলে প্রথমবার আপগ্রেড করাটা ঝুঁকিপূর্ণ হয়ে দাঁড়ায়।

ইমিউটেবল (immutable) বা অ্যাটমিক (atomic) ডিস্ট্রিবিউশন আসলে কী পরিবর্তন আনে?

এটি আপডেট প্রয়োগের সময় এবং তা বাতিল করার পদ্ধতিতে পরিবর্তন আনে। /usr ফাইলসিস্টেমটি রিড-অনলি হিসেবে মাউন্ট করা থাকে। একটি আপডেট সম্পূর্ণ নতুন ট্রি (tree) হিসেবে স্টেজ করা হয় এবং রিবুট করার সময় সুইচ সম্পন্ন হয়। আগের ট্রি-টি রোলব্যাকের জন্য একটি বুট এন্ট্রি হিসেবে সংরক্ষিত থাকে। এতে আপনি এমন একটি মেশিন পান যা হয় সম্পূর্ণ আপডেট করা, অথবা আপডেট করা হয়নি—মাঝামাঝি কোনো অবস্থায় থাকে না। ফাইল এডিট করে সফটওয়্যার ইনস্টল করার সুবিধা এখানে থাকে না, তাই অ্যাপ্লিকেশনগুলোকে কন্টেইনারে অথবা লেয়ারড প্যাকেজে স্থানান্তর করতে হয়।