ประวัติศาสตร์ Linux distribution และจุดกำเนิดสายพันธุ์

Linux distribution คืออะไรกันแน่

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

มันประกอบด้วย 5 ส่วน หากเปลี่ยนส่วนใดส่วนหนึ่งไป คุณจะได้ distribution ใหม่ทันที แม้ว่าไฟล์ binary ส่วนใหญ่จะเหมือนกันก็ตาม:

• Kernel: ในเวอร์ชันที่โครงการเลือกใช้ พร้อมด้วย patch และ driver ที่เพิ่มเข้าไป
• Userland: ประกอบด้วย C library, shell, init system และคำสั่งมาตรฐานต่างๆ
• รูปแบบของ package และเครื่องมือที่ใช้ในการติดตั้ง
• นโยบายการ release: สิ่งที่สามารถเปลี่ยนแปลงได้ ความถี่ในการออกรุ่น และระยะเวลาที่แต่ละรุ่นจะได้รับการแก้ไข
• ผู้คน: ผู้ดูแล package, ทีมรักษาความปลอดภัย และผู้ที่คอยตอบคำถามเมื่อ package เกิดปัญหา

Kernel เป็นส่วนที่ใช้ร่วมกัน ดังนั้น Linux distribution สองตัวจึงมีความใกล้เคียงกันมากกว่าเมื่อเทียบกับ Unix ตัวอื่น นี่เป็นประเด็นที่ควรคำนึงถึงเมื่อคุณเปรียบเทียบ Linux และ FreeBSD ในฐานะแพลตฟอร์มเซิร์ฟเวอร์ ซึ่งในกรณีของ FreeBSD นั้น kernel และ base userland ถูกสร้างโดยโครงการเดียวกันและออกรุ่นพร้อมกัน แต่สำหรับ Linux ชิ้นส่วนเหล่านี้มาจาก upstream ที่แยกจากกัน และ distribution คือสิ่งที่ทำให้ส่วนประกอบเหล่านั้นทำงานร่วมกันได้

ประวัติของ Linux distributions ใน 3 ตระกูลหลัก

โครงการ 3 โครงการที่เริ่มต้นในปี 1993 และ 1994 ได้กลายเป็นตระกูลหลัก ได้แก่ Slackware, Debian และ Red Hat โดยอิมเมจเกือบทั้งหมดในแผงควบคุม VPS ในปัจจุบันล้วนเป็นหนึ่งในตระกูลเหล่านี้หรือเป็นรุ่นที่สืบทอดต่อกันมา รุ่นที่สืบทอดจะได้รับรูปแบบแพ็กเกจ โครงสร้างไฟล์ และมักจะรวมถึงธรรมเนียมการออกรุ่น (release habits) มาด้วย ซึ่งเป็นเหตุผลว่าทำไมรุ่นที่แตกแขนงมาจาก Debian ถึงยังคงให้ความรู้สึกเหมือน Debian แม้จะเปลี่ยนการสร้างแบรนด์ไปแล้วก็ตาม

กลุ่มที่เป็นอิสระควรถูกแยกออกมาต่างหาก เพราะไม่ได้แตกแขนงมาจากใคร โดย Arch, Gentoo, Alpine, NixOS และ Void ต่างเขียนตัวจัดการแพ็กเกจและกำหนดกฎเกณฑ์ของตนเองขึ้นมาใหม่ทั้งหมด ทั้งนี้ Arch และ Alpine ได้กลายเป็นส่วนหนึ่งในรายการอิมเมจของผู้ให้บริการของคุณในที่สุด ด้วยเหตุผลที่ไม่ได้เกี่ยวข้องกับเรื่องเดสก์ท็อปเลยแม้แต่น้อย

1992: การแจกจ่ายก่อนยุคตระกูล Linux

