Lịch sử Linux distribution: Slackware, Debian và Red Hat

Linux distribution thực sự là gì

Lịch sử của các Linux distribution bắt đầu từ một khoảng trống: bản thân Linux kernel không làm được điều gì hữu ích cho người dùng. Nó khởi động và nhận diện phần cứng. Sau đó nó dừng lại. Cần có người bổ sung userland, chọn cách cài đặt và cập nhật software, đồng thời cam kết tiếp tục sửa lỗi trong nhiều năm. Distribution là tập hợp những lựa chọn đó, cùng với nhóm người tiếp tục duy trì nó về sau.

Một distribution có 5 thành phần:

• Kernel ở version do project lựa chọn, cùng các patch và driver mà project bổ sung.
• Userland: C library, shell, init system và các command tiêu chuẩn.
• Định dạng package và tool dùng để cài đặt package đó.
• Chính sách release: những gì được phép thay đổi, tần suất thay đổi và mỗi release được sửa lỗi trong bao lâu.
• Con người: package maintainer, security team và người trả lời khi một package bị lỗi.

Kernel là phần dùng chung. Vì vậy, hai Linux distribution gần nhau hơn nhiều so với bất kỳ distribution nào so với một Unix khác. Cần ghi nhớ điều này khi so sánh Linux và FreeBSD dưới vai trò nền tảng server, trong đó kernel và userland cơ sở do một project xây dựng và release cùng nhau. Trên Linux, các phần đó đến từ những upstream riêng biệt, còn distribution là thành phần khiến chúng hoạt động thống nhất.

Lịch sử các bản phân phối Linux qua ba họ

Ba dự án bắt đầu vào năm 1993 và 1994 đã phát triển thành ba họ: Slackware, Debian và Red Hat. Gần như mọi image trong control panel của VPS hiện nay đều thuộc một trong ba họ này hoặc là hậu duệ của chúng. Hậu duệ kế thừa format của package, bố cục filesystem và thường cả cách phát hành. Vì vậy, một bản phân phối dựa trên Debian vẫn cho cảm giác như Debian ngay cả khi đã bỏ branding.

Các bản phân phối độc lập cần được nói riêng vì chúng không fork từ dự án nào. Arch, Gentoo, Alpine, NixOS và Void đều tự xây dựng package manager và bộ quy tắc riêng. Trong số đó, Arch và Alpine cuối cùng vẫn xuất hiện trong danh sách image của nhà cung cấp, vì những lý do không liên quan đến desktop.

1992: các bản phân phối trước khi hình thành các họ

