Lịch sử Linux distribution: từ Slackware đến 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: chỉ riêng Linux kernel thì không làm được điều gì mà người dùng có thể sử 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, rồi cam kết tiếp tục sửa lỗi trong nhiều năm. Distribution là tập hợp các 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 phần. Chỉ cần thay đổi một phần là bạn đã có một distribution khác, ngay cả khi phần lớn binary giống nhau:

• Kernel ở phiên bản 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à công cụ 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 việc một trong hai distribution đó gần một Unix khác. Điều này đáng ghi nhớ khi bạn so sánh Linux và FreeBSD làm nền tảng server, trong đó kernel và base userland do một project xây dựng rồi phát hành 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 nhất quán với nhau.

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 các họ bản phân phối: Slackware, Debian và Red Hat. Gần như mọi image trong control panel của VPS ngày nay đều là một trong số đó hoặc là hậu duệ của một trong số đó. Hậu duệ thường kế thừa định dạng package, bố cục file và cách phát hành, vì vậy một bản phân phối dựa trên Debian vẫn mang 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 khác. Arch, Gentoo, Alpine, NixOS và Void đều tự viết package manager và tự đặt ra 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, nhưng vì những lý do không liên quan đến desktop.

1992: các bản phân phối trước thời kỳ các họ distro

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. Nó đưa kernel và các công cụ GNU (GNU's not Unix) vào hai image floppy, kèm một trình cài đặt điều khiển bằng menu. Dự án tồn tại vì thực hiện việc đó thủ công sẽ mất cả một 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 và bổ sung X (X Window System) cùng khả năng 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, hai người riêng rẽ 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 lỗi. Dự án vẫn được duy trì, vì vậy đây là bản phân phối Linux lâu đời nhất còn tồn tại.

Một package Slackware là một tar archive được nén, bên trong có script cài đặt. Hệ thống không xử lý dependency: không có thành phần nào kiểm tra thư viện 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 công cụ không xử lý dependency, toàn bộ package được phát hành phải tự nhất quán ngay từ đầu, nên các bản phát hành ít 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 bản phát hành đầ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 dự án phát triển theo hướng riêng với YaST và sau đó là định dạng package RPM. Phần cuối này thường gây nhầm lẫn. SUSE và openSUSE sử dụng package RPM, nhưng không phải là các bản phân phối dẫn xuất từ Red Hat. Định dạng đã được sử dụng rộng rãi. Dòng kế thừa thì không.

Debian, 1993: khế ước xã hội và quy trình 3 suite

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

Sau đó Debian ghi rõ các nguyên tắc này thành văn bản. Debian Social Contract và DFSG (Debian free software guidelines) được thông qua vào July 1997, còn DFSG trở thành nền tảng cho Open Source Definition vào 1998. Một tài liệu được viết để xác định thành phần nào được phép có trong một distribution cuối cùng lại định nghĩa một nhóm giấy phép 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ó card wireless có thể cài đặt mà không phải tự đi tìm từng gói.

Bộ công cụ là di sản quan trọng khác. dpkg cài đặt một package và dừng lại 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 tải thêm những gì và theo thứ tự nào. Mọi lệnh apt trên mọi Debian derivative đều kế thừa từ công việc đó.

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

Cơ chế quản trị cũng được ghi rõ, 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. Những người không đồng ý đã fork thành Devuan, và Devuan phát hành bản đầu tiên vào 2017. Các derivative 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ì bán phần mềm. Red Hat lên sàn vào ngày 11 August 1999. IBM hoàn tất việc mua lại công ty vào tháng 7 năm 2019 với giá khoảng 34 billion dollars. Vì vậy, bản phân phối được phần lớn phần mềm doanh nghiệp chứng nhận đã thuộc IBM kể 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 này về sau đã làm cho việc rebuild độc lập sản phẩm enterprise của Red Hat trở nên khả thi.

Red Hat Linux 9 năm 2003 là bản cuối cùng của dòng sản phẩm ban đầu. Công ty tách dòng này thành hai: Fedora Core 1 vào tháng 11 năm 2003, là bản community phát hành 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 thương mại phát hành 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 version mới, vừa là platform để 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 Fedora, sau đó được ổn định và đóng băng. Công cụ package cũng chuyển đổi theo cùng lịch trình, từ yum vào 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 nhiệm vụ đơn giản: lấy các source package do Red Hat công bố, xóa trademark, rebuild chúng rồi phát hành miễn phí. CentOS trở thành bản phân phối server miễn phí mặc định trong suốt một thập kỷ. Red Hat tiếp nhận dự án vào năm 2014.

Ngày 8 tháng 12 năm 2020, Red Hat công bố 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 lịch đã công bố, đồng thời tên CentOS sẽ tiếp tục được dùng cho CentOS Stream. Stream không phải là một bản rebuild. Đây là branch dùng để tạo các minor release của RHEL, nên nó chạy trước RHEL thay vì chạy sau. Với máy chủ 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 thay đổi trước khách hàng trả phí của Red Hat.

Năm 2021 xuất hiện 2 bản rebuild. Rocky Linux do Gregory Kurtzer, người đồng sáng lập CentOS, khởi xướng. AlmaLinux do 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 của hãng. Rocky tiếp tục hướng đến các bản rebuild giống hệt. AlmaLinux chuyển 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 vẫn 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.

Nếu danh sách image của provider vẫn ghi CentOS, hãy xác định chính xác đó là bản nào trước khi dùng nó để triển khai.

cat /etc/os-release

NAME="CentOS Stream" là branch phát triển rolling đi trước RHEL. NAME="AlmaLinux" hoặc NAME="Rocky Linux" là bản rebuild đi theo RHEL, với thời gian hỗ trợ 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. Quá trình import tiếp tục cho đến Debian Import Freeze ở giữa chu kỳ. Sau thời điểm đó, Ubuntu tự duy trì các thay đổi của mình. Nhiều package Ubuntu là package Debian cộng thêm một delta, và changelog sẽ ghi rõ điều này.

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à một bản LTS (long term support). Đây là loại bản phát hành mà provider muốn nói đến khi liệt kê Ubuntu mà không có qualifier. Việc chọn bản nào trong hai loại để chạy trên server là nội dung chính của việc chọn giữa Ubuntu LTS và bản phát hành interim, còn việc nâng cấp từ một bản LTS lên bả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à phạm vi security coverage của nó là một cam kết khác. apt install không hiển thị thông tin về sự khác biệt này. Một command có thể hiển thị thông tin đó:

apt-cache policy nginx

Một dòng repository kết thúc bằng /main có nghĩa là security team của Canonical chịu trách nhiệm cho package đó. Dòng kết thúc bằng /universe có 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ể nhận traffic 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 tháng 3 năm 2002, cùng một package manager do ông tự viết là pacman và các build recipe chỉ là shell script thông thường. Arch hoàn toàn không có các bản phát hành theo version. Bộ cài là các snapshot có ghi ngày của cùng một rolling repository. Vì vậy, máy được cài vào năm 2019 và cập nhật mỗi tuần đang chạy cùng phiên bản Arch với máy đượ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. Vì vậy, đọc PKGBUILD trước khi chạy là một phần công việc.

Rolling release chỉ có một kiểu lỗi, và lần nào cũng do chính người dùng gây ra. Cài một package đơn lẻ bằng pacman -Sy foo sẽ refresh package database rồi 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. Sau đó, 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

Thao tác được hỗ trợ là pacman -Syu, cập nhật mọi thứ cùng lúc. Project cũng đăng các mục news cho biết 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 mục 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 định bỏ mặc. Máy được cập nhật mỗi tuần thì không vấn đề gì. Nhưng nếu chỉ cập nhật một lần rồi để một năm sau mới cập nhật lại, máy sẽ yêu cầu xử lý toàn bộ các bướ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 khoảng năm 2005 dưới dạng một 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, không phải cho desktop. Alpine thay thế hầu hết userland thường dùng: dùng musl thay cho GNU C library, BusyBox thay cho GNU core utilities, OpenRC thay cho systemd và apk làm package manager. Alpine 3.0 phát hành năm 2014 là phiên bản chuyển sang musl.

Container đã giúp Alpine trở nên phổ biến. Một base layer Alpine chỉ có kích thước bằng một phần nhỏ base của Debian hoặc Ubuntu. Vì vậy, từ năm 2016, Alpine trở thành 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 các lỗi trông như không liên quan. Một 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. Khi đó, pip chuyển sang compile từ source và dừng lại vì không có compiler. Tiêu chuẩn wheel musllinux từ năm 2021 đã giải quyết vấn đề này cho các project phát hành những wheel đó, nhưng không giải quyết cho các project khác.

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

Thế hệ bất biến: cập nhật nguyên tử và máy chủ 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 tải xuống, chuẩn bị sẵn rồi 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 một mục boot, nên có thể hoàn tác 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 máy chủ vào năm 2019, sau khi Red Hat mua CoreOS vào năm 2018. Flatcar Container Linux tiếp tục dòng Container Linux ban đầu sau khi dòng này bị ngừng vào năm 2020. openSUSE MicroOS đạt 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, xây dựng trên bootc, trong đó hệ điều hành được phát hành dưới dạng container image và máy được cập nhật bằng cách trỏ đến một tag mới. Talos Linux tiến xa nhất khi 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, và các thế hệ trước vẫn có thể boot.

Nhà cung cấp của bạn có thể không cung cấp các hệ thống này dưới dạng image cài đặt 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. Đó là tình huống bạn sẽ gặp khi quản lý nhiều máy chủ Linux cùng lúc và cần chứng minh từng máy giống với các máy còn lại.

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

Chính sách hỗ trợ release là phần của một distribution mà bạn phải sử dụng lâu nhất. Chính sách này được công bố theo số năm. Dưới đây là các khoảng thời gian hỗ trợ cho 5 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 rebuild thường xuyên hơn là host được để nguyên trong thời gian dài. Đội bảo mật Debian hỗ trợ một stable release trong khoảng 3 năm. Sau đó, đội LTS tiếp tục hỗ trợ các kiến trúc phổ biến, đưa tổng thời gian lên khoảng 5 năm. Ubuntu LTS hỗ trợ các package trong main trong 5 năm. Ubuntu Pro mở rộng thời gian 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 máy nhỏ. RHEL 10 công bố thời gian hỗ trợ 10 năm. Gói paid extended life cycle support kéo dài thời gian đó lên 13 năm. AlmaLinux 10 có cùng thời gian hỗ trợ 10 năm như RHEL mà không cần subscription. Đây là toàn bộ lý do các bản rebuild này tồn tại.

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

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

Provider cung cấp các image mà khách hàng thường gọi tên và có thể cài đặt unattended 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 tương thích với RHEL, rồi đặt Alpine, Arch và Fedora ở phía dưới. Khi biết VPS là gì và image được đưa vào disk như thế nào, bạn sẽ thấy rõ quy luật này: provider chọn những hệ điều hành có thể vượt qua quá trình cài đặt unattended và được hỗ trợ lâu hơn thời gian trung bình khách hàng duy trì 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ẽ upgrade trong ba năm nữa, và cách đó khác hoàn toàn giữa các family. Debian và Ubuntu hỗ trợ upgrade major version ngay trên hệ thống hiện tại. Red Hat family thực hiện việc này qua leapp. Arch không có upgrade vì nó không có version. Alpine thực hiện việc này 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 third-party repository, 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, và phần mềm tương lai của bạn sẽ mặc định có init system và C library nào.

Còn một ảnh hưởng khác cũng dễ bị đánh giá thấp. Phần lớn câu trả lời trên Internet đều giả định quy trình theo Debian family hoặc Red Hat family. Vì vậy, nếu chọn ngoài hai nhóm này, bạn sẽ phải chuyển đổi hướng dẫn trong suốt thời gian server hoạt động. Hãy chọn family 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ì đơn giản. Thay đổi distribution bên dưới chúng đồng nghĩa với việc rebuild box.

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 nhận biết còn lại. apt và dpkg thuộc họ Debian, dnf và rpm thuộc họ Red Hat, apk là Alpine, còn pacman là 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 này, đã kết thúc vào 31 December 2021. CentOS Linux 7 đã hết vòng đời vào 30 June 2024. Dự án còn lại là CentOS Stream. Đây là nhánh được dùng để build các bản phát hành minor của RHEL, nên nhận thay đổi trước RHEL thay vì sau đó. Các bản rebuild miễn phí tiếp quản 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 phát hành các version quá cũ?

Vì số version được đóng băng trong khi các bản sửa lỗi vẫn tiếp tục được đưa vào. Debian backport các bản vá bảo mật vào version đã phát hành thay vì nhập một bản upstream mới hơn. Vì vậy, một package hiển thị 2.4.57-2+deb13u1 vẫn có thể chứa bản sửa lỗi được công bố 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 độ bảo mật của server Debian chỉ dựa trên số version lúc nào cũng cho kết quả sai.

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

Chỉ nên chạy nếu bạn cập nhật theo lịch cố định. Rolling distribution giả định mọi máy sẽ hội tụ về package set 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à gây ra lỗi như cannot open shared object file. Hãy chạy pacman -Syu thường xuyên, đọc trang tin tức của dự án trước mỗi lần chạy, và 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ở thành lần có rủi ro cao.

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. Update được chuẩn bị dưới dạng một tree mới hoàn chỉnh. Việc chuyển sang tree mới diễn ra khi reboot, còn tree trước đó được giữ lại dưới dạng boot entry để rollback. Bạn có một máy hoặc đã được update hoàn toàn, hoặc chưa được update hoàn toàn, 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 chỉnh sửa file tại chỗ. Vì vậy, ứng dụng được đưa vào container hoặc layered package.