APT của Debian dự kiến đưa phụ thuộc bắt buộc Rust vào từ tháng 5/2026

• Trình quản lý gói APT của Debian dự kiến sẽ bao gồm mã và các phụ thuộc dựa trên Rust từ sau tháng 5/2026
• Ở giai đoạn đầu, phạm vi tích hợp gồm trình biên dịch Rust, thư viện chuẩn và hệ sinh thái Sequoia
• Trình phân tích tệp .deb, .ar, .tar và mã xác minh chữ ký HTTP là các khu vực cải tiến chính về an toàn bộ nhớ và tăng cường kiểm thử đơn vị
• Các port không có toolchain Rust cần xây dựng môi trường Rust trong vòng 6 tháng hoặc ngừng hỗ trợ (sunset)
• Đây là bước đi nhằm giúp toàn bộ dự án chuyển sang công cụ và công nghệ hiện đại, tránh bị kìm hãm bởi yêu cầu tương thích với phần cứng cũ

---

Kế hoạch đưa mã Rust vào APT

• Dự kiến đưa mã Rust và phụ thuộc cứng (hard dependency) vào APT sau tháng 5/2026
  • Thời điểm áp dụng là sau tháng 5/2026, trước đó sẽ không triển khai
• Phạm vi tích hợp ban đầu được giới hạn ở trình biên dịch Rust, thư viện chuẩn và hệ sinh thái Sequoia

Mục tiêu nâng cao chất lượng mã và độ an toàn

• Mã phân tích tệp .deb, .ar, .tar và mã xác minh chữ ký HTTP là các mục tiêu chính của việc đưa Rust vào
  • Tài liệu nêu rõ các khu vực này sẽ hưởng lợi lớn từ ngôn ngữ an toàn bộ nhớ và hệ thống kiểm thử đơn vị được tăng cường

Yêu cầu đối với người bảo trì port

• Các port không có toolchain Rust phải thiết lập môi trường Rust trong vòng 6 tháng
  • Nếu không, port tương ứng có thể bị ngừng hỗ trợ (sunset)

Định hướng của dự án

• Nhấn mạnh rằng dự án Debian cần phát triển bằng cách tận dụng công cụ và công nghệ hiện đại
  • Đồng thời nêu rõ không nên để tiến độ phát triển bị chậm lại vì cố gắng chạy theo phần cứng cũ hoặc thiết bị retro computing

Thông tin khác

• Người gửi là nhà phát triển cốt lõi của Debian và Ubuntu, Julian Andres Klode
• Email được đăng trên mailing list dành cho nhà phát triển Debian là debian-devel
• Có đính kèm chữ ký PGP (signature.asc)
• Không đề cập thêm chi tiết kỹ thuật hay thay đổi lịch trình

[GN⁺]

Ý kiến trên Hacker News

• Có vẻ cuối cùng cũng đến lúc. Việc vẫn giữ mã phân tích dữ liệu không đáng tin cậy bằng C là một khoản nợ kỹ thuật ngày càng phình to theo thời gian
  Rust không hẳn khó viết hơn C quá nhiều, và nếu ngày nay làm lại C dựa trên hiểu biết hiện tại về thiết kế ngôn ngữ và độ an toàn của mã, có lẽ sẽ ra một ngôn ngữ như Rust
  Nếu có thể bỏ hỗ trợ x86 32-bit vì lý do thực dụng, thì các kiến trúc này cũng vậy. Nếu thật sự muốn duy trì chúng thì phải tự xây backend toolchain Rust

  • Hiện tại, các ngôn ngữ được chấp nhận cho ứng dụng cốt lõi trong hệ thống cơ bản chủ yếu là C, C++, Shell (bash), Perl, Python. Python được thêm vào khoảng 20 năm trước, và Rust là ngôn ngữ đầu tiên đủ gần để thay thế vai trò của C
    Go là ngôn ngữ có lẽ gần nhất, nhưng chưa từng được bàn tới ở mức dùng cho hệ thống lõi như systemd. Cũng tò mò không biết trước đây khi thêm C++, Python, Perl vào thì có tranh cãi tương tự không
  • Người ta nói “trình phân tích .deb, .ar, .tar và mã xác minh chữ ký HTTP sẽ hưởng lợi từ ngôn ngữ an toàn bộ nhớ”, nhưng tôi vẫn nghi ngờ việc phải viết lại bằng ngôn ngữ mới những đoạn mã đã ổn định suốt 30 năm sẽ đem lại lợi ích thực tế nào
    Liệu có đáng để bỏ đi mã đã được kiểm chứng thực chiến rồi tạo thêm vấn đề tương thích và lỗi mới không
  • Có một hướng tiếp cận thực tế hơn để xử lý vấn đề bảo mật của mã C cũ là dự án Fil-C. Cách này biến C gần như thành một ngôn ngữ được quản lý, giúp giảm nhu cầu viết lại
  • Đây không chỉ là vấn đề an toàn bộ nhớ. Cộng đồng C đang già đi, nên ngày càng khó tìm người bảo trì. Đội của chúng tôi cũng đang chuyển toàn bộ mã C/C++ sang ngôn ngữ khác. Phần lớn lập trình viên C/C++ đều ở độ tuổi 40 và ít có ý định đổi việc
  • Tôi khó đồng ý với nhận định Rust là phiên bản tái tạo hiện đại của C. Ví dụ, mã widget đồng hồ của desktop COSMIC khó đọc hơn rất nhiều so với mã C có độ phức tạp tương tự như GNU coreutils

