ประวัติ Linux kernel: การตัดสินใจสำคัญที่เปลี่ยนโลกไอที

ประวัติโดยย่อของ Linux kernel

ประวัติของ Linux kernel เริ่มต้นจากเวอร์ชัน 0.01 ในเดือนกันยายน 1991 จนถึงซีรีส์ 7.x ที่ใช้บูตเซิร์ฟเวอร์ในปัจจุบัน รายการเวอร์ชันที่ปล่อยออกมาเป็นส่วนที่น่าสนใจน้อยที่สุด การตัดสินใจเพียงไม่กี่อย่างได้กำหนดทิศทางของระบบ และแต่ละการตัดสินใจยังคงส่งผลกระทบต่อเครื่องที่คุณเช่าใช้งานในบ่ายวันนี้

วันที่และหมายเลขเวอร์ชันในที่นี้อ้างอิงจาก kernel.org และประวัติการปล่อยเวอร์ชันที่เผยแพร่ สถานะปัจจุบัน ณ เดือนสิงหาคม 2026 คือ 7.0 ถูกปล่อยออกมาเมื่อวันที่ 12 เมษายน 2026, 7.1 เมื่อวันที่ 14 มิถุนายน 2026 และ 7.2 อยู่ในขั้นตอน release candidates

เหตุผลที่การเลือกใช้ GPL ในปี 1992 ยังคงมีความสำคัญ

เวอร์ชัน 0.01 ถูกเผยแพร่เมื่อวันที่ 17 กันยายน 1991 ภายใต้สัญญาอนุญาตที่ Torvalds เขียนขึ้นเอง โดยกำหนดให้ต้องมีการแจกจ่ายซอร์สโค้ด และเพิ่มข้อความที่สำคัญกว่านั้นคือ "คุณห้ามแจกจ่ายซอฟต์แวร์นี้โดยเรียกเก็บค่าธรรมเนียม แม้แต่ค่า 'ดำเนินการ' ก็ตาม" ในปี 1991 ซอฟต์แวร์ถูกจัดส่งผ่านแผ่นฟลอปปีดิสก์ ซึ่งการคัดลอกและจัดส่งแผ่นดิสก์มีต้นทุน ข้อกำหนดดังกล่าวจึงทำให้การทำ Linux distribution เชิงพาณิชย์เป็นไปไม่ได้

เขาได้เปลี่ยนสัญญาอนุญาตดังกล่าว การย้ายไปใช้ GNU General Public License (GPL) ได้รับการประกาศในบันทึกประจำรุ่น 0.12 เมื่อเดือนมกราคม 1992 และมีผลบังคับใช้ในวันที่ 1 กุมภาพันธ์ 1992 โดยเวอร์ชัน 0.95 ในเดือนมีนาคม 1992 เป็นรุ่นแรกที่เผยแพร่ภายใต้สัญญาอนุญาตนี้ ธุรกิจทุกแห่งที่สร้างขึ้นบน Linux ในเวลาต่อมาล้วนตั้งอยู่บนการเปลี่ยนแปลงครั้งนั้น

Kernel ใช้ GPL เวอร์ชัน 2 เท่านั้น และไม่เคยย้ายไปใช้เวอร์ชัน 3 Torvalds ปฏิเสธในปี 2007 โดยมีสาเหตุหลักมาจากกฎต่อต้านการล็อกอุปกรณ์ (anti-tivoisation) ใน GPLv3 ซึ่งกำหนดให้อุปกรณ์ที่ใช้โค้ด GPL ต้องยอมรับโค้ดที่ถูกแก้ไขแล้วด้วย เขาถือว่าฮาร์ดแวร์ที่ถูกล็อกเป็นเรื่องของทางผู้ผลิตเอง ในปี 2017 นักพัฒนา Kernel ได้เผยแพร่ Kernel Enforcement Statement ซึ่งหยิบยืมส่วนหนึ่งของ GPLv3 มาใช้ นั่นคือ ผู้ที่แก้ไขการละเมิดหลังจากได้รับแจ้งจะยังคงได้รับสิทธิ์ในสัญญาอนุญาตต่อไป แทนที่จะสูญเสียสิทธิ์อย่างถาวรตั้งแต่การละเมิดครั้งแรก

