ประวัติความเป็นมาของ Linux distribution และความสัมพันธ์

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

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

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

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

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

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

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

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

1992: การแจกจ่ายก่อนที่จะมีตระกูล Linux

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

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

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

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

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

ตระกูลนี้มีขนาดเล็ก รุ่นแรกๆ ของ 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 เริ่มต้น และกลุ่มคนที่เห็นต่างได้แยกตัวออกไปสร้าง Devuan ซึ่งออกรุ่นแรกในปี 2017 ดิสทริบิวชันขนาดใหญ่ที่สืบทอดมาจาก Debian ได้แก่ 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 พันล้านดอลลาร์ ส่งผลให้ดิสทริบิวชันที่ซอฟต์แวร์ระดับองค์กรส่วนใหญ่ใช้รับรองมาตรฐานนั้นตกเป็นทรัพย์สินของ 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 แต่เป็นสาขาที่ใช้ตัดรุ่นย่อยของ RHEL ดังนั้นมันจึงทำงานล้ำหน้ากว่า RHEL แทนที่จะตามหลัง สำหรับเครื่องที่คุณตั้งใจจะใช้งานต่อเนื่องหลายปี การล้ำหน้าถือเป็นทิศทางที่ไม่เหมาะสม เพราะคุณจะได้รับความเปลี่ยนแปลงก่อนลูกค้าที่จ่ายเงินให้ Red Hat

มีการ rebuild เกิดขึ้นใหม่ 2 โครงการในปี 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 เพื่อเผยแพร่ซอร์สโค้ดร่วมกัน

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

cat /etc/os-release

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

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

Ubuntu 4.10 เปิดตัวเมื่อวันที่ 20 ตุลาคม 2004 โดยได้รับทุนสนับสนุนจาก Mark Shuttleworth ความสัมพันธ์ระหว่าง Ubuntu และ Debian เป็นเรื่องของกลไกมากกว่าความรู้สึก ในแต่ละรอบการพัฒนา Ubuntu จะเริ่มต้นด้วยการนำแพ็กเกจจาก 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 รุ่นหนึ่งไปยังรุ่นถัดไปมีขั้นตอนเฉพาะ ซึ่งครอบคลุมอยู่ใน การอัปเกรดจาก 24.04 ไปยัง 26.04

มีรายละเอียดหนึ่งที่ผู้ดูแลเซิร์ฟเวอร์มักมองข้ามในทุกปี คือคลังซอฟต์แวร์ (archive) ของ 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 ที่เป็น shell script ธรรมดา Arch ไม่มีเวอร์ชันของรุ่นที่ปล่อยออกมาเลย สื่อที่ใช้ติดตั้งเป็นเพียงภาพรวมของ repository แบบ rolling ที่ระบุวันที่ไว้ ดังนั้นเครื่องที่ติดตั้งในปี 2019 และอัปเดตทุกสัปดาห์จึงรัน Arch เวอร์ชันเดียวกับเครื่องที่ติดตั้งในวันนี้ ส่วน AUR (Arch user repository) เก็บสูตรการ build ที่ผู้ใช้ร่วมกันสร้างขึ้น สิ่งเหล่านี้เป็นเพียงสูตร ไม่ใช่แพ็กเกจที่ผ่านการตรวจสอบ ดังนั้นการอ่านไฟล์ PKGBUILD ก่อนสั่งรันจึงเป็นหน้าที่ของผู้ใช้

การอัปเดตแบบ rolling มีจุดที่ทำให้ระบบล้มเหลวได้หนึ่งจุด ซึ่งมักเกิดจากตัวผู้ใช้เอง การติดตั้งแพ็กเกจเพียงตัวเดียวด้วย 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 ได้สร้างมันขึ้นมาเพื่อใช้งานกับอุปกรณ์เฉพาะทางมากกว่าการใช้งานบนเดสก์ท็อป Alpine เข้ามาแทนที่ซอฟต์แวร์พื้นฐานส่วนใหญ่ที่คุ้นเคย โดยใช้ musl แทน GNU C library, ใช้ BusyBox แทน GNU core utilities, ใช้ OpenRC แทน systemd และใช้ apk เป็นตัวจัดการแพ็กเกจ ทั้งนี้ Alpine 3.0 ในปี 2014 คือเวอร์ชันที่เปลี่ยนไปใช้ musl อย่างเต็มตัว

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

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

