Debian 13 "Trixie" ra mắt

• Dự án Debian đã ra mắt phiên bản Debian 13 "Trixie" ổn định mới sau 2 năm 1 tháng 30 ngày phát triển
• GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0, Xfce 4.20 và nhiều môi trường máy tính để bàn khác đã được hỗ trợ mặc định
• Hơn 14.100 gói mới đã được thêm vào, tổng số gói là 69.830 và 8.840 gói bị loại bỏ do lỗi thời
• 44.326 gói đã được cập nhật và tiến hành dọn dẹp lớn về cơ sở mã; dung lượng đĩa tổng cộng là 403GB và số dòng mã đạt 1,4 tỷ
• Kiến trúc hỗ trợ: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
  • Hỗ trợ chính thức cho riscv64 được giới thiệu lần đầu tiên
  • Quyết định ngừng hỗ trợ i386: không cung cấp kernel và công cụ cài đặt chính thức, chỉ có thể sử dụng hạn chế trên CPU 64-bit
  • Kiến trúc armel là lần hỗ trợ cuối cùng trong bản phát hành này
• Ngoài i386, trên tất cả kiến trúc khác đã áp dụng ABI time_t 64-bit, hỗ trợ cả ngày tháng sau năm 2038

• Phần mềm và công cụ phát triển

  • Hơn 63% tổng số gói đã được cập nhật
  • Phần mềm và công cụ phát triển tiêu biểu: Apache 2.4.64, Bash 5.2.37, BIND 9.20, curl/libcurl 8.14.1, Emacs 30.1, GNU Compiler Collection 14.2, GIMP 3.0.4, LibreOffice 25.2, Linux kernel 6.12 LTS, LLVM/Clang 19, Python 3.13, Rustc 1.85, Systemd 257, Vim 9.1 và nhiều mục khác
  • Thích hợp cho nhiều mục đích sử dụng khác nhau như arch, máy chủ, máy tính để bàn, cluster, cơ sở dữ liệu, máy chủ web và máy chủ lưu trữ
  • Quy trình đảm bảo chất lượng như cài đặt tự động và kiểm thử nâng cấp đã được tăng cường

• Hỗ trợ đám mây và live installation

  • Cung cấp hình ảnh cho các dịch vụ đám mây như Amazon EC2, Microsoft Azure, OpenStack, PlainVM, NoCloud
  • Hình ảnh đám mây đã tích hợp tự động hóa cloud-init và tối ưu hóa kernel/bootloader để khởi động nhanh instance
  • Hình ảnh live được cung cấp cho amd64 và arm64 dưới dạng DVD, USB, và khởi động qua mạng
  • Hình ảnh live cho phép trải nghiệm qua nhiều môi trường desktop khác nhau; ảnh chuẩn không có GUI cũng có thể sử dụng
  • Có thể cài đặt bằng Calamares và Debian Installer chuẩn, đồng thời hỗ trợ nhiều phương thức cài đặt khác như HTTP Boot

[zihado]

Không biết mọi người vẫn khỏe không nhỉ, những người từng có mặt ở kênh irc của Debian. Hồi thời Debian Potato mình hay chơi IRC nhiều lắm... haha

[jungmin1237]

Tag Docker cũng đã có rồi.
https://hub.docker.com/layers/library/…

[dongjinahn]

Tôi cũng đã chuyển từ Ubuntu sang Debian trên VPS 512MB giá $2.5/tháng và thấy khá ổn. Vì đã quen dùng Ubuntu trước đó nên rất dễ thích nghi, và bộ nhớ cũng tiêu thụ ít hơn.

[GN⁺]

Ý kiến trên Hacker News

