Linux kernel-এর ইতিহাস: যে সিদ্ধান্তগুলো টিকে গেছে

Linux kernel ইতিহাসের সংক্ষিপ্ত সংস্করণ

Linux kernel-এর ইতিহাস September 1991-এর version 0.01 থেকে আজ server-এ boot হওয়া 7.x series পর্যন্ত বিস্তৃত। Release list-ই এর সবচেয়ে কম গুরুত্বপূর্ণ অংশ। অল্প কয়েকটি সিদ্ধান্ত Linux-এর গঠন নির্ধারণ করেছিল। আজ বিকেলে ভাড়া নেওয়া কোনো machine-এও প্রতিটির প্রভাব রয়েছে। 1991 সালে নতুন kernel আদৌ কেন প্রয়োজন হয়েছিল, তা Unix, AT&T licensing এবং BSD-কে থামিয়ে দেওয়া lawsuit-এর দীর্ঘতর ইতিহাসের অংশ।

এখানে ব্যবহৃত তারিখ ও version number kernel.org এবং প্রকাশিত release history থেকে নেওয়া হয়েছে। August 2026 অনুযায়ী বর্তমান অবস্থা হলো: 7.0 প্রকাশিত হয়েছে 12 April 2026-এ, 7.1 প্রকাশিত হয়েছে 14 June 2026-এ, এবং 7.2 release candidate পর্যায়ে রয়েছে।

1992 সালের GPL নির্বাচন এখনও গুরুত্বপূর্ণ কেন

Version 0.01 17 September 1991-এ Torvalds নিজে লেখা একটি licence-এর অধীনে প্রকাশিত হয়। এতে source বিতরণ করা বাধ্যতামূলক ছিল। আরও গুরুত্বপূর্ণ একটি লাইন এতে যোগ করা হয়েছিল: "আপনি এটি কোনো fee-এর বিনিময়ে বিতরণ করতে পারবেন না, এমনকি 'handling' cost-এর জন্যও নয়।" 1991 সালে software floppy disk-এ ship করা হতো। Floppy disk copy ও post করতে খরচ হতো। ওই clause-এর কারণে commercial Linux distribution অসম্ভব হয়ে পড়ে।

তিনি এটি পরিবর্তন করেন। GNU General Public License (GPL)-এ যাওয়ার ঘোষণা January 1992-এ 0.12 release notes-এ দেওয়া হয়। এই পরিবর্তন 1 February 1992-এ কার্যকর হয়। March 1992-এর Version 0.95 ছিল GPL-এর অধীনে প্রকাশিত প্রথম release। পরে Linux-এর ওপর গড়ে ওঠা প্রতিটি business এই পরিবর্তনের ওপর নির্ভর করে।

Kernel শুধু GPL version 2-এর অধীনে রয়েছে। এটি কখনও version 3-এ যায়নি। Torvalds 2007 সালে এতে অস্বীকৃতি জানান। এর প্রধান কারণ ছিল GPLv3-এর anti-tivoisation rule। এই rule অনুযায়ী, GPL code ship করা কোনো device-কে ওই code-এর modified copy গ্রহণ করার সুযোগও দিতে হবে। তিনি locked hardware-কে manufacturer-এর নিজস্ব business বিষয় হিসেবে দেখেছেন। 2017 সালে kernel developers Kernel Enforcement Statement প্রকাশ করেন। এতে GPLv3-এর একটি নীতি নেওয়া হয়েছে: কোনো violation সম্পর্কে জানানো হলে তা সংশোধনকারী ব্যক্তি তাঁর licence বজায় রাখেন। প্রথম breach-এই licence স্থায়ীভাবে হারান না।