• Xu hướng viết lại hệ thống lõi bằng Rust đang mạnh lên, nhưng tôi vẫn nghi ngờ liệu việc viết lại các công cụ lâu đời có thực sự cải thiện bảo mật hay không
  Tôi hiểu việc đưa hệ thống mới vào là khó, nhưng cảm giác như ta vẫn đang tiếp tục chồng thêm các lớp lên trên những quyết định thiết kế từ thời điện báo

  • Có thể nghe thấy hai lý do cho những lần viết lại như vậy.
    Thứ nhất, gần như không có người đóng góp mới nào muốn đụng vào các codebase C/C++ cũ. Chuyển sang Rust sẽ dễ thu hút lập trình viên mới hơn
    Thứ hai, độ tin cậy được kiểm chứng qua tần suất sử dụng, còn độ an toàn chỉ được kiểm chứng qua tấn công. Không thể nói mã cũ đã trải qua mọi vector tấn công. Vì vậy có cơ sở để tăng cường bảo mật một cách chủ động
  • uutils/coreutils dùng giấy phép MIT, còn GNU coreutils dùng GPL nên có khác biệt về giấy phép. Với doanh nghiệp, đây có thể là điểm quan trọng
  • Ai đó rồi cũng phải học, nên việc viết lại để luyện tập với những dự án đơn giản và dễ kiểm thử là điều chấp nhận được. Nhưng sản phẩm tạo ra có thay thế bản gốc hay không lại là chuyện khác

• Theo luồng thư Debian, Rust thực ra đã là yêu cầu bắt buộc trên hầu hết các kiến trúc phát hành của Debian
  Trong email liên quan, chỉ alpha, hppa, m68k, sh4 được nêu là ngoại lệ. Tôi khá tò mò về số phận sau này của các kiến trúc đó

  • Thật sự tôi muốn biết có còn ai dùng những máy cũ này không. Phần lớn là phần cứng hơn 20 năm tuổi.
    Rust có mục tiêu Tier 3 cho m68k, nhưng không có cho các kiến trúc khác. Tôi tò mò về các trường hợp sử dụng thực tế
  • Theo Debian Supported Architectures, các nền tảng này đang ở trạng thái không chính thức.
    Khá bất ngờ khi chúng vẫn còn trong khi x86 32-bit và MIPS đã bị loại. Cá nhân tôi cũng có chút hoài niệm, nhưng không rõ thực tế chúng còn được dùng vào đâu
  • m68k đã có LLVM port nên về lý thuyết có thể triển khai Rust. Các backend LLVM cho alpha, hppa, sh4 cũng có giá trị như tài liệu tham khảo cho giáo dục
    Trước đây LLVM từng có backend DEC Alpha, nhưng chuyện đó đã lâu rồi
  • Từ góc nhìn của Ubuntu, các kiến trúc này không có giá trị thương mại
  • Chúng đã quá lỗi thời, nên cứ dừng ở bản cuối còn hỗ trợ hoặc tự làm bản phân phối riêng là được. Việc bổ sung hỗ trợ Rust là không thực tế

• Tôi muốn cộng đồng Rust thay vì chen vào các dự án sẵn có thì hãy tự xây công nghệ hiện đại mới để chứng minh
  Những dự án độc lập như Redox là ví dụ như vậy, nên hơi tiếc vì kiểu thử nghiệm này không được đẩy mạnh hơn

  • Đây là quyết định chính thức của Debian trong việc thêm phụ thuộc Rust, không phải do các fan Rust bên ngoài ép buộc
    Tất nhiên vẫn có những người quá khích kiểu “hãy viết lại bằng Rust”, nhưng chuyện lần này không giống vậy
  • ripgrep chính là một ví dụ như thế. Nó được xây mới, và mọi người thực sự thích nó

• Dùng thư viện chuẩn Rust thì không sao, nhưng tôi không muốn kéo theo 500 gói cargo chỉ để build một trình phân tích deb đơn giản