• Tôi đang viết bài này trên một hệ Debian và dùng nó như máy chạy hàng ngày, rất hài lòng. Sau khi Ubuntu ngày càng xấu đi, tôi đã chuyển sang Debian 6 và chưa bao giờ hối tiếc. Debian làm tôi ấn tượng vì cân bằng cả giữa tư tưởng lẫn tính thực dụng: mặc định theo đuổi phần mềm tự do, nhưng vẫn cho phép cài firmware/phần mềm non-free khi cần; tôi cũng rất thích các hướng dẫn đóng gói, dpkg và tài liệu rất chặt chẽ của nó (về tài liệu thì Arch vẫn hơn). Việc có các stream stable/testing giúp chọn giữa độ ổn định của bản cũ và bản gần như ổn định nhưng mới hơn. Trên hết, trừ khi tôi vô tình làm sai, chưa một lần nào tôi thấy Debian tự hỏng do lỗi nội tại. Có thời điểm lỗi nghiêm trọng làm không boot được hoặc có vấn đề, nhưng mỗi lần đều do thêm kho của bên thứ ba hoặc chỉnh cấu hình sai.

  • Tôi đồng ý Debian tuyệt vời, nhưng cũng không thể khẳng định chắc chắn rằng nó không bao giờ hỏng trước khi mình làm sai. Đặc biệt, Debian stable có rất nhiều patch cho kernel; ở subsystem DRM thay đổi nhanh, tôi đã nhiều lần gặp crash khó debug trong quá trình backport. Dù theo danh nghĩa kernel thường giữ nguyên suốt cả chu kỳ phát hành, nhưng thực tế việc dùng kernel mới liên tục như Ubuntu (dòng hwe) khiến áp lực patch như vậy ít hơn. Vì thế tôi dùng Debian cho VM và Ubuntu cho bare-metal. Tôi chưa thử dùng kernel từ repo debian-backports.
  • Tôi cũng đã từng cực mệt vì các sự cố nâng cấp khi dùng Ubuntu Server. Tôi vận hành hơn 75 VPS, và khi làm cập nhật bảo trì từng lo rằng có thể sẽ bị không boot được. Việc phục hồi do mỗi VPS tốn thêm 1–2 giờ. Từ lúc chuyển sang Debian thời 8.x (khoảng năm 2015), mọi thứ ổn định hơn nhiều. Như thường lệ, miễn là tôi không tự gây lỗi, chưa thấy Debian bị hỏng.
  • Tôi tò mò phần nào đã khiến bạn thấy Ubuntu tệ hơn như vậy.
  • Nhược điểm duy nhất của Debian là nó thường cố gắng chạy service ngay sau khi cài xong. Dù hầu hết cấu hình mặc định khá an toàn, nhưng khi thấy service tự bật dù chưa kịp cấu hình vẫn hơi đáng sợ. Red Hat lại theo hướng tới khi tôi tự bật thì service mới chạy, nên điểm này khiến tôi thích hơn.
  • Debian là nền tảng cho hệ server của mình. Tôi để server ở chế độ old stable, còn các tính năng mới thì kiểm tra trên hệ tạm. Trên Bookworm tôi học nftables, trên Trixie thử labwc. labwc hỗ trợ Wayland nhưng vẫn cấu hình theo kiểu Openbox.

• Tôi rất biết ơn các tình nguyện viên cộng đồng Debian. Debian và vô số dự án dựa trên Debian được hiện thực hóa là nhờ công sức của các bạn. Rất nhiều cá nhân và doanh nghiệp đều được hưởng lợi từ nỗ lực của bạn. Cá nhân tôi, tôi đặc biệt phấn khích với bản phát hành Trixie này. Dự án phụ của tôi, ntfy, đã được đưa vào và nằm trong Trixie. Tuy nhiên, chỉ đến giai đoạn cuối kỳ phát hành tôi mới biết người đóng gói ntfy đưa ra truy vấn license, và khi đó mới thấy web app đã bị loại khỏi package Debian, một số tính năng cũng bị xóa bằng patch. Tôi đã thêm build tags để dễ loại bỏ Stripe, Firebase, WebPush; hy vọng bản Debian tiếp theo sẽ có ít patch hơn. Ở góc nhìn maintainer upstream, tôi thấy tiếc vì không có thông tin rõ ràng lý do bỏ web app. Tôi hiểu là đã loại bỏ có chủ đích, nhưng chưa biết làm sao để đưa lại trong bản tiếp theo. Nếu apt install ntfy mà không có web app, nhiều user sẽ thất vọng. Rất mong nhận được lời khuyên hay hướng dẫn. Có thể xem thêm source code.

  • Người duy trì package đã thêm phần giải thích liên quan (đây). Web app chạy bằng nodejs, và những package nodejs tương ứng chưa có trong Debian. Theo triết lý Debian, việc đưa source dependency trực tiếp vào package là điều không được khuyến khích. Chắc vì như vậy phải tự tạo và duy trì thêm các package phụ thuộc nên rất nặng.
  • Build package npm trong Debian phải build được. Vì vậy trong một package.json riêng cho Debian cần thay thế dependency npm thành package Debian, hoặc port chúng đi, hoặc tách thành package riêng. Đây có thể là khá nhiều công việc tiềm ẩn; nếu lockfile quá lớn thì công sức còn lớn hơn nữa. Có lẽ maintainer thấy khối lượng này quá sức. Theo kiểu Debian, có vẻ tự nhiên hơn khi tách ntfy-web thành package riêng.
  • Tôi vô cùng biết ơn nhờ ntfy. Tôi dùng nó hằng ngày để nhận thông báo sự kiện từ node Meshtastic ở nhà.
  • Phần mềm ntfy đang chạy rất tốt.
  • Nếu muốn giải quyết vấn đề dependency, triển khai bằng container image có thể là cách tốt hơn.