Server-এ এর দুটি ফল রয়েছে। আপনি যে kernel binary boot করেন, তাতে matching source পাওয়ার অধিকার অন্তর্ভুক্ত থাকে। তাই কেউ এমন Linux kernel দিতে পারে না যা আপনি inspect বা rebuild করতে পারবেন না। Kernel-এর copyright notice-এ আরও বলা আছে যে normal system call-এর মাধ্যমে kernel service ব্যবহার করা user program-কে licence প্রযোজ্য নয়। এ কারণেই proprietary database এবং monitoring agent Linux-এর জন্য ship করতে পারে, কোনো সমস্যা ছাড়াই। Permissive licence উল্টো চাপ তৈরি করে। Platform বেছে নেওয়ার আগে এই পার্থক্য বোঝা গুরুত্বপূর্ণ: server platform হিসেবে Linux ও FreeBSD।

বাস্তবে monolithic kernel কেন সফল হলো

29 January 1992-এ Andrew Tanenbaum comp.os.minix newsgroup-এ "LINUX is obsolete" শিরোনামে একটি বার্তা পোস্ট করেন। তিনি দুটি দাবি করেছিলেন। Monolithic kernel-এ driver এবং filesystem একই privileged address space-এর ভিতরে চলে; এটি 1970-এর দশকের design। Microkernel-এ এই অংশগুলো সাধারণ process হিসেবে চলে; ভবিষ্যৎ microkernel-এর। তাঁর আরেকটি দাবি ছিল, Linux Intel 386-এর সঙ্গে এমনভাবে যুক্ত যে এটি কখনো অন্য platform-এ port করা যাবে না।

Porting-এর মাধ্যমে portability-সংক্রান্ত দাবিটির উত্তর দেওয়া হয়। March 1995-এর Version 1.2-এ Alpha, SPARC এবং MIPS যোগ হয়। June 1996-এর Version 2.0-এ 64-bit Alpha port যোগ হয়।

Design-সংক্রান্ত দাবিটির উত্তর ছিল একটি সমঝোতা। Linux কখনো microkernel হয়নি। এর পরিবর্তে এতে loadable kernel module যোগ হয়: এগুলো এমন object file, যা চলমান kernel-এ insert করা এবং পরে remove করা যায়। ফলে driver-কে kernel binary থেকে আলাদাভাবে release করা যায়।

lsmod | head
modinfo virtio_net | head -5

lsmod বর্তমানে কী কী loaded আছে তা দেখায়। modinfo module-টি কোন file থেকে এসেছে এবং এটি কোন parameter গ্রহণ করে তা দেখায়। একটি virtual server-এ disk ও network path-এর বেশিরভাগ অংশ module হিসেবে থাকে। এ কারণেই এমন hardware-এও একটি kernel image boot করতে পারে, যার সঙ্গে এটি আগে কখনো কাজ করেনি। Kernel শুধু নতুন hardware শনাক্ত করে। এরপর user space daemon কোন module load করবে এবং device-এর কী নাম হবে তা নির্ধারণ করে। এভাবেই device management init system-এর ভিতরে চলে আসে। systemd এড়ানো কঠিন হয়ে ওঠার এটিও একটি কারণ।

Microkernel design-এর অতিরিক্ত খরচ ছাড়াই module এই নমনীয়তা দিয়েছে। একটি driver-কে নিজস্ব process-এ আলাদা রাখলে প্রতিটি call-এ context switch এবং message পাঠানোর খরচ দিতে হয়। 1992 সালে এই খরচ যথেষ্ট বেশি ছিল।

Linux যে খরচটি ধরে রেখেছে, সেটিই পরিকল্পনার সময় বিবেচনা করতে হবে: একটি module সম্পূর্ণ kernel privilege নিয়ে চলে। তাই ত্রুটিপূর্ণ module একটি process-এর পরিবর্তে পুরো machine বন্ধ করে দিতে পারে। Out-of-tree module-এ এই সমস্যা বেশি দেখা যায়। Mainline-এ থাকা নেই এমন vendor driver-কে প্রতিটি নতুন kernel-এর জন্য পুনরায় build করতে হয়। Upgrade-এর সময় DKMS এই কাজটি করে। সেই build ব্যর্থ হলে reboot-এর পরে device-টি আর থাকে না।