ผลลัพธ์สองประการที่เกิดขึ้นบนเซิร์ฟเวอร์คือ Kernel binary ที่คุณบูตมาพร้อมกับสิทธิ์ในการเข้าถึงซอร์สโค้ดที่ตรงกัน ดังนั้นจึงไม่มีใครสามารถส่ง Linux kernel ที่คุณไม่สามารถตรวจสอบหรือคอมไพล์ใหม่ให้คุณได้ และประกาศลิขสิทธิ์บน Kernel ระบุว่าสัญญาอนุญาตไม่ครอบคลุมถึงโปรแกรมของผู้ใช้ที่เรียกใช้บริการของ Kernel ผ่าน system call ปกติ ซึ่งเป็นเหตุผลว่าทำไมฐานข้อมูลและตัวแทนตรวจสอบ (monitoring agent) แบบกรรมสิทธิ์ (proprietary) จึงสามารถใช้งานบน Linux ได้โดยไม่ละเมิดข้อกำหนดใดๆ สัญญาอนุญาตแบบเปิดกว้าง (permissive licence) จะสร้างแรงกดดันในทิศทางตรงกันข้าม และความแตกต่างนั้นเป็นสิ่งที่ควรทำความเข้าใจก่อนที่คุณจะเลือกแพลตฟอร์ม: ดู Linux และ FreeBSD ในฐานะแพลตฟอร์มเซิร์ฟเวอร์

เหตุใด monolithic kernel จึงเป็นผู้ชนะในทางปฏิบัติ

เมื่อวันที่ 29 มกราคม 1992 Andrew Tanenbaum ได้โพสต์ข้อความหัวข้อ "LINUX is obsolete" ลงในกลุ่มข่าว comp.os.minix โดยเขากล่าวอ้างไว้สองประการ ประการแรกคือ monolithic kernel ซึ่งเป็นสถาปัตยกรรมที่ไดรเวอร์และระบบไฟล์ทำงานอยู่ภายในพื้นที่หน่วยความจำที่มีสิทธิ์ระดับสูง (privileged address space) นั้นเป็นดีไซน์ของยุค 1970 ในขณะที่ microkernel ซึ่งให้ส่วนประกอบเหล่านั้นทำงานเป็นกระบวนการทั่วไป (ordinary processes) คืออนาคต ประการที่สองคือ Linux ถูกผูกติดไว้กับสถาปัตยกรรม Intel 386 จึงไม่มีทางที่จะนำไปใช้งานบนแพลตฟอร์มอื่นได้

ข้อโต้แย้งเรื่องความสามารถในการพอร์ต (portability) ได้รับคำตอบด้วยการพอร์ตจริง โดยในเวอร์ชัน 1.2 เมื่อเดือนมีนาคม 1995 ได้เพิ่มการรองรับ Alpha, SPARC และ MIPS และในเวอร์ชัน 2.0 เมื่อเดือนมิถุนายน 1996 ได้เพิ่มการรองรับ Alpha แบบ 64-bit

ข้อโต้แย้งเรื่องดีไซน์ได้รับคำตอบด้วยการประนีประนอม Linux ไม่เคยกลายเป็น microkernel แต่ได้นำระบบ loadable kernel modules มาใช้ ซึ่งคือไฟล์ออบเจกต์ที่คุณสามารถแทรกเข้าไปใน kernel ที่กำลังทำงานอยู่และนำออกได้ ทำให้ไดรเวอร์สามารถแยกส่งต่างหากจากไฟล์ kernel binary ได้

lsmod | head
modinfo virtio_net | head -5

lsmod จะแสดงรายการสิ่งที่ถูกโหลดอยู่ในขณะนี้ modinfo จะแสดงไฟล์ต้นทางของโมดูลและพารามิเตอร์ที่โมดูลนั้นรองรับ บนเซิร์ฟเวอร์เสมือน (virtual server) ส่วนประกอบส่วนใหญ่ของดิสก์และเครือข่ายจะเป็นโมดูล ซึ่งเป็นเหตุผลว่าทำไม kernel image เพียงชุดเดียวจึงสามารถบูตบนฮาร์ดแวร์ที่ไม่เคยรู้จักมาก่อนได้

โมดูลช่วยให้ได้ความยืดหยุ่นดังกล่าวโดยไม่ต้องแบกรับต้นทุนที่การออกแบบ microkernel ต้องเผชิญ การแยกไดรเวอร์ไว้ในกระบวนการของตัวเองหมายถึงการต้องเสียค่าใช้จ่ายในการทำ context switch และการส่งข้อความในทุกการเรียกใช้งาน ซึ่งในปี 1992 ต้นทุนส่วนนี้ถือว่าสูงมาก

