ประวัติ Linux kernel ตั้งแต่เวอร์ชัน 0.01 ถึง 7.x

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

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

วันที่และหมายเลขเวอร์ชันในที่นี้อ้างอิงจาก 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 ในเวลาต่อมาล้วนตั้งอยู่บนการเปลี่ยนแปลงครั้งนั้น

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

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

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

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

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

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

lsmod | head
modinfo virtio_net | head -5

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

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

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

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

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

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

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

คำมั่นสัญญานี้มีการเปลี่ยนแปลงมากกว่าหนึ่งครั้ง เดิมทีคือสองปี จากนั้นเพิ่มเป็นหกปีสำหรับบางสาขา ในปี 2023 ผู้ดูแล stable ได้ปรับลดระยะเวลาเริ่มต้นกลับมาเหลือสองปี เนื่องจากการ backport เข้าสู่ tree เก่าใช้เวลาของผู้ดูแลมากและสาขาเก่าแทบไม่ได้รับการทดสอบจริง ในวันที่ 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 และสาขาที่ไม่มีใครใช้งานอาจถูกยกเลิกก่อนกำหนดได้ ระบบปฏิบัติการของคุณมักจะเป็นผู้เลือกให้คุณโดยอัตโนมัติ เช่น 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 ของตัวระบบปฏิบัติการเอง ดังนั้นตัวเลขดังกล่าวจึงบอกเพียงว่าสาขานั้นเริ่มต้นที่จุดใด ไม่ใช่บอกว่ามีการแก้ไขใดบ้างที่รวมอยู่ภายใน เครื่องมือสแกนที่ตัดสิน kernel จากสตริงเวอร์ชันจึงมักแจ้งเตือนผิดพลาดกับ kernel ของระบบปฏิบัติการด้วยเหตุผลนี้เอง

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

ขณะนี้มีประเด็นถกเถียงอยู่ 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 นั้น

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

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

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

FAQ

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

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

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

เป็น monolithic kernel ที่รองรับการโหลดโมดูล ไดรเวอร์และระบบไฟล์ทำงานภายในพื้นที่หน่วยความจำของ kernel และ lsmod จะแสดงรายการโมดูลที่โหลดอยู่ในขณะนี้ ผลลัพธ์คือความเร็วในด้านหนึ่ง แต่ก็มีความเสี่ยงในอีกด้านหนึ่ง: โมดูลที่ผิดพลาดอาจทำให้เครื่องทั้งเครื่องหยุดทำงาน (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 ที่รวมการ backport แก้ไขบั๊กและการทดสอบจากผู้จำหน่าย ซึ่งเป็นสิ่งที่ image ของผู้ให้บริการและข้อตกลงการสนับสนุนของคุณอ้างอิงถึง ให้สร้าง kernel เวอร์ชัน mainline ใหม่ก็ต่อเมื่อคุณต้องการไดรเวอร์หรือฟีเจอร์เฉพาะ และควรตรวจสอบวันที่สิ้นสุดการสนับสนุนของ branch ที่คุณกำลังจะย้ายไปก่อนตัดสินใจใช้งาน