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

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

Linux kernel-এর ইতিহাস সেপ্টেম্বর 1991-এর version 0.01 থেকে শুরু হয়ে বর্তমানে server-এ চালু থাকা 7.x series পর্যন্ত বিস্তৃত। শুধু release list দেখলে এই ইতিহাসের সবচেয়ে গুরুত্বপূর্ণ দিকটি বোঝা যায় না। অল্প কয়েকটি সিদ্ধান্ত kernel-এর কাঠামো নির্ধারণ করেছে। আজ বিকেলে ভাড়া নেওয়া কোনো machine-এও প্রতিটি সিদ্ধান্তের প্রভাব দেখা যায়।

এখানে ব্যবহৃত তারিখ ও version number kernel.org এবং সেখানে প্রকাশিত release history থেকে নেওয়া। আগস্ট 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 distributed করার বাধ্যবাধকতা ছিল। আরও গুরুত্বপূর্ণ একটি লাইন ছিল: "আপনি এটি কোনো fee-এর বিনিময়ে distribute করতে পারবেন না, এমনকি 'handling' costs-এর জন্যও নয়।" 1991 সালে software floppy disks-এ distributed হতো, এবং floppy disks 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 ছিল এর অধীনে প্রকাশিত প্রথম release। পরে Linux-এর ওপর গড়ে ওঠা প্রতিটি business এই পরিবর্তনের ওপর নির্ভর করে।

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

Server-এর ক্ষেত্রে এর দুটি ফল রয়েছে। আপনি boot করা kernel binary-এর সঙ্গে matching source পাওয়ার অধিকারও পান। তাই কেউ এমন Linux kernel দিতে পারে না যা আপনি inspect বা rebuild করতে পারবেন না। Kernel-এর copyright notice-এ আরও বলা আছে যে normal system calls-এর মাধ্যমে kernel services ব্যবহার করা user programs-এর ওপর licence প্রযোজ্য নয়। এই কারণেই proprietary databases এবং monitoring agents কোনো সমস্যা ছাড়াই 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 হিসেবে চলে; এটিই ভবিষ্যৎ। তাঁর দ্বিতীয় দাবি ছিল, Linux Intel 386-এর সঙ্গে এত ঘনিষ্ঠভাবে যুক্ত যে এটি কখনো অন্য platform-এ চলবে না।

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 করতে পারে, যার সঙ্গে এটি আগে কখনো কাজ করেনি।

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

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

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

1996 সালের June মাসে প্রকাশিত Linux 2.0 ছিল symmetric multiprocessing (SMP) সমর্থনকারী প্রথম kernel। এর অর্থ, একই kernel-এর অধীনে একাধিক CPU চলতে পারে। প্রথম implementation-এ একটি single 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 version-এ CFS-এর পরিবর্তে EEVDF।

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

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

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

2.6-এর পর এই বিভাজন বাদ দেওয়া হয়। এখন mainline প্রায় দুই সপ্তাহের একটি merge window খোলে, নতুন কাজ গ্রহণ করে, তারপর release candidate চালায় যতক্ষণ না পরিবর্তন কমে আসে। এরপর প্রতি 9 থেকে 10 সপ্তাহে একটি release প্রকাশ করা হয়। kernel.org এখনও এই cadence নথিভুক্ত করে। এই মডেলের অন্য অংশটি 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 নতুন করে লেখা kernel নয়। দ্বিতীয় সংখ্যা Torvalds-এর কাছে যথেষ্ট বড় মনে হলে তিনি প্রথম সংখ্যা বাড়ান। এ কারণেই April 2026-এ 6.19-এর পর 7.0 প্রকাশিত হয়েছিল। Server-এর জন্য গুরুত্বপূর্ণ হলো আপনার distribution কোন branch অনুসরণ করে এবং সেই branch এখনও fix পায় কি না।

এপ্রিল 2005-এ BitKeeper সংকট কীভাবে git তৈরি করেছিল

February 2002 থেকে 2.5 series দিয়ে Larry McVoy-এর কোম্পানি BitMover-এর proprietary distributed version control system BitKeeper-এ kernel-এর development চলছিল। BitMover kernel developer-দের কিছু শর্তে বিনামূল্যে licence দিয়েছিল: competing version control tool-এ কাজ করা যাবে না এবং BitKeeper reverse engineer করা যাবে না। অনেক developer এমন একটি tool ব্যবহার করে free kernel তৈরি করা পছন্দ করতেন না, যার source code পড়ার অনুমতি তাদের ছিল না।

2005 সালের April-এ এই ব্যবস্থা ভেঙে পড়ে। Andrew Tridgell BitKeeper repository-এর সঙ্গে যোগাযোগ করতে পারে এমন একটি program প্রদর্শন করার পর 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-এ সংরক্ষিত হচ্ছিল। 18 April-এ একাধিক branch-এর প্রথম merge সম্পন্ন হয়। June 2005-এ git 2.6.12-এর release পরিচালনা করে। এর কিছু পর Torvalds maintenance-এর দায়িত্ব Junio Hamano-কে দেন এবং kernel development-এ ফিরে যান।

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

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

Mainline ব্যবহার করার জন্য নয়। একটি mainline release সাধারণত 9 থেকে 10 সপ্তাহ পর superseded হয়। প্রতিটি release-এর পর stable tree আরও কয়েক সপ্তাহ সংশোধন বহন করে। 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 ছিল, অর্থাৎ প্রকাশের পর 6 বছরেরও বেশি সময়।

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

[
  {
    "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 তালিকাভুক্ত করেছে। সবচেয়ে পুরোনো branch, 5.10, Dec 2026-এ শেষ হওয়ার সময় 6.0 বছর সংশোধন বহন করবে। সবচেয়ে নতুন branch, 6.18, Dec 2028 পর্যন্ত চলবে বলে projection করা হয়েছে। এতে 3.1 বছরের সংশোধন থাকবে।

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

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

এই মুহূর্তে kernel নিয়ে যে বিতর্ক চলছে

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

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

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

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

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

• লাইসেন্সের কারণেই আপনার provider যে kernel boot করে, সেটি আপনি পড়তে ও পুনর্নির্মাণ করতে পারেন। একই কারণে proprietary software-ও এতে চলে।
• monolithic design-এর কারণে একটি driver-এর bug পুরো machine reboot করাতে পারে। একই কারণে out-of-tree module প্রতিটি kernel upgrade-এর সময় পুনর্নির্মাণ করতে হয়।
• release model-এর কারণে version number আপনাকে খুব কম তথ্য দেয়। বিপরীতে branch এবং তার end-of-life date প্রায় পুরো চিত্রটি জানায়।
• virtualisation type নির্ধারণ করে আপনি আদৌ কী করতে পারবেন। 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 গ্রহণ না করার সিদ্ধান্ত নেন। এর প্রধান কারণ ছিল GPLv3-এর anti-tivoisation requirement। এই requirement অনুযায়ী, কোনো device GPL code ship করলে সেটিকে ওই code-এর modified version-ও গ্রহণ করতে দিতে হবে। Torvalds locked hardware-কে নির্মাতার ব্যবসায়িক সিদ্ধান্ত হিসেবে দেখেন। বাস্তবে 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-এর ভেতরে চলে। বর্তমানে কোনগুলো loaded আছে, তা lsmod দেখায়। এর ফলে একদিকে গতি পাওয়া যায়, অন্যদিকে ক্ষতির পরিধি বড় হয়। কোনো 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 পর্যালোচনা করেছেন এবং 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 পরীক্ষা করুন।