ต้นทุนที่ Linux ยังคงต้องแบกรับและเป็นสิ่งที่ต้องวางแผนรับมือคือ โมดูลจะทำงานด้วยสิทธิ์ระดับ kernel เต็มรูปแบบ ดังนั้นโมดูลที่บกพร่องจะทำให้เครื่องทั้งเครื่องหยุดทำงานแทนที่จะเป็นเพียงกระบวนการเดียว ปัญหานี้มักเกิดขึ้นกับโมดูลที่อยู่นอกเหนือจาก mainline ไดรเวอร์จากผู้ผลิตที่ไม่ได้รวมอยู่ใน mainline จะต้องถูกคอมไพล์ใหม่ทุกครั้งที่มีการอัปเดต kernel ซึ่งเป็นหน้าที่ของ DKMS ในระหว่างการอัปเกรด และเมื่อการคอมไพล์นั้นล้มเหลว อุปกรณ์ดังกล่าวก็จะใช้งานไม่ได้ทันทีหลังจากรีบูตเครื่อง

เหตุใด SMP จึงใช้เวลาถึงสิบห้าปีในการพัฒนาจนเสร็จสมบูรณ์

Linux 2.0 ในเดือนมิถุนายน 1996 เป็น kernel รุ่นแรกที่รองรับ symmetric multiprocessing (SMP) ซึ่งหมายถึงการที่ CPU มากกว่าหนึ่งตัวสามารถรัน kernel เดียวกันได้ การนำมาใช้งานในยุคแรกใช้ lock เพียงตัวเดียวที่เรียกว่า big kernel lock (BKL) ส่งผลให้มีเพียงโปรเซสเซอร์เดียวเท่านั้นที่สามารถทำงานภายในโค้ดของ kernel ได้ในขณะใดขณะหนึ่ง ดังนั้น CPU ตัวที่สองจึงช่วยแบ่งเบาภาระงานที่ประมวลผลใน user space ได้ แต่แทบไม่ช่วยงานที่ต้องเรียกใช้ system calls เลย เนื่องจากงานเหล่านั้นต้องเข้าคิวรอหลัง lock ตัวเดียวกัน

การกำจัด lock ดังกล่าวใช้เวลาถึงสิบห้าปี ผู้ใช้งานที่เหลืออยู่ถูกเปลี่ยนไปใช้ fine-grained locking ซึ่งส่วนใหญ่ดำเนินการโดย Arnd Bergmann และ BKL ได้ถูกลบออกในรุ่น 2.6.39 ซึ่งปล่อยออกมาเมื่อวันที่ 18 พฤษภาคม 2011 ส่วน scheduler ก็มีการพัฒนาไปในกรอบเวลาที่ช้าเช่นเดียวกัน ได้แก่ O(1) scheduler ในรุ่น 2.6.0, Completely Fair Scheduler (CFS) ตั้งแต่รุ่น 2.6.23 ในปี 2007 และ EEVDF ซึ่งเข้ามาแทนที่ CFS ในรุ่น 6.6 เมื่อเดือนตุลาคม 2023

งานเหล่านั้นคือเหตุผลที่ทำให้แผนการใช้งาน 4 vCPU กลายเป็นเรื่องปกติในปัจจุบัน นอกจากนี้ยังเป็นข้อจำกัดที่ควรทราบ บนเซิร์ฟเวอร์เสมือนแบบแบ่งใช้ (shared virtual server) kernel ของคุณจะทำหน้าที่จัดตารางเวลาให้กับ thread ต่างๆ ของคุณ ในขณะที่ hypervisor จะทำหน้าที่จัดตารางเวลาให้กับ kernel ของคุณ ให้รันคำสั่ง top แล้วอ่านค่าในฟิลด์ %st ค่า Steal time คือเวลาของ CPU ที่ kernel ของคุณพร้อมใช้งานแต่โฮสต์กลับจัดสรรไปให้ guest ตัวอื่น ดังนั้นการปรับแต่งภายใน kernel ของคุณจึงไม่สามารถกู้คืนเวลานี้กลับมาได้

เหตุใดซีรีส์ 2.6 จึงเปลี่ยนวิธีการสร้างเคอร์เนล