MCC Interim Linux ปรากฏขึ้นในเดือนกุมภาพันธ์ 1992 โดย Owen Le Blanc จาก Manchester Computing Centre เป็นผู้รวบรวม ระบบนี้บรรจุ kernel และเครื่องมือ GNU (GNU's not Unix) ลงในแผ่น floppy disk สองแผ่นพร้อมตัวติดตั้งแบบเมนู สาเหตุที่ระบบนี้เกิดขึ้นเพราะการติดตั้งด้วยตนเองในสมัยนั้นต้องใช้เวลาทำงานถึงหนึ่งวันเต็ม

SLS (Softlanding Linux System) ซึ่งปล่อยออกมาโดย Peter MacDonald ในปี 1992 ได้ขยายขีดความสามารถเพิ่มขึ้นโดยรวม X (X Window System) และระบบเครือข่าย TCP/IP เข้าไปด้วย SLS คือเหตุผลที่คำว่า distribution (การแจกจ่าย) มีความหมายอย่างที่เป็นอยู่ในปัจจุบัน อย่างไรก็ตาม SLS มีข้อผิดพลาดจำนวนมากและได้รับการดูแลอย่างล่าช้า ในปี 1993 จึงมีบุคคลสองคนตัดสินใจแก้ไขปัญหานี้แยกกัน คนหนึ่งเลือกที่จะสร้างใหม่ทั้งหมด ส่วนอีกคนเลือกที่จะเริ่มต้นใหม่โดยใช้กฎเกณฑ์ที่เขียนขึ้นอย่างชัดเจน

Slackware ปี 1993: ตระกูลที่เก่าแก่ที่สุดที่ยังมีการเผยแพร่

Patrick Volkerding เผยแพร่ Slackware 1.00 เมื่อวันที่ 16 กรกฎาคม 1993 โดยสร้างขึ้นจาก SLS ที่ได้รับการแก้ไขบั๊กแล้ว ปัจจุบันยังคงมีการดูแลรักษาอยู่ ทำให้เป็น Linux distribution ที่เก่าแก่ที่สุดที่ยังคงอยู่มาจนถึงปัจจุบัน

แพ็กเกจของ Slackware คือไฟล์ tar ที่ถูกบีบอัดและมีสคริปต์ติดตั้งอยู่ภายใน ระบบไม่มีการตรวจสอบ dependency: ไม่มีกลไกใดตรวจสอบว่า library ที่แพ็กเกจใหม่ของคุณต้องการนั้นมีอยู่ในดิสก์แล้วหรือไม่ การตัดสินใจเพียงข้อเดียวนั้นส่งผลต่อทุกสิ่ง หากเครื่องมือไม่แก้ไข dependency ให้ ชุดซอฟต์แวร์ที่เผยแพร่ออกมาจึงต้องมีความสอดคล้องกันโดยโครงสร้าง ทำให้การออกรุ่นใหม่เกิดขึ้นได้ยากและเน้นความปลอดภัยเป็นหลัก Slackware 15.0 ออกมาในเดือนกุมภาพันธ์ 2022 ซึ่งห่างจากรุ่น 14.2 ถึง 6 ปี

ตระกูลนี้มีขนาดเล็ก รุ่นแรกๆ ของ SUSE ในช่วงกลางทศวรรษ 1990 สร้างขึ้นบนพื้นฐานของ Slackware ก่อนที่โครงการจะแยกตัวออกไปใช้แนวทางของตนเองด้วย YaST และในเวลาต่อมาคือรูปแบบแพ็กเกจ RPM ส่วนหลังนี้ทำให้ผู้คนสับสน SUSE และ openSUSE ใช้แพ็กเกจ RPM แต่ไม่ได้เป็นอนุพันธ์ของ Red Hat รูปแบบไฟล์นั้นถูกนำไปใช้ต่อ แต่สายเลือดของระบบไม่ได้สืบทอดกันมา

Debian, 1993: สัญญาประชาคมและไปป์ไลน์สามชุด

Ian Murdock ประกาศเปิดตัว Debian เมื่อวันที่ 16 สิงหาคม 1993 ซึ่งเป็นเวลาสามสัปดาห์หลังจาก Slackware และด้วยเหตุผลเดียวกัน ชื่อนี้เป็นการรวมชื่อของ Debra คู่ชีวิตของเขากับชื่อของเขาเอง Debian Manifesto ตามมาในเดือนมกราคม 1994 และกำหนดเงื่อนไขไว้ว่า: ดิสทริบิวชันนี้จะได้รับการดูแลแบบเปิดโดยอาสาสมัคร ไม่ใช่โดยบริษัท

จากนั้น Debian ได้เขียนเงื่อนไขเหล่านั้นลงเป็นลายลักษณ์อักษร Debian Social Contract และ DFSG (Debian free software guidelines) ได้รับการยอมรับในเดือนกรกฎาคม 1997 และ DFSG ได้กลายเป็นพื้นฐานของ Open Source Definition ในปี 1998 เอกสารที่เขียนขึ้นเพื่อตัดสินว่าสิ่งใดควรอยู่ในดิสทริบิวชันหนึ่ง กลับกลายเป็นการกำหนดหมวดหมู่ใบอนุญาตสำหรับอุตสาหกรรมทั้งหมด นี่คือเหตุผลว่าทำไม sources.list ของคุณจึงมีส่วนประกอบต่างๆ: main เก็บซอฟต์แวร์ที่ตรงตามแนวทางปฏิบัติ ส่วน contrib และ non-free เก็บสิ่งที่ไม่ได้ตรงตามแนวทางดังกล่าว และ Debian 12 ได้เพิ่ม non-free-firmware เข้ามาเพื่อให้แล็ปท็อปที่มีการ์ดไร้สายสามารถติดตั้งได้โดยไม่ต้องคอยหาไดรเวอร์เอง

เครื่องมือจัดการแพ็กเกจคือมรดกอีกอย่างหนึ่ง dpkg ติดตั้งแพ็กเกจหนึ่งรายการและจะปฏิเสธการทำงานหากมีบางอย่างขาดหายไป โดยแสดง dpkg: dependency problems prevent configuration of ออกมา APT (advanced package tool) ซึ่งกลายเป็นค่าเริ่มต้นตั้งแต่ Debian 2.1 ในปี 1999 คือเลเยอร์ที่ทำหน้าที่คำนวณว่าต้องดึงข้อมูลอะไรเพิ่มเติมและในลำดับใด คำสั่ง apt ทุกคำสั่งบน Debian ทุกรุ่นที่แตกแขนงออกมาล้วนสืบทอดมาจากงานชิ้นนั้น

กลไกการออกรุ่นมีสามชุดและหนึ่งกฎ ผู้ดูแลแพ็กเกจจะอัปโหลดไปยัง unstable ซึ่งมีชื่อรหัสถาวรว่า sid สคริปต์จะย้ายแพ็กเกจเข้าสู่ testing หลังจากผ่านไปประมาณ 5 ถึง 10 วัน หากแพ็กเกจนั้นสร้างบนสถาปัตยกรรมที่รองรับได้สำเร็จและไม่มีบั๊กวิกฤตใหม่เกิดขึ้น จากนั้น testing จะเข้าสู่สถานะ freeze ทีมงานออกรุ่นจะจัดการสิ่งที่เหลืออยู่ และ stable จะถูกปล่อยออกมาเมื่อรายการบั๊กสั้นพอ ไม่ใช่การปล่อยตามวันที่ที่กำหนด นี่คือเหตุผลที่ Debian stable ดูเก่าแต่ทำงานได้เสถียร: หมายเลขเวอร์ชันจะหยุดนิ่งที่จุด freeze ในขณะที่การแก้ไขความปลอดภัยจะถูก backport เข้าไปในเวอร์ชันเหล่านั้นอย่างต่อเนื่อง

การกำกับดูแลถูกเขียนไว้เป็นลายลักษณ์อักษรเช่นกัน โดยมีหัวหน้าโครงการที่มาจากการเลือกตั้งและมติทั่วไปที่มีผลผูกพัน ในปี 2014 กลไกดังกล่าวได้เลือก systemd เป็นระบบ init เริ่มต้น และกลุ่มคนที่เห็นต่างได้ทำการ fork ออกไปเป็น Devuan ซึ่งปล่อยรุ่นแรกในปี 2017 Debian ไม่ใช่ดิสทริบิวชันแรกที่เปลี่ยนผ่านและไม่ใช่ดิสทริบิวชันสุดท้าย เหตุผลที่การเปลี่ยนแปลงนี้เกิดขึ้นซ้ำๆ รวมถึงข้อโต้แย้งที่พิสูจน์แล้วว่าถูกต้อง สามารถติดตามได้ใน บันทึกเรื่องราวการที่ systemd เข้ามาแทนที่ SysV init ดิสทริบิวชันที่สืบทอดต่อมาที่มีขนาดใหญ่ ได้แก่ Ubuntu, Raspberry Pi OS, Proxmox VE, Kali และ Linux Mint

Red Hat, 1994: RPM และการแยกตัวเป็น Fedora และ RHEL

Marc Ewing ได้ปล่อย Red Hat Linux เวอร์ชันแรกออกมาในช่วงเทศกาลฮาโลวีนปี 1994 ต่อมาบริษัทของ Bob Young ได้เข้าซื้อกิจการในปี 1995 ทั้งสองได้ร่วมกันสร้างธุรกิจ Linux แห่งแรกที่ขายบริการสนับสนุนแทนการขายซอฟต์แวร์ Red Hat เข้าสู่ตลาดหลักทรัพย์เมื่อวันที่ 11 สิงหาคม 1999 และ IBM ได้ปิดดีลการเข้าซื้อกิจการบริษัทนี้ในเดือนกรกฎาคม 2019 ด้วยมูลค่าประมาณ 34 พันล้านดอลลาร์ ส่งผลให้ Linux distribution ที่ซอฟต์แวร์ระดับองค์กรส่วนใหญ่ใช้รับรองมาตรฐาน กลายเป็นทรัพย์สินของ IBM นับแต่นั้นเป็นต้นมา

ผลงานทางเทคนิคที่ยั่งยืนคือ RPM (Red Hat package manager) ซึ่งเขียนโดย Erik Troan และ Marc Ewing สำหรับ Red Hat Linux 2.0 ในปี 1995 ไฟล์ RPM จะประกาศ dependency ของตนเอง และถูกสร้างขึ้นจาก spec file ซึ่งเป็นสูตรการ build ที่ใครก็สามารถนำไปรันได้ คุณสมบัติประการหลังนี้เองที่ทำให้การสร้างซอฟต์แวร์ใหม่จากซอร์สโค้ดของผลิตภัณฑ์ระดับองค์กรจาก Red Hat โดยอิสระสามารถเกิดขึ้นได้จริง

Red Hat Linux 9 ในปี 2003 เป็นเวอร์ชันสุดท้ายของสายการผลิตดั้งเดิม บริษัทได้แยกผลิตภัณฑ์ออกเป็นสองส่วน ได้แก่ Fedora Core 1 ในเดือนพฤศจิกายน 2003 ในฐานะรุ่นสำหรับชุมชนที่เน้นความรวดเร็ว และ RHEL (Red Hat Enterprise Linux) ซึ่งเริ่มต้นจาก Advanced Server 2.1 ในปี 2002 ในฐานะรุ่นที่ต้องชำระเงินและเน้นความเสถียร สาเหตุนั้นชัดเจน ผลิตภัณฑ์เดียวไม่สามารถเป็นทั้งพื้นที่สำหรับทดลองเวอร์ชันใหม่และเป็นแพลตฟอร์มที่ธนาคารจะใช้งานโดยไม่เปลี่ยนแปลงใดๆ เป็นเวลาสิบปีได้ ทั้งสองส่วนนี้มีความเชื่อมโยงกัน โดย RHEL เวอร์ชันหลักจะแตกแขนงออกมาจาก Fedora release จากนั้นจะเข้าสู่กระบวนการทำให้เสถียรและทำการ freeze เวอร์ชัน เครื่องมือจัดการแพ็กเกจมีการพัฒนาตามกำหนดการเดียวกัน จาก yum ในช่วงทศวรรษ 2000 ไปสู่ dnf ซึ่งเป็นค่าเริ่มต้นของ Fedora ในปี 2015 โดยมี rpm ทำงานอยู่เบื้องหลังทั้งสองระบบ

เหตุใด CentOS จึงเลิกเป็น RHEL rebuild แบบฟรี

CentOS เริ่มต้นในปี 2004 ด้วยภารกิจง่ายๆ คือ นำซอร์สแพ็กเกจที่ Red Hat เผยแพร่มาลบเครื่องหมายการค้าออก ทำการ build ใหม่ แล้วแจกจ่ายผลลัพธ์ให้ใช้งานฟรี มันกลายเป็นดิสทริบิวชันสำหรับเซิร์ฟเวอร์ฟรีที่เป็นมาตรฐานมานานนับทศวรรษ จนกระทั่ง Red Hat ได้นำโครงการนี้เข้ามาอยู่ภายใต้การดูแลของบริษัทในปี 2014

เมื่อวันที่ 8 ธันวาคม 2020 Red Hat ประกาศว่า CentOS Linux 8 จะสิ้นสุดการสนับสนุนในวันที่ 31 ธันวาคม 2021 ซึ่งเร็วกว่ากำหนดการเดิมที่ประกาศไว้ถึง 8 ปี และชื่อ CentOS จะยังคงอยู่ต่อไปในฐานะ CentOS Stream ซึ่ง Stream ไม่ใช่การ rebuild แต่เป็น branch ที่ใช้ตัดรุ่นย่อยของ RHEL ดังนั้นมันจึงทำงานล้ำหน้ากว่า RHEL แทนที่จะตามหลัง สำหรับเครื่องที่คุณตั้งใจจะใช้งานต่อเนื่องหลายปี การทำงานล้ำหน้าถือเป็นทิศทางที่ไม่เหมาะสม เพราะคุณจะได้รับความเปลี่ยนแปลงก่อนลูกค้าที่จ่ายเงินให้กับ Red Hat

มีการ rebuild เกิดขึ้นสองโครงการในปี 2021 ได้แก่ Rocky Linux ซึ่งก่อตั้งโดย Gregory Kurtzer ผู้ร่วมก่อตั้ง CentOS และ AlmaLinux ซึ่งได้รับทุนสนับสนุนจาก CloudLinux ในเดือนมิถุนายน 2023 Red Hat ได้หยุดเผยแพร่ซอร์สโค้ดของ RHEL ในทุกช่องทางยกเว้น CentOS Stream และพอร์ทัลสำหรับลูกค้า Rocky ยังคงมุ่งเน้นการทำ rebuild ให้เหมือนต้นฉบับทุกประการ ส่วน AlmaLinux ได้เปลี่ยนเป้าหมายไปที่ความเข้ากันได้ระดับ ABI (application binary interface) ซึ่งหมายความว่าซอฟต์แวร์ที่สร้างมาเพื่อ RHEL จะสามารถทำงานได้ โดยไม่มีการรับประกันว่ารายการบั๊กจะตรงกันทุกบรรทัด ต่อมาในปีเดียวกัน Oracle, SUSE และ CIQ ได้ร่วมกันจัดตั้ง OpenELA เพื่อเผยแพร่ซอร์สโค้ดร่วมกัน ลำดับเหตุการณ์ทั้งหมดตั้งแต่การแยกตัวในปี 2003 จนถึงการเปลี่ยนแปลงแหล่งที่มาของซอร์สโค้ดในปี 2023 และสิ่งที่แต่ละโครงการ rebuild ให้คำมั่นสัญญาในปัจจุบัน ได้ถูกรวบรวมไว้ใน บันทึกฉบับเต็มของ Red Hat, CentOS, Rocky และ AlmaLinux

หากรายการอิมเมจของผู้ให้บริการรายใดรายหนึ่งยังคงระบุว่าเป็น CentOS ให้ตรวจสอบให้แน่ใจก่อนว่าหมายถึงโครงการใดก่อนที่คุณจะเริ่มใช้งาน

cat /etc/os-release

NAME="CentOS Stream" เป็น branch สำหรับการพัฒนาแบบต่อเนื่องที่นำหน้า RHEL ส่วน NAME="AlmaLinux" หรือ NAME="Rocky Linux" คือการ rebuild ที่ติดตาม RHEL โดยมีระยะเวลาสนับสนุน 10 ปี

Ubuntu 20.04: ภาพรวมของ Debian unstable บนปฏิทิน

Ubuntu 4.10 ออกเผยแพร่เมื่อวันที่ 20 ตุลาคม 2004 โดยได้รับเงินทุนสนับสนุนจาก Mark Shuttleworth ความสัมพันธ์ระหว่าง Ubuntu กับ Debian เป็นเรื่องของกลไกมากกว่าความรู้สึก ในแต่ละรอบการพัฒนาจะเริ่มต้นด้วยการนำแพ็กเกจจาก Debian unstable เข้ามาใน Ubuntu เวอร์ชันใหม่ การนำเข้าจะดำเนินไปจนถึงช่วง Debian Import Freeze ซึ่งอยู่ระหว่างรอบการพัฒนา หลังจากนั้น Ubuntu จะดำเนินการเปลี่ยนแปลงด้วยตนเอง แพ็กเกจ Ubuntu จำนวนมากคือแพ็กเกจของ Debian ที่บวกด้วยส่วนต่าง (delta) ซึ่งระบุไว้ใน changelog

อีกครึ่งหนึ่งคือเรื่องของปฏิทิน Debian จะออกเผยแพร่เมื่อพร้อม แต่ Ubuntu จะออกเผยแพร่ในเดือนเมษายนและตุลาคม โดยเลขเวอร์ชันจะอ้างอิงตามวันที่ เช่น 24.04 ออกมาในเดือนเมษายน 2024 ทุกๆ เวอร์ชันที่ออกในเดือนเมษายนของปีคู่จะเป็น LTS (long term support) ซึ่งเป็นสิ่งที่ผู้ให้บริการหมายถึงเมื่อระบุชื่อ Ubuntu โดยไม่มีคำต่อท้าย การเลือกว่าเวอร์ชันใดเหมาะสมกับเซิร์ฟเวอร์เป็นหัวข้อหลักของ การเลือกระหว่าง Ubuntu LTS และเวอร์ชัน interim และการอัปเกรดจาก LTS หนึ่งไปยังอีก LTS หนึ่งมีขั้นตอนเฉพาะ ซึ่งครอบคลุมอยู่ใน การอัปเกรดจาก 24.04 ไปยัง 26.04

มีรายละเอียดหนึ่งที่ผู้ดูแลเซิร์ฟเวอร์มักพลาดในทุกปี คือคลังซอฟต์แวร์ของ Ubuntu ถูกแบ่งออกเป็นส่วนประกอบต่างๆ main ได้รับการดูแลโดย Canonical ตลอดช่วงเวลาการสนับสนุนเต็มรูปแบบ universe ได้รับการดูแลโดยชุมชน ซึ่งมีข้อตกลงเรื่องความปลอดภัยที่แตกต่างออกไป apt install ไม่ได้ระบุข้อมูลใดๆ เกี่ยวกับความแตกต่างนี้ แต่สามารถตรวจสอบได้ด้วยคำสั่งเดียว:

apt-cache policy nginx

บรรทัดใน repository ที่ลงท้ายด้วย /main หมายความว่าทีมความปลอดภัยของ Canonical เป็นผู้ดูแลแพ็กเกจนั้น ส่วนบรรทัดที่ลงท้ายด้วย /universe หมายความว่าชุมชนเป็นผู้ดูแล ให้ตรวจสอบสิ่งนี้สำหรับซอฟต์แวร์ทุกตัวที่เชื่อมต่อกับอินเทอร์เน็ต

Arch, 2002: rolling release และต้นทุนของการอัปเกรดบางส่วน

Judd Vinet เปิดตัว Arch 0.1 เมื่อวันที่ 11 มีนาคม 2002 พร้อมกับตัวจัดการแพ็กเกจที่เขาเขียนขึ้นเองชื่อ pacman และใช้ build recipe ที่เป็นสคริปต์ shell ธรรมดา Arch ไม่มีเวอร์ชันของรุ่นที่ปล่อยออกมาเลย สื่อที่ใช้ติดตั้งเป็นเพียง snapshot ของ repository แบบ rolling ที่ระบุวันที่ไว้ ดังนั้นเครื่องที่ติดตั้งในปี 2019 และอัปเดตทุกสัปดาห์จึงรัน Arch เวอร์ชันเดียวกับเครื่องที่ติดตั้งในวันนี้ ส่วน AUR (Arch user repository) จะเก็บ build recipe ที่ผู้ใช้ร่วมกันสร้างขึ้น สิ่งเหล่านี้เป็นเพียงสูตรการสร้าง ไม่ใช่แพ็กเกจที่ผ่านการตรวจสอบแล้ว ดังนั้นการอ่านไฟล์ PKGBUILD ก่อนเริ่มใช้งานจึงเป็นส่วนหนึ่งของหน้าที่ผู้ใช้

รูปแบบ rolling release มีจุดอ่อนที่เกิดจากผู้ใช้เองเสมอ การติดตั้งแพ็กเกจเพียงตัวเดียวด้วย pacman -Sy foo จะเป็นการรีเฟรชฐานข้อมูลแพ็กเกจแล้วติดตั้ง binary ใหม่ที่เชื่อมโยงกับ library เวอร์ชันที่ใหม่กว่าที่มีอยู่ในดิสก์ ส่งผลให้โปรแกรมทำงานล้มเหลวในลักษณะนี้:

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

การดำเนินการที่รองรับคือ pacman -Syu ซึ่งเป็นการอัปเดตทุกอย่างพร้อมกัน โครงการยังมีการประกาศข่าวในกรณีที่จำเป็นต้องมีการดำเนินการด้วยตนเองก่อนการอัปเกรดบางอย่าง หากรันการอัปเกรดโดยไม่อ่านประกาศเหล่านั้น อาจทำให้เครื่องไม่สามารถบูตได้

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

Alpine: ลีนุกซ์ดิสทริบิวชันขนาดเล็กที่โด่งดังจากคอนเทนเนอร์

Alpine เริ่มต้นขึ้นเมื่อประมาณปี 2005 โดยเป็นการแตกแขนง (fork) มาจาก LEAF (Linux embedded appliance framework) ซึ่งมีรากฐานมาจาก Linux Router Project โดย Natanael Copa ได้สร้างมันขึ้นมาเพื่อใช้กับอุปกรณ์เฉพาะทาง (appliances) มากกว่าการใช้งานบนเดสก์ท็อป มันเข้ามาแทนที่ userland ส่วนใหญ่ที่คุ้นเคย โดยใช้ musl แทน GNU C library, ใช้ BusyBox แทน GNU core utilities, ใช้ OpenRC แทน systemd และใช้ apk เป็นตัวจัดการแพ็กเกจ โดย Alpine 3.0 ในปี 2014 คือรุ่นที่เปลี่ยนมาใช้ musl อย่างเต็มตัว

คอนเทนเนอร์ทำให้ Alpine ได้รับความนิยมอย่างสูง เนื่องจาก base layer ของ Alpine มีขนาดเล็กกว่า Debian หรือ Ubuntu มาก ตั้งแต่ปี 2016 เป็นต้นมา มันจึงกลายเป็น base image มาตรฐาน และมีผู้คนจำนวนมากที่แม้ไม่เคยติดตั้ง Alpine ลงบนเครื่องจริง แต่กลับใช้งานมันอยู่ทุกวันผ่านคอนเทนเนอร์

ข้อแลกเปลี่ยนคือ musl ไม่ใช่ glibc ซึ่งความแตกต่างนี้มักแสดงออกมาเป็นบั๊กที่ดูเหมือนไม่เกี่ยวข้องกัน โปรแกรมแบบ binary ที่คอมไพล์มาเพื่อ glibc จะทำงานบน Alpine ไม่ได้ พร้อมข้อความแจ้งเตือนที่ทำให้ผู้ใช้เข้าใจผิดว่าหาไฟล์ไม่พบ ทั้งที่ไฟล์นั้นมีอยู่จริง:

sh: ./myapp: not found

โปรแกรมนั้นมีอยู่จริง แต่ตัวตีความ (ELF interpreter) ของมันไม่มี เพราะตัวโหลดของ glibc ไม่ได้ถูกติดตั้งไว้ Python เป็นอีกหนึ่งสิ่งที่มักสร้างความประหลาดใจ เพราะ prebuilt wheels ที่สร้างมาสำหรับ manylinux จะไม่สามารถติดตั้งบน musl ได้ ส่งผลให้ pip พยายามคอมไพล์จาก source code แทน และหยุดทำงานหากไม่มีคอมไพเลอร์ติดตั้งอยู่ มาตรฐาน musllinux wheel ในปี 2021 ได้เข้ามาแก้ไขปัญหานี้สำหรับโปรเจกต์ที่เผยแพร่ wheel รูปแบบดังกล่าว แต่สำหรับโปรเจกต์อื่นปัญหายังคงอยู่

ในฐานะระบบปฏิบัติการสำหรับโฮสต์บน VPS นั้น Alpine มีขนาดเล็กและอัปเดตได้อย่างรวดเร็ว แต่จะทำให้คุณหลุดออกจากเส้นทางที่เอกสารส่วนใหญ่แนะนำไว้ คู่มือทุกฉบับที่ระบุให้คุณรัน systemctl enable จำเป็นต้องได้รับการปรับเปลี่ยนเป็น rc-update add แทน

ยุคสมัยแห่งความไม่เปลี่ยนแปลง: การอัปเดตแบบอะตอมและเซิร์ฟเวอร์ที่ใช้ Image เป็นฐาน

แนวทางใหม่ล่าสุดเปลี่ยนรูปแบบการอัปเดตจากการจัดการรายการแพ็กเกจ ระบบที่ใช้ ostree จะรักษา /usr ให้เป็นแบบอ่านอย่างเดียว การอัปเดตคือการสร้างโครงสร้างระบบไฟล์ใหม่ทั้งหมด ซึ่งจะถูกดาวน์โหลด เตรียมการ และสลับไปใช้งานในการรีบูตครั้งถัดไป โครงสร้างเดิมจะยังคงอยู่เป็นรายการสำหรับบูต ดังนั้นหากการอัปเดตมีปัญหา ก็สามารถย้อนกลับได้โดยการรีบูตเข้าสู่ระบบเดิม

Fedora Silverblue นำแนวทางนี้มาสู่เดสก์ท็อปในปี 2018 และ Fedora CoreOS นำมาสู่เซิร์ฟเวอร์ในปี 2019 หลังจากที่ Red Hat เข้าซื้อกิจการ CoreOS ในปี 2018 ส่วน Flatcar Container Linux ได้สานต่อ Container Linux ดั้งเดิมหลังจากที่โครงการนั้นยุติลงในปี 2020 ทางด้าน openSUSE MicroOS ก็บรรลุเป้าหมายเดียวกันผ่าน btrfs snapshots และ transactional-update ในปี 2024 Red Hat ได้เพิ่มโหมดที่ใช้ Image เป็นฐานให้กับ RHEL ซึ่งสร้างบน bootc โดยที่ระบบปฏิบัติการจะถูกจัดส่งในรูปแบบ container image และการอัปเดตเครื่องจะทำโดยการชี้ไปยัง tag ใหม่ ส่วน Talos Linux ไปไกลกว่านั้นด้วยการตัด shell และ SSH ออกไปโดยสิ้นเชิง เครื่องจะถูกกำหนดค่าผ่าน API ดังนั้นจึงไม่มีช่องทางให้ล็อกอินเข้าไปได้ สำหรับ NixOS ซึ่งเปิดตัวครั้งแรกในปี 2007 นั้นมีแนวทางที่ต่างออกไป ระบบทั้งหมดถูกสร้างขึ้นจากการกำหนดค่าแบบประกาศ (declarative configuration) เพียงชุดเดียว และเวอร์ชันก่อนหน้าจะยังคงสามารถบูตได้เสมอ

ผู้ให้บริการของคุณอาจไม่มี Image เหล่านี้ให้เลือกใช้งานแบบคลิกเดียว เพราะพวกเขาคาดหวังให้ระบบถูกกำหนดค่าตั้งแต่การบูตครั้งแรกด้วย Ignition หรือ cloud-init แทนที่จะให้ผู้ดูแลระบบแก้ไขไฟล์ผ่าน SSH ระบบเหล่านี้จะให้ผลตอบแทนที่คุ้มค่าเมื่อใช้งานกับเครื่องจำนวนมากที่เหมือนกันทุกประการ ซึ่งเป็นสถานการณ์ที่คุณจะพบเมื่อคุณ จัดการเซิร์ฟเวอร์ Linux หลายเครื่องพร้อมกัน และต้องการให้แต่ละเครื่องมีสถานะที่พิสูจน์ได้ว่าเหมือนกับเครื่องอื่นๆ ทุกประการ

ระยะเวลาการสนับสนุนของแต่ละ release คือเท่าใด

นโยบายการออก release คือส่วนของ distribution ที่คุณต้องใช้งานยาวนานที่สุด โดยจะประกาศเป็นจำนวนปี นี่คือระยะเวลาสำหรับ release ของเซิร์ฟเวอร์ปัจจุบันจำนวน 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 สนับสนุนแต่ละ branch 3.x เป็นเวลา 2 ปี ซึ่งเป็นเหตุผลว่าทำไมจึงเหมาะกับ container image ที่คุณสร้างใหม่บ่อยๆ มากกว่าโฮสต์ที่คุณปล่อยทิ้งไว้ ทีมความปลอดภัยของ Debian ดูแล stable release เป็นเวลาประมาณ 3 ปี จากนั้นทีม LTS จะดูแลสถาปัตยกรรมทั่วไปต่อจนครบประมาณ 5 ปี Ubuntu LTS ให้ระยะเวลา 5 ปีสำหรับแพ็กเกจใน main และการสมัครสมาชิก Ubuntu Pro จะขยายระยะเวลานั้นเป็น 10 ปี โดยไม่มีค่าใช้จ่ายสำหรับการใช้งานส่วนบุคคลบนเครื่องจำนวนน้อย RHEL 10 ประกาศระยะเวลา 10 ปี ซึ่งบริการเสริม extended life cycle support แบบชำระเงินจะขยายระยะเวลาออกไปเป็น 13 ปี AlmaLinux 10 มีระยะเวลาเท่ากับ RHEL ที่ 10 ปีโดยไม่ต้องสมัครสมาชิก ซึ่งเป็นเหตุผลทั้งหมดที่มีการสร้าง rebuild เหล่านี้ขึ้นมา

Arch ไม่มีแถวในตารางนี้ เนื่องจาก rolling distribution ไม่มี release ให้สนับสนุน ตัวเลขที่สำคัญสำหรับ Arch คือระยะเวลาที่คุณสามารถปล่อยเครื่องทิ้งไว้โดยไม่แตะต้อง ซึ่งวัดเป็นสัปดาห์

เหตุผลที่รายการอิมเมจ VPS ของคุณมีหน้าตาเช่นนี้

ผู้ให้บริการจะจัดเตรียมอิมเมจตามที่ลูกค้าต้องการโดยระบุชื่อ และติดตั้งแบบอัตโนมัติบนไฮเปอร์ไวเซอร์ของตน นี่คือเหตุผลที่รายการเกือบทุกแห่งจะขึ้นต้นด้วย Ubuntu LTS และ Debian รุ่นเสถียร ตามด้วย AlmaLinux หรือ Rocky สำหรับผู้ที่ใช้ซอฟต์แวร์ที่ผ่านการรับรองสำหรับ RHEL และเก็บ Alpine, Arch และ Fedora ไว้ในลำดับถัดไป เมื่อคุณทราบแล้วว่า VPS คืออะไรและอิมเมจถูกเขียนลงดิสก์อย่างไร รูปแบบนี้จะอ่านได้ชัดเจนขึ้น: ผู้ให้บริการกำลังเลือกใช้ระบบปฏิบัติการที่สามารถติดตั้งแบบอัตโนมัติได้สำเร็จและมีการสนับสนุนที่ยาวนานกว่าระยะเวลาเฉลี่ยที่ลูกค้าใช้งานเซิร์ฟเวอร์นั้น

การเลือกนี้ไม่ได้ผูกมัดคุณไว้แค่ตัวจัดการแพ็กเกจเท่านั้น แต่ยังกำหนดวิธีการอัปเกรดที่คุณจะต้องทำในอีก 3 ปีข้างหน้า ซึ่งแต่ละตระกูลจะมีวิธีการที่แตกต่างกันโดยสิ้นเชิง Debian และ Ubuntu รองรับการอัปเกรดเวอร์ชันหลักแบบ in-place ตระกูล Red Hat จะดำเนินการผ่าน leapp ส่วน Arch ไม่มีการอัปเกรดเวอร์ชันเพราะไม่มีการแบ่งเวอร์ชัน สำหรับ Alpine คือการแก้ไขไฟล์ /etc/apk/repositories แล้วรัน apk upgrade --available นอกจากนี้ การเลือกดังกล่าวยังกำหนดว่าซอฟต์แวร์ใดที่คุณสามารถติดตั้งได้โดยไม่ต้องเพิ่ม repository ของบุคคลที่สาม ใครจะเป็นผู้จัดส่งแพตช์เมื่อมีรายการ CVE (ช่องโหว่และความเสี่ยงทั่วไป) เกิดขึ้นกับซอฟต์แวร์ที่คุณใช้งาน รวมถึงกำหนดว่าระบบ init และ C library ใดที่ซอฟต์แวร์ในอนาคตของคุณจะคาดหวังให้มีอยู่

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

FAQ

ตระกูล Linux distribution ของเซิร์ฟเวอร์ฉันคืออะไร?

ให้รันคำสั่ง cat /etc/os-release โดยฟิลด์ ID จะระบุชื่อ distribution และ ID_LIKE จะระบุตระกูลของมัน เช่น เครื่อง Ubuntu จะแสดงค่า ID_LIKE=debian และเครื่อง AlmaLinux จะแสดงค่า ID_LIKE="rhel centos fedora" นอกจากนี้ยังสามารถดูได้จาก package manager โดย apt และ dpkg หมายถึงตระกูล Debian ส่วน dnf และ rpm หมายถึงตระกูล Red Hat ในขณะที่ apk หมายถึง Alpine และ pacman หมายถึง Arch

CentOS ยังคงเป็นเวอร์ชันฟรีของ RHEL อยู่หรือไม่?

ไม่แล้ว CentOS Linux 8 ซึ่งเป็นรุ่น rebuild สุดท้ายในชื่อนี้ได้สิ้นสุดลงเมื่อวันที่ 31 ธันวาคม 2021 และ CentOS Linux 7 ได้สิ้นสุดการสนับสนุนเมื่อวันที่ 30 มิถุนายน 2024 โครงการที่ยังคงอยู่คือ CentOS Stream ซึ่งเป็นสาขาที่ใช้สร้าง RHEL เวอร์ชันย่อย ดังนั้นการเปลี่ยนแปลงจะเกิดขึ้นใน CentOS Stream ก่อน RHEL สำหรับโครงการที่เข้ามาทำหน้าที่แทนในรูปแบบ rebuild ฟรีคือ AlmaLinux และ Rocky Linux ซึ่งทั้งคู่มีการสนับสนุนนาน 10 ปี

ทำไม Debian stable ถึงใช้เลขเวอร์ชันที่เก่ามาก?

เพราะเลขเวอร์ชันจะถูกแช่แข็งไว้ในขณะที่การแก้ไขยังคงดำเนินต่อไป Debian จะใช้วิธี backport แพตช์ความปลอดภัยเข้ามาในเวอร์ชันที่ปล่อยออกมา แทนที่จะอัปเดตเป็นเวอร์ชันใหม่จากต้นทาง ดังนั้นแพ็กเกจที่แสดงเลข 2.4.57-2+deb13u1 อาจมีการรวมแพตช์ที่เพิ่งปล่อยออกมาเมื่อสัปดาห์ที่แล้วไว้ด้วย ส่วนตัวเลขต่อท้ายเวอร์ชันต้นทางคือ Debian revision และ apt changelog <package> จะแสดงรายละเอียดการเปลี่ยนแปลงที่รวมอยู่ในนั้น การตัดสินความปลอดภัยของเซิร์ฟเวอร์ Debian ด้วยเลขเวอร์ชันเพียงอย่างเดียวจึงมักให้ผลลัพธ์ที่ผิดพลาดเสมอ

ฉันควรใช้ rolling release อย่าง Arch บน VPS หรือไม่?

ควรใช้ก็ต่อเมื่อคุณมีกำหนดการอัปเดตที่ชัดเจนเท่านั้น เพราะ rolling distribution ถูกออกแบบมาให้ทุกเครื่องต้องอัปเดตตามแพ็กเกจปัจจุบันเสมอ ดังนั้นการอัปเดตเพียงแพ็กเกจเดียวด้วย pacman -Sy foo อาจทำให้ library ไม่ตรงกันและเกิดข้อผิดพลาดเช่น cannot open shared object file ได้ หากคุณรัน pacman -Syu อย่างสม่ำเสมอและอ่านหน้าข่าวสารของโครงการก่อนอัปเดตทุกครั้ง ระบบก็จะมีความเสถียร แต่หากปล่อยทิ้งไว้เป็นปี การอัปเดตครั้งแรกจะกลายเป็นความเสี่ยงทันที

distribution แบบ immutable หรือ atomic มีการเปลี่ยนแปลงอย่างไร?

มันเปลี่ยนวิธีการนำอัปเดตไปใช้และวิธีการย้อนกลับ (undo) โดยที่ /usr จะถูก mount แบบอ่านได้อย่างเดียว (read-only) การอัปเดตจะถูกเตรียมไว้เป็นโครงสร้างไฟล์ชุดใหม่ทั้งหมด และจะสลับใช้งานเมื่อรีบูตเครื่อง โดยที่โครงสร้างเดิมจะถูกเก็บไว้เป็น boot entry เพื่อให้สามารถย้อนกลับได้ คุณจะได้เครื่องที่อัปเดตสมบูรณ์หรือไม่ได้อัปเดตเลย โดยไม่มีสถานะที่อัปเดตเพียงบางส่วน คุณจะต้องแลกกับการไม่สามารถติดตั้งซอฟต์แวร์ด้วยการแก้ไขไฟล์ในระบบโดยตรง ดังนั้นแอปพลิเคชันต่างๆ จึงต้องย้ายไปอยู่ในคอนเทนเนอร์หรือติดตั้งผ่าน layered packages แทน