MCC Interim Linux xuất hiện vào tháng 2 năm 1992, do Owen Le Blanc xây dựng tại Manchester Computing Centre. Bản này đưa kernel và các công cụ GNU (GNU's not Unix) vào 2 image floppy, kèm một trình cài đặt điều khiển bằng menu. Nó tồn tại vì thực hiện việc đó thủ công sẽ mất cả ngày làm việc.

SLS (Softlanding Linux System), do Peter MacDonald phát hành năm 1992, tiến thêm một bước khi bổ sung X (X Window System) và networking TCP/IP. SLS là lý do từ distribution có ý nghĩa như hiện nay. Tuy nhiên, SLS có nhiều lỗi và được bảo trì chậm. Năm 1993, 2 người đã độc lập quyết định sửa vấn đề đó. Một người xây dựng lại nó. Người kia bắt đầu lại từ đầu với các quy tắc được viết rõ ràng.

Slackware, 1993: dòng họ lâu đời nhất vẫn còn phát hành

Patrick Volkerding phát hành Slackware 1.00 vào ngày 16 tháng 7 năm 1993, được xây dựng từ SLS sau khi loại bỏ các bug. Slackware vẫn được duy trì, nên đây là Linux distribution lâu đời nhất còn tồn tại.

Một package của Slackware là tar archive được nén, bên trong có install script. Slackware không có cơ chế giải quyết dependency: không có thành phần nào kiểm tra library mà package mới cần đã có trên disk hay chưa. Quyết định duy nhất đó đã định hình mọi thứ khác. Nếu tool không tự giải quyết dependency, tập package được phát hành phải nhất quán ngay từ đầu, nên các release thường hiếm và thận trọng. Slackware 15.0 ra mắt vào tháng 2 năm 2022, 6 năm sau 14.2.

Dòng họ này khá nhỏ. Các release đầu tiên của SUSE vào giữa thập niên 1990 được xây dựng trên Slackware, trước khi project đi theo hướng riêng với YaST và sau đó là RPM package format. Phần cuối này thường gây nhầm lẫn. SUSE và openSUSE sử dụng RPM package, nhưng không phải là các bản phân nhánh của Red Hat. Package format đã được sử dụng rộng hơn. Dòng phát triển thì không.

Debian, 1993: social contract và quy trình ba suite

Ian Murdock công bố Debian vào ngày 16 August 1993, ba tuần sau Slackware và cũng vì lý do đó. Tên này ghép tên người bạn đời Debra của ông với tên của chính ông. Debian Manifesto được công bố vào January 1994 và đặt ra các điều khoản: distribution này sẽ do các tình nguyện viên duy trì công khai, không phải một công ty.

Sau đó Debian ghi lại các điều khoản này. Debian Social Contract và DFSG (Debian free software guidelines) được thông qua vào July 1997, và DFSG trở thành cơ sở của Open Source Definition vào 1998. Một tài liệu được viết để xác định những gì thuộc về một distribution cuối cùng lại định nghĩa một nhóm licence cho toàn ngành. Đây cũng là lý do sources.list của bạn có các component: main chứa phần mềm đáp ứng các guideline, contrib và non-free chứa phần mềm không đáp ứng, còn Debian 12 bổ sung non-free-firmware để laptop có wireless card có thể cài đặt mà không phải tự tìm từng gói.

Bộ công cụ là phần kế thừa khác. dpkg cài đặt một package và dừng khi thiếu dependency, đồng thời in ra dpkg: dependency problems prevent configuration of. APT (advanced package tool), trở thành mặc định từ Debian 2.1 vào 1999, là lớp xác định cần fetch thêm gì và theo thứ tự nào. Mọi lệnh apt trên mọi Debian derivative đều bắt nguồn từ công việc này.

Quy trình release có ba suite và một quy tắc. Maintainer upload package lên unstable, có codename cố định là sid. Một script migrate package sang testing sau khoảng 5 đến 10 ngày, nếu package build được trên các release architecture và không phát sinh release-critical bug mới. Sau đó testing được freeze, release team xử lý những vấn đề còn lại, rồi stable được phát hành khi danh sách bug đủ ngắn. Không theo một ngày cố định. Vì vậy Debian stable có vẻ cũ nhưng hoạt động ổn định: version number dừng ở thời điểm freeze, còn security fix vẫn được backport vào các version đó.

Cơ chế quản trị cũng được ghi thành văn bản, với project leader do bầu cử và các general resolution có tính ràng buộc. Năm 2014, cơ chế này chọn systemd làm init system mặc định, còn những người không đồng ý đã fork thành Devuan, phát hành bản release đầu tiên vào 2017. Debian không phải distribution đầu tiên chuyển sang systemd và cũng không phải distribution cuối cùng; các lý do khiến việc này tiếp tục xảy ra, cùng những phản đối sau đó được chứng minh là đúng, được trình bày trong bài viết về cách systemd thay thế SysV init. Các hậu duệ lớn hơn gồm Ubuntu, Raspberry Pi OS, Proxmox VE, Kali và Linux Mint.

Red Hat, 1994: RPM, sau đó tách thành Fedora và RHEL

Marc Ewing phát hành bản Red Hat Linux đầu tiên vào khoảng Halloween năm 1994. Công ty của Bob Young mua lại sản phẩm này vào năm 1995, rồi hai người xây dựng doanh nghiệp Linux đầu tiên bán dịch vụ hỗ trợ thay vì phần mềm. Red Hat phát hành cổ phiếu lần đầu ra công chúng vào ngày 11 August 1999. IBM hoàn tất việc mua lại công ty vào July 2019 với giá khoảng 34 billion dollars. Vì vậy, bản phân phối mà phần lớn phần mềm doanh nghiệp chứng nhận tương thích đã thuộc sở hữu của IBM từ đó.

Đóng góp kỹ thuật có ảnh hưởng lâu dài là RPM (Red Hat package manager), do Erik Troan và Marc Ewing viết cho Red Hat Linux 2.0 vào năm 1995. Một RPM khai báo các dependency của nó và được tạo từ một spec file, tức recipe build mà bất kỳ ai cũng có thể chạy. Chính đặc tính thứ hai đã khiến việc rebuild độc lập sản phẩm doanh nghiệp của Red Hat về sau trở nên khả thi.

Red Hat Linux 9 vào năm 2003 là phiên bản cuối của dòng ban đầu. Công ty chia dòng này thành hai: Fedora Core 1 vào November 2003, là bản phát hành cộng đồng có tốc độ thay đổi nhanh; và RHEL (Red Hat Enterprise Linux), vốn bắt đầu với Advanced Server 2.1 vào năm 2002, là bản phát hành trả phí có tốc độ thay đổi chậm. Nguyên nhân rất rõ ràng. Một sản phẩm không thể vừa là nơi thử nghiệm các phiên bản mới, vừa là nền tảng mà một ngân hàng vận hành ổn định trong mười năm. Hai nhánh này vẫn liên kết với nhau: một major version của RHEL được tách từ một bản phát hành Fedora, sau đó được ổn định hóa và đóng băng. Công cụ quản lý package cũng chuyển đổi theo cùng lịch trình, từ yum trong những năm 2000 sang dnf làm mặc định của Fedora vào năm 2015, với rpm nằm bên dưới cả hai.

Vì sao CentOS không còn là bản rebuild RHEL miễn phí

CentOS bắt đầu vào năm 2004 với một mục tiêu đơn giản: lấy các source package do Red Hat phát hành, gỡ trademark, rebuild chúng rồi cung cấp miễn phí. CentOS trở thành distribution server miễn phí mặc định trong một thập kỷ, và Red Hat đưa dự án này về quản lý nội bộ vào năm 2014.

Ngày 8 tháng 12 năm 2020, Red Hat thông báo CentOS Linux 8 sẽ kết thúc vào ngày 31 tháng 12 năm 2021, sớm hơn 8 năm so với thời điểm đã công bố, đồng thời tên CentOS sẽ tiếp tục tồn tại dưới dạng CentOS Stream. Stream không phải là một bản rebuild. Đây là branch dùng để tạo các bản minor release của RHEL, nên nó chạy trước RHEL thay vì theo sau RHEL. Với một máy bạn dự định duy trì trong nhiều năm, chạy trước là hướng không phù hợp, vì bạn sẽ nhận được các thay đổi trước khách hàng trả phí của Red Hat.

Hai bản rebuild xuất hiện trong năm 2021. Rocky Linux do Gregory Kurtzer, đồng sáng lập CentOS, khởi xướng. AlmaLinux được CloudLinux tài trợ. Tháng 6 năm 2023, Red Hat ngừng công bố source của RHEL ở mọi nơi, ngoại trừ CentOS Stream và customer portal. Rocky vẫn hướng đến các bản rebuild giống hệt. AlmaLinux đổi mục tiêu sang khả năng tương thích ABI (application binary interface), nghĩa là phần mềm được build cho RHEL có thể chạy được, nhưng không cam kết danh sách bug khớp từng dòng. Oracle, SUSE và CIQ thành lập OpenELA vào cuối năm đó để công bố source dùng chung. Toàn bộ diễn biến này, từ lần tách năm 2003 đến thay đổi source năm 2023 và cam kết hiện tại của từng bản rebuild, được trình bày trong bài viết chi tiết hơn về Red Hat, CentOS, Rocky và AlmaLinux.

Nếu danh sách image của provider vẫn ghi CentOS, hãy xác định đó là phiên bản nào trước khi build trên image đó.

cat /etc/os-release

NAME="CentOS Stream" là branch phát triển rolling dẫn đến RHEL. NAME="AlmaLinux" hoặc NAME="Rocky Linux" là bản rebuild đi theo branch này, với thời hạn 10 năm.

Ubuntu, 2004: ảnh chụp Debian unstable theo lịch phát hành

Ubuntu 4.10 được phát hành vào ngày 20 tháng 10 năm 2004, với nguồn tài trợ từ Mark Shuttleworth. Mối quan hệ giữa Ubuntu và Debian mang tính cơ học hơn là tình cảm. Mỗi chu kỳ bắt đầu bằng việc import các package từ Debian unstable vào bản Ubuntu mới. Việc import tiếp tục cho đến Debian Import Freeze ở giữa chu kỳ. Sau đó, Ubuntu tự duy trì các thay đổi của mình. Nhiều package Ubuntu là package Debian cộng với một delta, và changelog cho biết delta đó là gì.

Nửa còn lại là lịch phát hành. Debian phát hành khi đã sẵn sàng. Ubuntu phát hành vào tháng 4 và tháng 10, còn số phiên bản là ngày phát hành: 24.04 được phát hành vào tháng 4 năm 2024. Cứ mỗi bản phát hành tháng 4 thứ hai lại là một LTS (long term support), tức loại phiên bản mà provider muốn nói đến khi liệt kê Ubuntu mà không ghi thêm điều kiện nào. Bản nào trong hai loại phù hợp cho server là nội dung chính của việc chọn giữa Ubuntu LTS và các bản interim, còn việc nâng cấp từ LTS này lên LTS tiếp theo có quy trình riêng, được trình bày trong quy trình nâng cấp từ 24.04 lên 26.04.

Có một chi tiết khiến server admin phải chú ý mỗi năm. Archive của Ubuntu được chia thành các component. main do Canonical duy trì trong toàn bộ thời gian support. universe do cộng đồng duy trì, và mức security coverage của component này là một cam kết khác. apt install không hiển thị gì về sự khác biệt đó. Một command có thể cho biết:

apt-cache policy nginx

Dòng repository kết thúc bằng /main nghĩa là team security của Canonical chịu trách nhiệm cho package đó. Dòng kết thúc bằng /universe nghĩa là cộng đồng chịu trách nhiệm. Hãy kiểm tra điều này với mọi package có thể truy cập từ Internet.

Arch, 2002: rolling release và cái giá của partial upgrade

Judd Vinet phát hành Arch 0.1 vào ngày 11 March 2002, cùng một package manager do ông tự viết là pacman và các build recipe chỉ là shell script thuần. Arch hoàn toàn không có các bản release theo version. Bộ cài là snapshot có ngày tháng của cùng các rolling repository, vì vậy một máy được cài vào năm 2019 và cập nhật hằng tuần đang chạy cùng một Arch với máy vừa được cài hôm nay. AUR (Arch user repository) chứa các build recipe do người dùng đóng góp. Đây là recipe, không phải package đã được review, nên đọc PKGBUILD trước khi chạy là một phần của công việc.

Rolling release có một kiểu lỗi, và lần nào cũng do chính người quản trị gây ra. Cài một package riêng lẻ bằng pacman -Sy foo sẽ refresh package database, sau đó cài một binary mới được link với các library mới hơn những library đang có trên disk. Chương trình sẽ fail như sau:

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

Operation được hỗ trợ là pacman -Syu, dùng để cập nhật mọi thứ cùng lúc. Project cũng đăng các news entry cho biết khi nào cần can thiệp thủ công trước một số lần upgrade. Chạy upgrade mà không đọc các entry này có thể khiến máy không boot được.

Vì vậy, Arch không phù hợp với server mà bạn dự định bỏ mặc. Một máy được cập nhật hằng tuần thì không vấn đề gì. Một máy chỉ được cập nhật một lần rồi để đó thêm một năm sẽ buộc bạn xử lý toàn bộ các can thiệp bị bỏ qua trong một lần chạy.

Alpine: bản phân phối nhỏ nổi tiếng nhờ container

Alpine bắt đầu vào khoảng năm 2005 dưới dạng fork của LEAF (Linux embedded appliance framework), vốn phát triển từ Linux Router Project. Natanael Copa xây dựng Alpine cho các appliance thay vì cho desktop. Alpine thay thế hầu hết userland thường dùng: musl thay cho GNU C library, BusyBox thay cho GNU core utilities, OpenRC thay cho systemd và apk thay cho package manager.

Container khiến Alpine trở nên phổ biến. Base layer Alpine chỉ có kích thước bằng một phần nhỏ so với base của Debian hoặc Ubuntu. Vì vậy, từ năm 2016, Alpine trở thành một base image phổ biến. Nhiều người chưa từng cài Alpine vẫn chạy nó hằng ngày.

Đổi lại, musl không phải glibc và khác biệt này gây ra những lỗi trông như không liên quan. Binary được link với glibc sẽ fail trên Alpine bằng một thông báo khiến người dùng đi tìm một file vốn đã tồn tại:

sh: ./myapp: not found

Chương trình có tồn tại. ELF interpreter của nó thì không, vì loader của glibc không có trên hệ thống. Python là một bất ngờ thường gặp khác: các wheel dựng cho manylinux sẽ không cài được trên musl. Vì vậy, pip chuyển sang compile từ source rồi dừng lại khi không có compiler. Chuẩn musllinux wheel từ năm 2021 đã giải quyết vấn đề này cho các project có publish những wheel đó, và không giải quyết cho project nào khác.

Làm hệ điều hành trên VPS, Alpine cài đặt nhanh vì nhỏ và update nhanh. Tuy nhiên, Alpine đưa bạn ra ngoài hướng mà phần lớn tài liệu mặc định. Mọi hướng dẫn yêu cầu chạy systemctl enable đều cần được chuyển thành rc-update add.

Thế hệ immutable: cập nhật atomic và server dựa trên image

Nhánh mới nhất thay đổi mô hình cập nhật thay vì thay đổi danh sách package. Hệ thống dựa trên ostree giữ /usr ở chế độ chỉ đọc. Mỗi bản cập nhật là một cây filesystem hoàn chỉnh được download, staging và chuyển sang sử dụng ở lần reboot tiếp theo. Cây trước đó vẫn được giữ lại dưới dạng boot entry, vì vậy có thể hoàn tác một bản cập nhật lỗi bằng cách reboot vào cây cũ.

Fedora Silverblue đưa mô hình này lên desktop vào năm 2018, còn Fedora CoreOS đưa nó lên server vào năm 2019, sau khi Red Hat mua CoreOS vào năm 2018. Flatcar Container Linux tiếp tục dự án Container Linux ban đầu sau khi dự án đó bị ngừng vào năm 2020. openSUSE MicroOS đạt được kết quả tương tự thông qua snapshot của btrfs và transactional-update. Năm 2024, Red Hat bổ sung chế độ dựa trên image cho RHEL, được xây dựng trên bootc. Ở chế độ này, operating system được cung cấp dưới dạng container image và máy được cập nhật bằng cách trỏ nó tới một tag mới. Talos Linux đi xa hơn bằng cách loại bỏ hoàn toàn shell và SSH: máy được cấu hình thông qua API, nên không có gì để đăng nhập. NixOS, được phát hành lần đầu vào năm 2007, đi theo hướng khác. Toàn bộ hệ thống được build từ một cấu hình khai báo duy nhất, còn các generation trước đó vẫn có thể boot.

Provider của bạn có thể không cung cấp bất kỳ hệ thống nào trong số này dưới dạng image một click, vì chúng được thiết kế để cấu hình ở lần boot đầu tiên bằng Ignition hoặc cloud-init, thay vì để administrator chỉnh sửa file qua SSH. Các hệ thống này phát huy hiệu quả khi triển khai trên nhiều máy giống hệt nhau. Đó chính là tình huống bạn gặp phải khi quản lý nhiều Linux server cùng lúc và cần chứng minh rằng mỗi máy giống hệt các máy còn lại.

Một bản release được hỗ trợ trong bao lâu?

Chính sách release là phần của một distribution mà bạn sẽ phải sử dụng trong thời gian dài nhất, và chính sách này được công bố theo số năm. Dưới đây là thời hạn hỗ trợ của 5 bản release server hiện tại.

[
  {
    "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 hỗ trợ mỗi nhánh 3.x trong 2 năm. Vì vậy, Alpine phù hợp với container image được build lại thường xuyên hơn là host bạn để nguyên trong thời gian dài. Đội ngũ bảo mật Debian hỗ trợ một bản stable trong khoảng 3 năm. Sau đó, đội ngũ LTS tiếp tục hỗ trợ các kiến trúc phổ biến đến khoảng 5 năm tổng cộng. Ubuntu LTS hỗ trợ các package trong main trong 5 năm. Gói thuê bao Ubuntu Pro mở rộng thời hạn này lên 10 năm và miễn phí cho mục đích cá nhân trên một số lượng nhỏ máy. RHEL 10 công bố thời hạn 10 năm. Gói hỗ trợ vòng đời mở rộng có trả phí kéo dài thời hạn này lên 13 năm. AlmaLinux 10 có thời hạn giống RHEL là 10 năm mà không cần subscription. Đây chính là lý do các bản rebuild tồn tại.

Arch không có dòng trong bảng này, vì rolling distribution không có release cần hỗ trợ. Con số quan trọng đối với Arch là bạn có thể để một máy không được cập nhật trong bao lâu. Thời gian này được tính theo tuần.

Vì sao danh sách image VPS của bạn lại như vậy

Nhà cung cấp phát hành các image mà khách hàng thường yêu cầu theo tên và có thể cài đặt tự động trên hypervisor của họ. Vì vậy, gần như mọi danh sách đều bắt đầu bằng Ubuntu LTS và Debian stable, thêm AlmaLinux hoặc Rocky cho những người có phần mềm được chứng nhận chạy trên RHEL, rồi đặt Alpine, Arch và Fedora ở phía dưới. Khi biết VPS là gì và image được ghi vào disk như thế nào, bạn sẽ thấy rõ quy luật này: nhà cung cấp chọn các hệ điều hành có thể hoàn tất quá trình cài đặt tự động và được hỗ trợ lâu hơn thời gian trung bình khách hàng sử dụng server.

Lựa chọn này ràng buộc bạn với nhiều thứ hơn một package manager. Nó quyết định cách bạn sẽ thực hiện upgrade trong ba năm nữa, và cách đó khác hoàn toàn giữa các họ hệ điều hành. Debian và Ubuntu hỗ trợ major upgrade tại chỗ. Họ Red Hat thực hiện việc này thông qua leapp. Arch không có upgrade vì không có version. Alpine thực hiện bằng cách chỉnh sửa /etc/apk/repositories rồi chạy apk upgrade --available. Lựa chọn này cũng quyết định phần mềm nào bạn có thể cài mà không cần thêm repository bên thứ ba, ai phát hành bản vá khi một mục CVE (common vulnerabilities and exposures) xuất hiện trong thành phần bạn đang chạy, cũng như phần mềm của bạn sau này sẽ giả định có init system và C library nào.

Còn một ảnh hưởng khác thường bị đánh giá thấp. Phần lớn câu trả lời trên Internet giả định quy trình dành cho họ Debian hoặc họ Red Hat. Vì vậy, nếu chọn một họ khác, bạn sẽ phải chuyển đổi hướng dẫn trong suốt thời gian sử dụng máy. Hãy chọn họ có release policy phù hợp với tần suất bạn sẵn sàng can thiệp vào server, rồi giữ nguyên lựa chọn đó. Thay đổi các package bên trên thì dễ. Thay đổi distribution bên dưới chúng đồng nghĩa với việc rebuild máy.

FAQ

Máy chủ của tôi thuộc họ bản phân phối Linux nào?

Chạy cat /etc/os-release. Trường ID cho biết tên bản phân phối và ID_LIKE cho biết họ của nó. Vì vậy, máy Ubuntu sẽ báo ID_LIKE=debian, còn máy AlmaLinux sẽ báo ID_LIKE="rhel centos fedora". Package manager là dấu hiệu còn lại. apt và dpkg cho biết máy thuộc họ Debian, dnf và rpm cho biết máy thuộc họ Red Hat, apk cho biết Alpine, còn pacman cho biết Arch.

CentOS có còn là phiên bản miễn phí của RHEL không?

Không. CentOS Linux 8, bản rebuild cuối cùng mang tên đó, đã kết thúc vào ngày 31 December 2021, còn CentOS Linux 7 đã hết vòng đời vào ngày 30 June 2024. Dự án còn lại là CentOS Stream. Đây là nhánh dùng để build các bản minor release của RHEL, nên CentOS Stream nhận thay đổi trước RHEL thay vì sau đó. Các bản rebuild miễn phí thay thế vai trò cũ là AlmaLinux và Rocky Linux, cả hai đều có thời hạn hỗ trợ 10 năm.

Vì sao Debian stable có số version cũ như vậy?

Vì số version được cố định trong khi các bản sửa lỗi vẫn tiếp tục được đưa vào. Debian backport bản vá bảo mật vào version đã phát hành thay vì import một bản upstream mới hơn. Vì vậy, package hiển thị 2.4.57-2+deb13u1 vẫn có thể chứa bản sửa lỗi được phát hành tuần trước. Hậu tố sau upstream version là Debian revision, còn apt changelog <package> liệt kê những thay đổi đã được đưa vào đó. Đánh giá mức độ an toàn của server Debian chỉ dựa trên số version sẽ luôn cho kết luận sai.

Tôi có nên chạy rolling release như Arch trên VPS không?

Chỉ khi bạn cập nhật nó theo lịch cố định. Rolling distribution giả định mọi máy đều hội tụ về bộ package hiện tại. Vì vậy, cập nhật một package bằng pacman -Sy foo có thể để lại các library không đồng bộ và những lỗi như cannot open shared object file. Hãy chạy pacman -Syu thường xuyên và đọc trang tin tức của dự án trước mỗi lần chạy. Khi đó, hệ thống sẽ ổn định. Nếu để một năm không cập nhật, lần upgrade đầu tiên sẽ trở nên rủi ro.

Immutable hoặc atomic distribution thực sự thay đổi điều gì?

Nó thay đổi thời điểm áp dụng update và cách hoàn tác chúng. /usr được mount ở chế độ chỉ đọc. Bản update được chuẩn bị thành một tree mới hoàn chỉnh và chỉ chuyển sang tree đó khi reboot. Tree trước đó vẫn được giữ dưới dạng boot entry để rollback. Máy sẽ ở trạng thái hoặc đã update đầy đủ, hoặc hoàn toàn chưa update, không có trạng thái áp dụng dở dang. Đổi lại, bạn không thể cài software bằng cách sửa trực tiếp các file tại chỗ. Vì vậy, ứng dụng được đưa vào container hoặc layered package.