ก่อนหน้าเวอร์ชัน 2.6 หมายเลขเวอร์ชันจะมาเป็นคู่ ตัวเลขหลักที่สองที่เป็นเลขคู่หมายถึงซีรีส์ที่มีความเสถียร (2.4) ส่วนเลขคี่หมายถึงรุ่นพัฒนา (2.5) เวอร์ชัน 2.4 ถูกปล่อยออกมาเมื่อวันที่ 4 มกราคม 2001 และ 2.6 ในวันที่ 17 ธันวาคม 2003 ทำให้ผู้ใช้ต้องรอเกือบสามปีกว่าจะได้ซีรีส์ที่มีความเสถียรชุดถัดไป บรรดาผู้จัดทำ Linux distribution รอไม่ไหวจึงใช้วิธี backport ทำให้ผู้จำหน่ายสองรายที่ต่างก็ระบุว่าใช้ "2.4" มีเคอร์เนลที่แตกต่างกันด้วย patch นับพันรายการ

การแบ่งแยกดังกล่าวถูกยกเลิกไปหลังจากเวอร์ชัน 2.6 ปัจจุบัน mainline จะเปิดหน้าต่างการรวมโค้ด (merge window) ประมาณสองสัปดาห์เพื่อรับงานใหม่ จากนั้นจะปล่อย release candidate ออกมาจนกว่าสถานการณ์จะนิ่ง และจะออกเวอร์ชันใหม่ทุก 9 ถึง 10 สัปดาห์ ซึ่งเป็นจังหวะการทำงานที่ kernel.org ยังคงระบุไว้ในเอกสาร อีกครึ่งหนึ่งของโมเดลนี้เกิดขึ้นเมื่อวันที่ 4 มีนาคม 2005 ด้วยการปล่อย stable tree รุ่นแรก ซึ่งเป็นการอัปเดตเฉพาะการแก้ไขข้อผิดพลาดให้กับ 2.6.11 โดยมี Greg Kroah-Hartman และ Chris Wright เป็นผู้ดูแล stable tree จะรับเฉพาะการแก้ไขและปฏิเสธการเพิ่มฟีเจอร์ใหม่

ผลข้างเคียงประการหนึ่งคือ หมายเลขเวอร์ชันไม่ได้เป็นคำมั่นสัญญาอีกต่อไป เวอร์ชัน 3.0, 4.0, 5.0 และ 7.0 ไม่ใช่การเขียนโค้ดใหม่ทั้งหมด Torvalds จะปรับตัวเลขหลักแรกขึ้นเมื่อตัวเลขหลักที่สองมีค่ามากจนน่ารำคาญ ซึ่งเป็นเหตุผลว่าทำไม 7.0 จึงตามหลัง 6.19 ในเดือนเมษายน 2026 สิ่งที่สำคัญสำหรับเซิร์ฟเวอร์คือ branch ที่ distribution ของคุณติดตาม และ branch นั้นยังคงได้รับการแก้ไขข้อผิดพลาดอยู่หรือไม่

จุดเริ่มต้นของ git จากเหตุการณ์ความขัดแย้งเรื่อง BitKeeper ในเดือนเมษายน 2005

ตั้งแต่เดือนกุมภาพันธ์ 2002 เคอร์เนลถูกพัฒนาโดยใช้ BitKeeper ซึ่งเป็นระบบควบคุมเวอร์ชันแบบกระจายศูนย์ที่เป็นกรรมสิทธิ์ของบริษัท BitMover ของ Larry McVoy โดยเริ่มตั้งแต่ซีรีส์ 2.5 เป็นต้นมา BitMover ได้มอบสิทธิ์การใช้งานฟรีให้แก่ผู้พัฒนาเคอร์เนลโดยมีเงื่อนไขว่า ห้ามพัฒนาเครื่องมือควบคุมเวอร์ชันที่เป็นคู่แข่ง และห้ามทำวิศวกรรมย้อนกลับ (reverse engineer) BitKeeper นักพัฒนาจำนวนมากไม่พอใจที่ต้องสร้างเคอร์เนลเสรีด้วยเครื่องมือที่พวกเขาไม่มีสิทธิ์ตรวจสอบการทำงานภายใน