• Có lẽ hợp lý hơn nếu chờ tới khi bản port Rust-for-GCC ổn định
  Kernel cũng chưa định biến Rust thành bắt buộc cho tới khi có hỗ trợ GCC.
  Khi có nhiều triển khai hơn, ngôn ngữ sẽ bớt bất ổn hơn
  Tuy vậy, nếu cắt hỗ trợ kiến trúc ngay bây giờ thì sau này khi có toolchain Rust, quy trình quay lại có thể sẽ phức tạp

  • Thực ra các kiến trúc này đã bị loại khỏi Debian hơn 10 năm nay rồi. Thay đổi lần này không làm chúng mới bị rớt khỏi danh sách
  • Chúng không được hỗ trợ chính thức, chỉ ở mức cá nhân duy trì lúc rảnh. Nếu không có công ty nào nhận bảo trì dài hạn thì rất khó quay lại
  • GCCRS hiện còn chưa build nổi cả libcore, và mới ở mức Rust 1.50. Có lẽ sẽ còn mất nhiều năm mới thành compiler dùng chung
    Thậm chí rustc_codegen_gcc có khả năng ổn định trước
  • Các port này không nằm trong bản phát hành chính thức của Debian mà chỉ được phân phối qua kênh unstable

• Xin nhắc lại rằng tác giả email trong cuộc thảo luận Rust của Debian là người bảo trì gói keepassxc
  Trước đây cũng từng có các luồng thảo luận nói rằng người này có cách hành xử khá thô với lập trình viên upstream và người dùng

  • Tôi cũng kiểm tra ngay sau khi đọc email đó, rồi nhớ lại luồng cũ nên thấy buồn cười
  • Thành thật mà nói, cách diễn đạt của anh ta có hơi gắt nhưng chỉ thẳng thắn chứ không xúc phạm. Tôi thấy đây là drama không cần thiết
  • Bản thân bài HN không hề công kích, có vẻ chỉ là một số người phản ứng quá mức
  • Kiểu văn hóa này khá phổ biến trong thế giới phần mềm tự do. Tôi thấy xu hướng theo đuổi hình mẫu người dùng lý tưởng hơn là người dùng thực tế đã kéo dài từ thời GNOME 3 và Mozilla

• Thật thú vị khi thấy quá trình một người thay đổi quan điểm. Liên kết phát biểu trước đây

  • Việc thay đổi suy nghĩ theo thời gian là điều đáng hoan nghênh
  • Việc APT đưa Rust vào cũng có thể là một quyết định mang tính quản trị giống như chuyển đổi coreutils

• Tôi nghĩ Rust chỉ là một làn sóng cường điệu. Trong thế giới nhúng, C vẫn là vua.
  Thực tế tôi chưa từng thấy ai xung quanh mình dùng hoặc cân nhắc dùng Rust

  • Khó mà kết luận từ việc “xung quanh tôi không có”. Có rất nhiều lập trình viên nhúng dùng Rust
  • Bên trong AWS, các dịch vụ cốt lõi như EC2, IAM, DynamoDB, S3 đều được viết bằng Rust.
    Vẫn giữ được hiệu năng và hiệu quả bộ nhớ trong khi tốc độ phát triển nhanh.
    Nhược điểm duy nhất là kích thước binary. Tôi cho rằng tương lai của Rust đã rất vững chắc
  • Rust cũng rất mạnh ở mảng nhúng, nhưng do thiếu hỗ trợ từ nhà sản xuất nên khối lượng công việc ban đầu theo từng phần cứng khá lớn.
    Dù vậy, thứ hấp dẫn không chỉ là an toàn bộ nhớ mà còn là chất lượng tổng thể của ngôn ngữ và toolchain
  • Hệ sinh thái nhúng cũng đang thay đổi dần nhờ avr-rust, esp-rs, cortex-m
  • Microsoft, Google và nhiều nơi khác cũng đang thảo luận về Rust và áp dụng nó vào sản phẩm thực tế

• Tôi nghĩ môi trường đa ngôn ngữ (polyglot) chỉ tạo thêm vấn đề.
  Python, Node, Go, Rust... mỗi thứ lại cần toolchain và trình quản lý gói riêng nên rất phức tạp
  Loại bỏ được buffer overflow bằng Node thì lại tăng tấn công chuỗi cung ứng.
  Thà làm lại từ đầu còn hơn, và nếu muốn dùng Rust trên diện rộng thì nên góp sức cho Redox OS

  • Thực tế mỗi ngôn ngữ đều có ưu và nhược điểm riêng, và Debian với tư cách là một hệ điều hành thực dụng cần hỗ trợ nhiều ngôn ngữ khác nhau
    Việc viết lại mọi thứ bằng một ngôn ngữ là không thực tế, còn dồn sức cho Redox có khi lại càng kém hiệu quả
    Rust đã là ngôn ngữ được kiểm chứng đủ nhiều, và với tư cách một ngôn ngữ biên dịch ít tự bắn vào chân hơn C khi sửa đổi, nó có giá trị rõ ràng
    Việc bỏ các kiến trúc quá cũ cũng không phải điều quá đáng
  • Với một dự án lớn như Debian, mở rộng lựa chọn là điều hợp lý. Thêm Rust là một quyết định hoàn toàn có thể hiểu được
    Nên loại hay thêm ngôn ngữ nào là việc của các maintainer Debian quyết định
  • Linux đã từ bỏ cuộc chiến chống độ phức tạp từ nhiều thập kỷ trước rồi