SMP সম্পূর্ণ হতে পনেরো বছর লেগেছিল

জুন 1996-এর Linux 2.0 ছিল symmetric multiprocessing (SMP) সমর্থনকারী প্রথম kernel। এর অর্থ, একই kernel-এ একাধিক CPU চলতে পারে। প্রথম implementation-এ একটি মাত্র lock, big kernel lock (BKL), ব্যবহার করা হতো। তাই এক সময়ে মাত্র একটি processor kernel code-এর ভেতরে থাকতে পারত। ফলে user space-এ computation করা workload-এ দ্বিতীয় CPU কিছুটা উপকার করত। কিন্তু system call-নির্ভর workload-এ উপকার খুব কম ছিল, কারণ সেগুলো একই lock-এর পেছনে queue হয়ে থাকত।

ওই lock সরাতে পনেরো বছর লেগেছিল। অবশিষ্ট ব্যবহারগুলো fine-grained locking-এ রূপান্তর করা হয়, যার বড় অংশ Arnd Bergmann করেন। 2.6.39-এ BKL মুছে ফেলা হয়; এই version 18 May 2011-এ release হয়। Scheduler-ও একই ধীর গতিতে উন্নত হয়েছে: 2.6.0-এ O(1) scheduler, 2007 সালে 2.6.23 থেকে Completely Fair Scheduler (CFS), এবং October 2023-এ 6.6-এ CFS-এর পরিবর্তে EEVDF।

এই কাজের কারণেই এখন 4 vCPU plan অস্বাভাবিক নয়। তবে এটি একটি গুরুত্বপূর্ণ সীমাও দেখায়। একটি shared virtual server-এ আপনার kernel আপনার thread schedule করে, আর hypervisor আপনার kernel schedule করে। top চালিয়ে %st field পড়ুন। Steal time হলো সেই CPU সময়, যা আপনার kernel ব্যবহারের জন্য প্রস্তুত ছিল কিন্তু host অন্য guest-কে দিয়েছে। তাই আপনার kernel-এর ভেতরের কোনো tuning তা পুনরুদ্ধার করতে পারে না।

2.6 সিরিজে kernel build করার পদ্ধতি কেন পরিবর্তিত হয়েছিল

2.6-এর আগে version number জোড়ায় জোড়ায় নির্ধারিত হতো। দ্বিতীয় সংখ্যা জোড় হলে সেটি stable series (2.4), আর বিজোড় হলে development series (2.5) বোঝাত। 2.4 প্রকাশিত হয়েছিল 4 January 2001-এ এবং 2.6 প্রকাশিত হয়েছিল 17 December 2003-এ। তাই পরবর্তী stable series-এর জন্য ব্যবহারকারীদের প্রায় তিন বছর অপেক্ষা করতে হতো। Distribution-গুলো এত দিন অপেক্ষা করতে পারত না, তাই তারা patch backport করত। দুটি vendor "2.4" প্রকাশ করলেও তাদের kernel-এর মধ্যে হাজার হাজার patch-এর পার্থক্য থাকত।

2.6-এর পরে এই বিভাজন বাদ দেওয়া হয়। এখন mainline প্রায় দুই সপ্তাহের একটি merge window খোলে, নতুন কাজ গ্রহণ করে, এরপর release candidate চালায় যতক্ষণ না পরিবর্তনের গতি কমে আসে, এবং প্রতি 9 থেকে 10 সপ্তাহে একটি release প্রকাশ করে। kernel.org এখনও এই cadence নথিভুক্ত করে। এই model-এর অন্য অংশটি আসে 4 March 2005-এ, stable tree-এর প্রথম release-এর মাধ্যমে। এটি ছিল 2.6.11-এর জন্য শুধু fix-সমৃদ্ধ একটি update, যা Greg Kroah-Hartman এবং Chris Wright রক্ষণাবেক্ষণ করতেন। stable tree fix গ্রহণ করে, feature গ্রহণ করে না।