ความสัมพันธ์ขาดสะบั้นลงในเดือนเมษายน 2005 หลังจาก Andrew Tridgell ได้สาธิตโปรแกรมที่สามารถสื่อสารกับ repository ของ BitKeeper ได้ ทาง BitMover อ้างว่านั่นคือการทำวิศวกรรมย้อนกลับและได้เพิกถอนสิทธิ์การใช้งานฟรี ส่งผลให้เคอร์เนลสูญเสียระบบควบคุมเวอร์ชันไปในระหว่างรอบการพัฒนา

การพัฒนา git เริ่มต้นขึ้นเมื่อวันที่ 3 เมษายน 2005 และ Torvalds ได้ประกาศเปิดตัวในวันที่ 6 เมษายน ภายในวันที่ 7 เมษายน git ก็สามารถ self-hosting ได้สำเร็จ ซึ่งหมายความว่าประวัติการทำงานของ git เองถูกจัดเก็บไว้ใน git เรียบร้อยแล้ว การรวม branch (merge) หลายสายครั้งแรกเกิดขึ้นในวันที่ 18 เมษายน และในเดือนมิถุนายน 2005 git ก็ได้เข้ามาจัดการการปล่อยเวอร์ชัน 2.6.12 หลังจากนั้นไม่นาน Torvalds ได้ส่งมอบหน้าที่การดูแลรักษาให้แก่ Junio Hamano และกลับไปโฟกัสที่งานเคอร์เนลต่อ

การออกแบบ git เกิดขึ้นโดยตรงจากปัญหาที่พบ คือการมีผู้ร่วมพัฒนาหลายพันคน และผู้ดูแลโปรเจกต์ที่ต้องดึงข้อมูล (pull) จากกันผ่านเครือข่ายที่ไม่สามารถไว้วางใจได้ วัตถุทุกชิ้นใน git จะถูกระบุด้วยค่า hash ของเนื้อหา ดังนั้นการเปลี่ยนแปลงข้อมูลเพียงหนึ่งไบต์ในประวัติเก่าจะส่งผลให้ชื่อของ commit ทุกตัวที่ตามมาเปลี่ยนไปทั้งหมด นี่คือเหตุผลที่การ clone ข้อมูลใน git ถือเป็นหลักฐานที่ยืนยันความถูกต้องได้มากกว่าเพียงแค่การอ้างอิง ทุกไปป์ไลน์การ deploy, ทุก repository สำหรับเก็บค่าคอนฟิก, โฮสต์เก็บโค้ดที่ทีมส่วนใหญ่ใช้งาน และ เซิร์ฟเวอร์ git ที่คุณสามารถติดตั้งใช้งานเองได้ ล้วนมีจุดกำเนิดมาจากข้อพิพาทเรื่องสิทธิ์การใช้งานของเครื่องมือตัวหนึ่งในอดีต

สิ่งที่โมเดล LTS รับประกันและสิ่งที่ไม่ได้รับประกัน

Mainline ไม่ใช่สิ่งที่คุณควรนำไปใช้งานจริง เพราะรุ่น mainline จะถูกแทนที่ด้วยรุ่นใหม่ในอีก 9 ถึง 10 สัปดาห์ถัดมา ส่วน stable tree จะมีการแก้ไขข้อผิดพลาดเพียงไม่กี่สัปดาห์หลังจากแต่ละรุ่นออกวางจำหน่าย ในขณะที่สาขา Longterm หรือที่มักเรียกกันว่า LTS จะมีการดูแลรักษาต่อเนื่องนานหลายปี ซึ่งเป็นสาขาที่บรรดา Linux distribution ต่างๆ เลือกใช้เป็นฐานในการพัฒนา

รุ่น 2.6.32 ซึ่งออกวางจำหน่ายในเดือนธันวาคม 2009 คือจุดที่พิสูจน์ความสำเร็จของโมเดลนี้ โดย RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 และ Ubuntu 10.04 LTS ต่างเลือกใช้รุ่นนี้ และสาขานี้ได้รับการดูแลรักษาจนถึงเดือนกุมภาพันธ์ 2016 ซึ่งเป็นเวลานานกว่าหกปีหลังจากที่เปิดตัวครั้งแรก