sh: ./myapp: not found

โปรแกรมนั้นมีอยู่จริง แต่ตัวตีความ ELF (ELF interpreter) ของมันไม่มีอยู่ เนื่องจากตัวโหลดของ glibc ไม่ได้ถูกติดตั้งไว้ อีกประเด็นที่มักสร้างความประหลาดใจคือ Python โดย prebuilt wheels ที่สร้างมาสำหรับ manylinux จะไม่สามารถติดตั้งบน musl ได้ ส่งผลให้ pip พยายามคอมไพล์จากซอร์สโค้ดและหยุดทำงานหากไม่มีคอมไพเลอร์ติดตั้งไว้ มาตรฐาน 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 ที่คุณต้องใช้งานยาวนานที่สุด โดยจะประกาศเป็นจำนวนปี นี่คือระยะเวลาสำหรับ 5 release ของเซิร์ฟเวอร์ในปัจจุบัน

[
  {
    "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 image ของคุณมีหน้าตาเช่นนี้

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

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

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

FAQ

เซิร์ฟเวอร์ของฉันอยู่ในตระกูล Linux distribution ใด

ให้รันคำสั่ง cat /etc/os-release โดยฟิลด์ ID จะระบุชื่อ distribution และ ID_LIKE จะระบุตระกูลของมัน เช่น เครื่อง Ubuntu จะแสดงค่า ID_LIKE=debian และเครื่อง AlmaLinux จะแสดงค่า ID_LIKE="rhel centos fedora" นอกจากนี้ตัวจัดการแพ็กเกจยังเป็นอีกหนึ่งจุดสังเกต โดย 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 นั้นเป็น branch ที่ใช้สร้าง RHEL minor release ดังนั้นการเปลี่ยนแปลงต่างๆ จะเกิดขึ้นใน CentOS Stream ก่อนที่จะถึง RHEL สำหรับโครงการ rebuild ฟรีที่มารับหน้าที่แทนคือ AlmaLinux และ Rocky Linux ซึ่งทั้งคู่มีการสนับสนุนนาน 10 ปี

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

เพราะเลขเวอร์ชันจะถูกแช่แข็งไว้ในขณะที่การแก้ไขข้อผิดพลาดยังคงดำเนินต่อไป Debian จะใช้วิธี backport แพตช์ความปลอดภัยเข้ามาในเวอร์ชันที่ปล่อยออกมา แทนที่จะอัปเดตเป็นเวอร์ชันใหม่จากต้นทาง ดังนั้นแพ็กเกจที่แสดงเลขเวอร์ชันเป็น 2.4.57-2+deb13u1 อาจมีการแก้ไขที่เพิ่งปล่อยออกมาเมื่อสัปดาห์ที่แล้วรวมอยู่ด้วย ส่วน suffix ที่ต่อท้ายเวอร์ชันต้นทางคือเลข revision ของ Debian และ 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 เพื่อให้สามารถย้อนกลับได้ คุณจะได้เครื่องที่อัปเดตเสร็จสมบูรณ์หรือยังไม่ได้อัปเดตเลย โดยไม่มีสถานะที่อัปเดตเพียงบางส่วน คุณจะต้องแลกกับการไม่สามารถติดตั้งซอฟต์แวร์ด้วยการแก้ไขไฟล์ในระบบโดยตรง ดังนั้นแอปพลิเคชันต่างๆ จึงต้องย้ายไปอยู่ใน container หรือติดตั้งผ่านการทำ layered packages แทน