এর একটি পার্শ্বপ্রতিক্রিয়া হলো, version number আর কোনো প্রতিশ্রুতি নির্দেশ করে না। 3.0, 4.0, 5.0 এবং 7.0 কোনো rewrite নয়। দ্বিতীয় সংখ্যা Torvalds-এর কাছে যথেষ্ট বড় মনে হলে তিনি প্রথম সংখ্যা বাড়ান। এ কারণেই April 2026-এ 6.19-এর পরে 7.0 প্রকাশিত হয়েছিল। সার্ভারের জন্য গুরুত্বপূর্ণ হলো আপনার distribution কোন branch অনুসরণ করে এবং সেই branch এখনও fix পায় কি না।

2005 সালের এপ্রিলে BitKeeper নিয়ে বিরোধ থেকে git কীভাবে তৈরি হয়েছিল

2002 সালের ফেব্রুয়ারি থেকে 2.5 সিরিজ দিয়ে kernel-এর উন্নয়ন BitKeeper-এ করা হতো। BitKeeper ছিল Larry McVoy-এর কোম্পানি BitMover-এর মালিকানাধীন distributed version control system। BitMover kernel developer-দের শর্তসাপেক্ষে বিনামূল্যে licence দিয়েছিল: আপনি কোনো প্রতিদ্বন্দ্বী version control tool নিয়ে কাজ করতে পারবেন না এবং BitKeeper-এর reverse engineering করতে পারবেন না। অনেক developer এমন একটি tool ব্যবহার করে free kernel তৈরি করতে অনিচ্ছুক ছিলেন, যার code পড়ার অনুমতি তাদের ছিল না।

Andrew Tridgell BitKeeper repository-এর সঙ্গে যোগাযোগ করতে পারে এমন একটি program প্রদর্শন করার পর 2005 সালের এপ্রিলে এই ব্যবস্থা ভেঙে যায়। BitMover এটিকে reverse engineering বলে অভিহিত করে এবং বিনামূল্যের licence প্রত্যাহার করে। Development cycle-এর মাঝখানে kernel তার version control system হারায়।

git-এর কাজ শুরু হয় 3 April 2005-এ। Torvalds 6 April এটি ঘোষণা করেন। 7 April-এ git self-hosting হয়ে যায়; অর্থাৎ git-এর নিজের history তখন থেকেই git-এ সংরক্ষিত হচ্ছিল। একাধিক branch-এর প্রথম merge 18 April-এ সম্পন্ন হয়। 2005 সালের জুনে git 2.6.12-এর release পরিচালনা করে। এর কিছু পর Torvalds maintenance-এর দায়িত্ব Junio Hamano-কে দেন এবং kernel-এর কাজে ফিরে যান।

এই design সরাসরি সমস্যাটি থেকে তৈরি হয়েছিল: হাজার হাজার contributor এবং এমন maintainer, যারা এমন একটি network-এর মাধ্যমে পরস্পরের কাছ থেকে পরিবর্তন নেন, যাকে কেউ বিশ্বাস করে না। প্রতিটি object তার content-এর hash দিয়ে শনাক্ত হয়। তাই পুরোনো history-এর একটি byte পরিবর্তন করলে তার পরের প্রতিটি commit-এর নাম বদলে যায়। এ কারণেই clone শুধু দাবি নয়, প্রমাণও। প্রতিটি deploy pipeline, প্রতিটি configuration repository, বেশিরভাগ team যে code host-এ push করে এবং আপনি নিজে যে git server চালাতে পারেন—সবকিছুই kernel নিয়ে একটি licensing argument থেকে তৈরি হয়েছে।

LTS মডেল কী প্রতিশ্রুতি দেয় এবং কী দেয় না