คำมั่นสัญญาเรื่องระยะเวลาการดูแลรักษาได้มีการเปลี่ยนแปลงมากกว่าหนึ่งครั้ง เดิมกำหนดไว้ที่สองปี จากนั้นขยายเป็นหกปีสำหรับบางสาขา ในปี 2023 ผู้ดูแล stable tree ได้ปรับลดระยะเวลามาตรฐานกลับมาเหลือสองปี เนื่องจากภาระงานในการ backport แก้ไขไปยังสาขาเก่าใช้เวลามากและสาขาเก่าเหล่านั้นแทบไม่ได้รับการทดสอบจริง ในวันที่ 25 กุมภาพันธ์ 2026 Greg Kroah-Hartman ได้ประกาศแผนการสนับสนุนระยะยาวอีกครั้งหลังจากหารือร่วมกับบริษัทต่างๆ ที่ต้องพึ่งพาสาขาเหล่านั้น โดยกรอบการทำงานปัจจุบันมีระยะเวลาตั้งแต่สามถึงหกปี

[
  {
    "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
  }
]

kernel.org แสดงรายการสาขา longterm จำนวน 6 สาขา ณ เดือนสิงหาคม 2026 โดยสาขาที่เก่าที่สุดคือ 5.10 จะได้รับการแก้ไขข้อผิดพลาดเป็นเวลา 6.0 ปี จนกระทั่งสิ้นสุดการสนับสนุนในวันที่ Dec 2026 ส่วนสาขาใหม่ล่าสุดคือ 6.18 มีกำหนดการสนับสนุนจนถึงวันที่ Dec 2028 ซึ่งคิดเป็นระยะเวลาการแก้ไขข้อผิดพลาด 3.1 ปี

โปรดอ่านวันที่เหล่านี้ในฐานะค่าขั้นต่ำไม่ใช่สัญญาผูกมัด กำหนดการของรุ่น 6.6 และ 6.12 ต่างถูกขยับออกไปในเดือนกุมภาพันธ์ 2026 และสาขาที่ไม่มีผู้ใช้งานก็อาจถูกยกเลิกการสนับสนุนได้เช่นกัน โดยปกติแล้ว Linux distribution ของคุณจะเป็นผู้เลือกให้ เช่น Debian 13 ใช้รุ่น 6.12 และ Ubuntu 26.04 LTS ใช้รุ่น 7.0 ช่องว่างระหว่างรุ่นเหล่านี้คือเนื้อหาสำคัญของ คำถามเรื่อง LTS เทียบกับรุ่น interim บนเซิร์ฟเวอร์ และเป็นสิ่งที่เปลี่ยนแปลงไปจริงๆ ภายใต้ระบบของคุณเมื่อ คุณอัปเกรด Ubuntu 24.04 เป็น 26.04

กับดักประการหนึ่งที่เกิดขึ้นจากเรื่องนี้คือ uname -r บน Ubuntu 24.04 จะแสดงผลลัพธ์ในลักษณะ 6.8.0-51-generic ซึ่งนั่นคือรุ่นพื้นฐานจาก upstream รวมกับ backports ของทาง distribution เอง ดังนั้นตัวเลขดังกล่าวจึงบอกเพียงจุดเริ่มต้นของสาขา ไม่ใช่รายการแก้ไขทั้งหมดที่รวมอยู่ภายใน เครื่องมือสแกนที่ตัดสินความปลอดภัยของ kernel จากเวอร์ชัน string มักจะแจ้งเตือนผิดพลาดกับ kernel ของ distribution ด้วยเหตุผลนี้เอง

สิ่งที่เคอร์เนลกำลังถกเถียงกันอยู่ในขณะนี้

ขณะนี้มีข้อถกเถียงสำคัญอยู่ 2 ประเด็น ซึ่งทั้งสองเรื่องเกี่ยวข้องกับว่าใครเป็นผู้รับผิดชอบงาน

Rust ถูกนำเข้ามาเป็นโครงสร้างพื้นฐานในเวอร์ชัน 6.1 เมื่อเดือนธันวาคม 2022 ในเวอร์ชัน 7.0 ป้ายกำกับสถานะทดลอง (experimental) ได้ถูกถอดออก ทำให้ภาษาหลักของเคอร์เนลประกอบด้วย C, assembly และ Rust โดยการ build ไม่จำเป็นต้องใช้ nightly compiler อีกต่อไป ข้อพิพาทที่เกิดขึ้นคือเรื่องการบำรุงรักษา ผู้ดูแลโค้ดภาษา C ที่ทำการเปลี่ยนแปลงอินเทอร์เฟซอาจทำให้ Rust bindings ที่ตนเองไม่ได้อ่านโค้ดนั้นเสียหายได้ และข้อถกเถียงคือใครมีหน้าที่ต้องแก้ไขส่วนที่เสียหายเหล่านั้น