• Debian là nền tảng ổn định cho cuộc sống “tự do tính toán” của tôi. Từ cách bỏ phiếu Condorcet, đến thủ tục đồng thuận, đến ra quyết định dựa trên nguyên tắc đã ảnh hưởng nhiều đến tôi. Tác động của dự án này và văn hóa của nó đến thế giới là thật sự to lớn. Xin chúc mừng với tất cả tình cảm.

• Về việc i386, giờ đây đã gần như chính thức chấm dứt hỗ trợ (không còn kernel hay installer mới, chỉ khuyến nghị trên CPU 64-bit; phần cứng 32-bit thuần không còn khuyến nghị nâng cấp nữa). Việc i386 vẫn được hỗ trợ đến tháng 8/2025 là rất đặc biệt. Tôi vẫn còn chạy Debian 10 Buster trên phần cứng Pentium 3 (EOL tháng 6/2024), vì vậy có thể thử nghiệm lại trên phần cứng cũ được, điều này rất có ích. Nếu ai đó cần OS mới trên i386, OpenBSD cũng đáng để cân nhắc.

  • Tôi cứ nghĩ từ khoảng 2007 là đeo Pentium 3 rồi, chứ giờ có thể mua PC nhanh hơn 100 lần với $1.
  • Nếu i386 chuyển qua hạ tầng Debian ports (như m68k) thì có thể tiếp tục dùng thử nghiệm trong Debian 14 hoặc 15.
  • Mình nhớ rằng old stable thường còn được hỗ trợ thêm khoảng 1 năm. Nghĩa là sau 2025 thì chưa phải kết thúc hoàn toàn.
  • Đây là câu chuyện về hỗ trợ Debian; Linux kernel bản thân vẫn tiếp tục hỗ trợ CPU 32-bit sau Pentium gốc (trừ một số chipset clone).
  • Có nhầm lẫn giữa "386" và 32-bit không? Bình thường 686 là kiến trúc 32-bit phổ biến, 386 đã là chuyện của thập niên 1980.

• sysvinit vẫn có thể dùng được. Tôi đã test ở server/desktop rồi. Với dependency của một số package, có thể tránh lỗi bằng cách gỡ và cài đồng thời qua lệnh dạng dưới đây. Theo lỗi Debian liên quan, chìa khóa là phải gỡ systemd-sysv và systemd với dấu - ở đầu. Cách này tạo build sysvinit bằng debootstrap gần giống bookworm (kể cả desktop). Như khi dùng bookworm hay buster, chỉ cần giữ libsystemd0 trong apt preferences và chặn các package systemd khác bằng priority -1.

  • Tôi thật sự tò mò liệu Debian 13 có chạy ổn với sysvinit không. Tức là có thể vận hành server chỉ bằng sysvinit, không cần systemd?
  • Cảm ơn đã chia sẻ. Tôi sẽ thử trong lxc container trước.
  • Tôi tò mò vì sao phải làm tận mức đó.

• Vì dễ tìm file .torrent cho x86-64 nên mình gom link: Minimal: netinstall ISO
  Full: DVD ISO

  • Hầu hết user không cần image DVD(full). Chỉ cần CD netinstall minimal để tải package khi cài đặt là đủ.