Mainline আপনি চালাবেন না। Mainline release 9 থেকে 10 সপ্তাহ পর superseded হয়। প্রতিটি release-এর পর stable tree আরও কয়েক সপ্তাহ fixes বহন করে। Longterm branch, সাধারণত LTS নামে লেখা হয়, সেগুলো বছরের পর বছর বহন করে। Distribution-গুলো এই branch-এর ওপর ভিত্তি করে build করে।

December 2009-এ প্রকাশিত 2.6.32 সংস্করণে এই মডেল কার্যকর প্রমাণিত হয়। RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 এবং Ubuntu 10.04 LTS—সবগুলোতেই এটি shipped হয়েছিল। Branch-টি February 2016 পর্যন্ত maintained ছিল, অর্থাৎ প্রকাশের পর ছয় বছরেরও বেশি সময়। Red Hat আরও এগিয়ে নিজস্ব backport-এর মাধ্যমে 2.6.32-ভিত্তিক kernel RHEL 6-এর end of life পর্যন্ত, অর্থাৎ 2020 সাল পর্যন্ত, maintained রেখেছিল। বিনামূল্যে সেই এক দশকের support পুনরুৎপাদন করার কারণই ছিল CentOS তৈরি হয়েছিল এবং পরে Rocky Linux ও AlmaLinux সেটির স্থলাভিষিক্ত হয়।

এই প্রতিশ্রুতি একাধিকবার পরিবর্তিত হয়েছে। প্রথমে সময়সীমা ছিল দুই বছর। পরে কিছু branch-এর জন্য তা ছয় বছর হয়। 2023 সালে stable maintainer-রা default সময়সীমা আবার দুই বছরে কমিয়ে আনেন। কারণ পুরোনো tree-তে backport করতে maintainer-দের সময় লাগে এবং পুরোনো branch-গুলোতে বাস্তব testing কম হয়। 25 February 2026-এ এসব branch-এর ওপর নির্ভরশীল কোম্পানিগুলোর সঙ্গে আলোচনার পর Greg Kroah-Hartman আবার দীর্ঘতর projection প্রকাশ করেন। বর্তমান framework তিন থেকে ছয় বছর পর্যন্ত বিস্তৃত।

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

August 2026 অনুযায়ী kernel.org-এ 6টি longterm branch তালিকাভুক্ত আছে। সবচেয়ে পুরোনো 5.10 branch শেষ হওয়ার সময় পর্যন্ত 6.0 বছর fixes বহন করবে। সবচেয়ে নতুন 6.18 branch-এর চালু থাকার সম্ভাব্য শেষ তারিখ Dec 2028। এতে 3.1 বছর fixes থাকবে।

এই তারিখগুলোকে চুক্তি হিসেবে নয়, বরং ন্যূনতম সময়সীমা হিসেবে দেখুন। February 2026-এ 6.6 এবং 6.12-এর projection—দুটিই আরও পিছিয়ে দেওয়া হয়েছে। আবার কোনো branch কেউ ব্যবহার না করলে সেটি আগেই বাদ পড়তে পারে। সাধারণত আপনার distribution এই সিদ্ধান্ত আপনার হয়ে নেয়। Debian 13-এ 6.12 shipped হয়, আর Ubuntu 26.04 LTS-এ 7.0 shipped হয়। এই পার্থক্যই server-এ LTS এবং interim release বেছে নেওয়ার বাস্তব বিষয়টি বোঝায়। Ubuntu 24.04 থেকে 26.04-এ upgrade করলে আপনার ব্যবহৃত kernel-এর নিচে বাস্তবে এটিই পরিবর্তিত হয়।