ประเด็นที่สองคือการมีส่วนร่วมของ AI โดย Sasha Levin ได้เสนอแนวทางปฏิบัติในเดือนกรกฎาคม 2025 หลังจากที่มีการส่ง patch ที่สร้างโดยเครื่องมือเพิ่มขึ้นอย่างต่อเนื่องในรายการส่งเมล เอกสารดังกล่าวถูกบรรจุลงในระบบเมื่อวันที่ 23 ธันวาคม 2025 และปัจจุบันอยู่ในเอกสารกระบวนการทำงานของเคอร์เนลที่ docs.kernel.org/process/coding-assistants.html ตัวแทน AI จะต้องไม่เพิ่มแท็ก Signed-off-by เนื่องจากบรรทัดดังกล่าวเป็นการรับรอง Developer Certificate of Origin (DCO) ซึ่งมีเพียงบุคคลเท่านั้นที่สามารถรับรองได้ การได้รับความช่วยเหลือจะต้องระบุด้วยแท็ก Assisted-by: ซึ่งเปลี่ยนมาจาก Co-developed-by: ในระหว่างการตรวจสอบ เนื่องจากเครื่องมือไม่ใช่ผู้เขียน โค้ดที่สร้างขึ้นต้องเข้ากันได้กับ GPL-2.0-only มนุษย์ที่เป็นผู้ส่ง patch จะต้องเป็นผู้ตรวจสอบและรับผิดชอบต่อโค้ดนั้น

แรงกดดันที่อยู่เบื้องหลังนโยบายนี้คือเวลาในการตรวจสอบ การสร้าง patch ใช้เวลาเพียงไม่กี่วินาที แต่การตรวจสอบต้องใช้เวลาของผู้ดูแลตลอดทั้งบ่าย การติดแท็กไม่ได้ช่วยแก้ไขความไม่สมดุลนี้ สิ่งที่นโยบายนี้รักษาไว้คือที่มาของโค้ด (provenance) โดยประวัติการแก้ไขจะยังคงบันทึกว่าใครเป็นผู้ลงนามรับรองการเปลี่ยนแปลงแต่ละครั้ง ซึ่งเป็นคุณสมบัติที่ DCO ถูกนำมาใช้เพื่อปกป้องตั้งแต่ปี 2004

ความหมายของประวัติศาสตร์นี้ต่อเซิร์ฟเวอร์ที่คุณเช่า

• สัญญาอนุญาตคือเหตุผลที่คุณสามารถอ่านและสร้าง kernel ใหม่ที่คุณใช้บูตเซิร์ฟเวอร์ได้ และเป็นเหตุผลที่ซอฟต์แวร์แบบปิด (proprietary software) ยังคงทำงานบนเซิร์ฟเวอร์นั้นได้
• การออกแบบแบบ monolithic คือเหตุผลที่บั๊กของไดรเวอร์เพียงตัวเดียวทำให้เครื่องทั้งเครื่องรีบูต และเป็นเหตุผลที่โมดูลแบบ out-of-tree ต้องถูกสร้างใหม่ทุกครั้งที่มีการอัปเกรด kernel
• รูปแบบการปล่อยซอฟต์แวร์ (release model) คือเหตุผลที่เลขเวอร์ชันบอกข้อมูลคุณได้น้อย ในขณะที่ branch และวันสิ้นสุดอายุการใช้งาน (end-of-life date) บอกข้อมูลคุณได้เกือบทั้งหมด
• ประเภทของ virtualisation เป็นตัวกำหนดสิ่งที่คุณสามารถทำได้: บน KVM คุณสามารถบูต kernel ของคุณเองและโหลดโมดูลได้ ในขณะที่บน container virtualisation ซึ่งใช้ kernel ร่วมกับโฮสต์ uname -r จะแสดงเวอร์ชันของโฮสต์ modprobe จะทำงานล้มเหลว และ sysctl หลายรายการจะถูกตั้งค่าเป็นแบบอ่านได้อย่างเดียว (read-only)

FAQ

ทำไม Linux kernel ถึงยังเป็น GPLv2 ไม่ใช่ GPLv3?