• Danh sách 7 kiến trúc chính thức được Debian Trixie hỗ trợ:

  • amd64(64-bit PC)
  • arm64
  • armel(ARM EABI)
  • armhf(ARMv7 EABI hard-float)
  • ppc64el(64-bit little-endian PowerPC)
  • riscv64(64-bit little-endian RISC-V)
  • s390x(IBM System z)
    RISC-V có ít phần cứng thực tế đủ tốt, nhưng cuối cùng cũng được xem như một nền tảng hàng đầu đã là điều đáng mừng. Tôi tò mò PowerPC và System z giờ dùng ở đâu, và ngoài amd64/arm64/riscv64 thì kiến trúc nào khác đang được triển khai thực tế.
  • Power và z vẫn là doanh nghiệp tỉ đô. Cả hai đều dùng nhiều trong ngành tài chính và ngân hàng. IBM vẫn tự hào về z; với Power thì tôi thấy như vẫn được duy trì hơn là phát triển, nên hơi tiếc. Power là kiến trúc và hệ thống rất tốt.
  • Mainframe có vị trí trong những nơi cần một server chạy liên tục hàng chục năm mà không dừng. Thậm chí cả CPU, RAM đều có thể hot-swap, và ngoài dịch vụ OS thì còn có giám sát/chẩn đoán phần cứng 24/7. Khi phát hiện lỗi phần cứng, hệ thống tự gửi cảnh báo cho chủ sở hữu và IBM. IBM đã hỗ trợ Linux như OS cấp một cho mainframe từ đầu những năm 2000. Từ góc nhìn developer, s390x gần như là kiến trúc big-endian cuối cùng còn lại (vẫn có SPARC nhưng gần như maintenance mode, và Oracle hiện chỉ chăm về Solaris), nên rất hữu ích để bắt bug endian. Hiện chỉ còn hai kiến trúc 32-bit là armel và armhf, và bản này là lần cuối hỗ trợ armel (xem thêm). Chắc chắn sắp tới sẽ kết thúc hỗ trợ 32-bit chính thức.
  • IBM đang đổ nhiều nỗ lực để giữ hai kiến trúc này chạy tốt trên các distro chính. Vì vậy khác với các kiến trúc khác, chúng không tự duy trì trong hệ sinh thái mà được giữ nhờ sự hậu thuẫn của IBM.

• Nếu lo ngại vấn đề đặt tên NIC trong systemd, hãy xem release notes. Dùng lệnh udevadm có thể kiểm tra trước xem tên interface sẽ đổi thế nào sau nâng cấp. Danh sách còn lại trừ bond/lo cũng có thể xem bằng one-liner bên dưới. Theo các lần tôi test trực tiếp, chưa từng có lần tên interface đổi do nâng cấp. Vì vậy tôi không chắc cách này có bắt được đổi tên thực sự hay không.

  • Có lẽ đây là lần thay đổi lớn cuối cùng liên quan đến naming interface. Ký hiệu enoX nên ổn định vì BIOS (bảng ACPI...) cho biết cổng nào có ID nào. Dạng ensX dựa theo PCIe slot nhưng một slot PCIe trong cây PCIe có thể có nhiều NIC, nên phức tạp. Hệ thống đã sửa logic naming nhiều lần để giải quyết các trường hợp ngoại lệ này. Trước đây đã từng có lần đọc gián tiếp PCIe slot gây xung đột; vấn đề này đã được fix trong systemd 257.
  • Tôi tò mò liệu đã tắt Predictable Network Interface Names của systemd trước nâng cấp thì interface có thể vẫn đổi sau nâng cấp không.

• Tôi dùng Debian từ thời slink. Vẫn còn apt-get ... mỗi lần vào việc và nó vẫn chạy được. Hơn 25 năm nâng cấp có nhiều lỗi lớn nhỏ, nhưng thời gian/công sức so với Linux khác hay phần mềm đóng vẫn không đáng kể. Chỉ tiếc là tôi chưa đóng góp được nhiều cho cộng đồng. Tôi nghĩ một lợi thế lớn của Debian là nó buộc người dùng hiểu ở mức tối thiểu cách hệ thống vận hành; vì thế mới giữ được triết lý "đơn giản nhất có thể nhưng không quá đơn giản".

• Một điểm mạnh của Debian là có thể nâng cấp stable này sang stable khác dưới 15 phút. Hệ đầu tiên của tôi hoàn tất migration dưới 10 phút, gồm cả tải package và reboot. Đó cũng không phải máy tính hiệu năng cao hay mạng nhanh, chỉ là mini PC 50Mbps.