এখান থেকে একটি বিভ্রান্তি তৈরি হতে পারে। Ubuntu 24.04-এ uname -r চালালে এমন কিছু দেখা যায়: 6.8.0-51-generic। এটি upstream base-এর সঙ্গে distribution-এর নিজস্ব backport যুক্ত করে তৈরি। তাই এই number শুধু branch কোথা থেকে শুরু হয়েছে তা জানায়; এতে কোন fixes রয়েছে তা জানায় না। এই কারণেই version string দেখে kernel বিচার করা scanner-গুলো distribution kernel-এর ক্ষেত্রে false alarm তৈরি করে।

কার্নেল এখন কোন বিষয় নিয়ে বিতর্ক করছে

দুটি বিতর্ক চলছে, এবং উভয়টির বিষয় হলো কাজটি কে করবে।

2022 সালের December-এ 6.1 সংস্করণে Rust অবকাঠামোর অংশ হিসেবে যুক্ত হয়। 7.0 সংস্করণে experimental label সরিয়ে নেওয়া হয়। ফলে kernel-এর মূল language এখন C, assembly এবং Rust, আর build-এর জন্য আর nightly compiler প্রয়োজন হয় না। বিতর্কটি maintenance নিয়ে। কোনো C maintainer একটি interface পরিবর্তন করলে, তিনি যে Rust binding পড়েন না সেগুলো ভেঙে যেতে পারে। সেগুলো ঠিক করার দায়িত্ব কার, তা নিয়েই বিতর্ক।

দ্বিতীয় বিতর্কটি AI contribution নিয়ে। machine-assisted patch-এর সংখ্যা বাড়তে থাকায় Sasha Levin July 2025-এ একটি policy প্রস্তাব করেন। 23 December 2025-এ document-টি commit করা হয় এবং এখন kernel-এর নিজস্ব process documentation-এ docs.kernel.org/process/coding-assistants.html হিসেবে রয়েছে। কোনো AI agent Signed-off-by tag যোগ করতে পারবে না, কারণ ওই line-এ Developer Certificate of Origin (DCO) প্রত্যয়িত হয় এবং এটি কেবল একজন মানুষ প্রত্যয়ন করতে পারেন। সহায়তার ঘোষণা Assisted-by: tag দিয়ে দিতে হয়। Review-এর সময় এটি Co-developed-by: থেকে পরিবর্তন করা হয়েছিল, কারণ কোনো tool author নয়। Generated code-কে GPL-2.0-only-এর সঙ্গে compatible হতে হবে। যে মানুষটি patch পাঠান, তিনি সেটি review করেন এবং এর দায়িত্ব বহন করেন।

এই policy-এর পেছনে মূল চাপ হলো review-এর সময়। একটি patch generate করতে কয়েক সেকেন্ড লাগে, কিন্তু সেটি review করতে একজন maintainer-এর পুরো বিকেল লেগে যেতে পারে। কোনো tag এই অসমতা দূর করে না। তবে এটি provenance অক্ষুণ্ণ রাখে। History-তে প্রতিটি পরিবর্তনের জন্য কে sign করেছেন, তা নথিভুক্ত থাকে। 2004 সালে DCO চালুর উদ্দেশ্য ছিল এই তথ্যটি সুরক্ষিত রাখা।

আপনার ভাড়া করা সার্ভারের জন্য এই ইতিহাসের অর্থ

• লাইসেন্সের কারণেই আপনার provider যে kernel চালু করে, সেটি আপনি পড়তে ও পুনর্নির্মাণ করতে পারেন। একই কারণে proprietary software-ও এতে চলে।
• monolithic design-এর কারণেই একটি driver-এর bug পুরো machine reboot করাতে পারে। একই কারণে প্রতিটি kernel upgrade-এর সময় out-of-tree module পুনর্নির্মাণ করতে হয়।
• release model-এর কারণে version number আপনাকে খুব কম তথ্য দেয়। branch এবং তার end-of-life date প্রায় সব গুরুত্বপূর্ণ তথ্য জানায়।
• virtualisation-এর ধরনই নির্ধারণ করে আপনি আদৌ কী করতে পারবেন। KVM-এ আপনি নিজের kernel boot করতে এবং module load করতে পারেন। কিন্তু host kernel শেয়ার করা container virtualisation-এ uname -r host-এর version দেখায়, modprobe ব্যর্থ হয়, এবং কয়েকটি sysctl read-only থাকে।