Torvalds ตัดสินใจไม่ใช้ GPLv3 ในปี 2007 โดยมีสาเหตุหลักมาจากข้อกำหนดเรื่อง anti-tivoisation ซึ่งบังคับให้อุปกรณ์ที่ใช้โค้ด GPL ต้องยอมรับโค้ดเวอร์ชันที่ถูกแก้ไขด้วย เขาถือว่าการล็อกฮาร์ดแวร์เป็นเรื่องของทางผู้ผลิต นอกจากนี้ การเปลี่ยนสัญญาอนุญาตในทางปฏิบัติแทบจะเป็นไปไม่ได้เลย เนื่องจากลิขสิทธิ์ใน kernel ถือครองโดยผู้ร่วมพัฒนาหลายพันคนและไม่มีข้อตกลงการโอนสิทธิ์ที่สามารถนำมาอ้างอิงได้ ตัว kernel เป็น GPL-2.0-only ดังนั้นโค้ดที่เสนอมาภายใต้ GPLv3 เพียงอย่างเดียวจึงไม่สามารถรวมเข้ากับโปรเจกต์ได้

Linux kernel เป็น monolithic kernel หรือ microkernel?

เป็น monolithic kernel ที่สามารถโหลดโมดูลได้ ไดรเวอร์และระบบไฟล์ทำงานอยู่ใน address space ของ kernel และ lsmod จะแสดงรายการโมดูลที่โหลดอยู่ในขณะนี้ ผลลัพธ์คือความเร็วในด้านหนึ่งและความเสี่ยงในอีกด้านหนึ่ง: โมดูลที่ผิดพลาดอาจทำให้เครื่องทั้งเครื่องเกิด kernel panic ได้ ในขณะที่ microkernel จะสูญเสียเพียงแค่ process เดียวเท่านั้น ภาพรวมของเรื่องนี้เริ่มเปลี่ยนไปตั้งแต่ปี 1992 ผ่านทางระบบไฟล์ FUSE ใน user space และโปรแกรม eBPF ที่ kernel จะตรวจสอบความถูกต้องก่อนเริ่มทำงาน

ความแตกต่างระหว่าง mainline, stable และ longterm kernel คืออะไร?

Mainline คือ tree ของ Torvalds ซึ่งมีการปล่อยเวอร์ชันใหม่ทุก 9 ถึง 10 สัปดาห์ และฟีเจอร์ใหม่จะถูกรวมไว้ที่นี่เป็นที่แรก ส่วน Stable จะนำเวอร์ชัน mainline ล่าสุดมาแก้ไขบั๊กเป็นเวลาสองสามสัปดาห์ สำหรับ Longterm branch จะได้รับการแก้ไขต่อเนื่องเป็นเวลาหลายปี และเป็นเวอร์ชันที่ distribution ต่างๆ ใช้สร้าง kernel ของตนเอง โดย kernel.org จะแสดงรายการ longterm branch ปัจจุบันพร้อมกับวันที่สิ้นสุดการสนับสนุน (end-of-life) ของแต่ละเวอร์ชัน

Linux kernel ยอมรับโค้ดที่เขียนโดย AI หรือไม่?

ยอมรับ ภายใต้นโยบายที่ประกาศใช้ในเดือนธันวาคม 2025 โดยต้องระบุชื่อเครื่องมือในแท็ก Assisted-by:, AI agent ต้องไม่เพิ่มบรรทัด Signed-off-by และโค้ดที่สร้างขึ้นต้องเข้ากันได้กับ GPL-2.0-only ผู้ส่งที่เป็นมนุษย์จะต้องทำการ sign off ซึ่งหมายความว่าพวกเขาได้ตรวจสอบ patch นั้นแล้วและรับผิดชอบภายใต้ Developer Certificate of Origin

ควรใช้ kernel เวอร์ชันใดบนเซิร์ฟเวอร์?

ในเกือบทุกกรณี ควรใช้เวอร์ชันที่ distribution ของคุณดูแลอยู่ kernel ของ distribution คือ longterm branch ที่รวมการแก้ไขแบบ backported และผ่านการทดสอบจากผู้จำหน่ายแล้ว ซึ่งเป็นสิ่งที่ image ของผู้ให้บริการและข้อตกลงการสนับสนุนของคุณอ้างอิงถึง ให้สร้าง kernel เวอร์ชัน mainline ใหม่ก็ต่อเมื่อคุณต้องการไดรเวอร์หรือฟีเจอร์เฉพาะ และควรตรวจสอบวันที่สิ้นสุดการสนับสนุนของ branch ที่คุณกำลังจะย้ายไปก่อนที่จะตัดสินใจใช้งาน