FAQ

Linux kernel এখনও GPLv2, GPLv3 নয়, কেন?

Torvalds 2007 সালে GPLv3 গ্রহণ না করার সিদ্ধান্ত নেন। এর প্রধান কারণ ছিল এর anti-tivoisation requirement। এই requirement অনুযায়ী, যে device GPL code সরবরাহ করে, সেটিকে ওই code-এর modified version-ও গ্রহণ করতে হয়। তিনি locked hardware-কে manufacturer-এর ব্যবসায়িক বিষয় হিসেবে দেখেন। বাস্তবে relicensing করাও প্রায় অসম্ভব। কারণ kernel-এর copyright হাজারো contributor-এর হাতে রয়েছে এবং এর বিকল্প হিসেবে ব্যবহার করার মতো কোনো assignment agreement নেই। Kernelটি GPL-2.0-only-এর অধীনে, তাই শুধু GPLv3-এর অধীনে দেওয়া code merge করা যায় না।

Linux kernel monolithic kernel, নাকি microkernel?

এটি loadable module-সহ monolithic kernel। Driver ও filesystem kernel-এর address space-এর ভিতরে চলে, এবং lsmod বর্তমানে load করা driver ও filesystem দেখায়। এর ফলে একদিকে গতি পাওয়া যায়, অন্যদিকে ত্রুটির প্রভাব বড় হয়। কোনো faulty module পুরো machine-এ panic ঘটাতে পারে, যেখানে microkernel-এ একটি process নষ্ট হতো। 1992 সালের পর user space-এ FUSE filesystem এবং kernel চালানোর আগে যাচাই করা eBPF program-এর কারণে এই পার্থক্য কিছুটা কমেছে।

mainline, stable এবং longterm kernel-এর মধ্যে পার্থক্য কী?

Mainline হলো Torvalds-এর tree। এটি প্রতি 9 থেকে 10 সপ্তাহে release হয় এবং নতুন feature প্রথমে এখানেই যোগ হয়। Stable সর্বশেষ mainline release গ্রহণ করে এবং কয়েক সপ্তাহ bug fix পায়। Longterm branch-গুলো বছরের পর বছর fix পেতে থাকে। Distribution-গুলো সাধারণত এই branch-এর ওপর তাদের kernel তৈরি করে। kernel.org প্রতিটি বর্তমান longterm branch-এর সম্ভাব্য end-of-life date তালিকাভুক্ত করে।

Linux kernel কি AI দিয়ে লেখা code গ্রহণ করে?

হ্যাঁ, December 2025-এ গৃহীত একটি policy-এর অধীনে। Tool-এর নাম একটি Assisted-by: tag-এ উল্লেখ করতে হয়। কোনো AI agent Signed-off-by line যোগ করতে পারবে না। Generated code-কে GPL-2.0-only-এর সঙ্গে compatible হতে হবে। Human submitter sign off করেন। এর অর্থ, তিনি patch review করেছেন এবং Developer Certificate of Origin-এর অধীনে এর দায়িত্ব গ্রহণ করছেন।

Server-এ কোন kernel version চালানো উচিত?

প্রায় সব ক্ষেত্রেই আপনার distribution যে version maintain করে, সেটিই চালানো উচিত। Distribution kernel হলো একটি longterm branch, backported fix এবং vendor-এর testing-এর সমন্বয়। আপনার provider-এর image এবং support arrangement সাধারণত এই kernel ধরেই তৈরি করা থাকে। নির্দিষ্ট driver বা feature প্রয়োজন হলে নতুন mainline kernel build করুন। তবে সেই branch গ্রহণের আগে তার end-of-life date পরীক্ষা করুন।