Lập trình viên OpenBSD từ chối chuyển uutils coreutils vì lo ngại giấy phép và khả năng tương thích

Một đề xuất đưa bản tái hiện uutils coreutils bằng Rust vào cây ports của OpenBSD đã làm dấy lên tranh luận gay gắt trên danh sách thư của dự án. Nhà sáng lập Theo de Raadt cùng các lập trình viên kỳ cựu đã thẳng thừng bác bỏ, coi đây là sự trùng lặp không cần thiết và tiềm ẩn rủi ro về hành vi không tương thích với hệ thống cơ sở.

Đề xuất gây tranh cãi

Ngày 20/9, David Uhden Collado đã gửi port sysutils/uutils, đóng gói các bản tái hiện bằng Rust của GNU coreutils như những lựa chọn thay thế trực tiếp. Port này cài đặt các lệnh có tiền tố "g" — gồm gcat, gls, gcp, gdate, gsort, gstat, gtail, gtimeout và nhiều lệnh khác — dưới dạng liên kết tượng trưng tới một binary đa năng đặt tại libexec/uutils.

Mỗi gói đều xung đột với phiên bản GNU tương ứng và khai báo port GNU như một @pkgpath phụ.

Phản hồi đến ngay lập tức và đầy hoài nghi.

"Mùi của một mục đích ngầm"

Stuart Henderson, một lập trình viên lâu năm của OpenBSD, mở đầu bằng sự hoài nghi: "Tôi không nghĩ đây là cách tiếp cận khả thi cho ports." Ông thừa nhận Ubuntu 26.10 đã áp dụng uutils coreutils, nhưng đánh giá các bản tái hiện khác vẫn còn đang trong quá trình hoàn thiện.

Theo de Raadt, nhà sáng lập OpenBSD, thì thẳng thắn hơn nhiều. Ông viết: "Có mùi của một mục đích ngầm", trước khi bác bỏ lập luận về giấy phép.

"Tôi cũng nghĩ chúng khá phù hợp với OpenBSD như các lựa chọn thay thế cho tiện ích GNU, đặc biệt vì chúng dùng giấy phép MIT thoáng. Lập luận đại khái là: vì chúng ta đã có các tiện ích giấy phép thoáng, người dùng của chúng ta thực sự muốn có thêm một bộ tiện ích giấy phép thoáng thứ hai nhưng lại khác biệt rất tinh vi. Điều đó chẳng có nghĩa lý gì."

Hệ thống cơ sở của OpenBSD vốn đã đi kèm các tiện ích chuẩn được cấp phép thoáng (giấy phép BSD). Dự án đã dành hàng thập kỷ để đảm bảo các công cụ này hoạt động nhất quán và có thể dự đoán trước với nhau. Theo de Raadt lập luận rằng việc đưa vào bộ công cụ thứ hai với hành vi "khác biệt tinh vi" sẽ tạo ra vấn đề thực sự cho người dùng khi đường ống (pipe) kết quả giữa các tiện ích.

Bài toán tương thích

"Không ai muốn những binary hành xử khác biệt tinh vi trong quy trình làm việc của mình," de Raadt tiếp tục. "Nếu ai đó chạy lệnh ls của OpenBSD trong một pipeline dùng sed, cut hay một tiện ích OpenBSD khác, và nó vô tình phân tích một đặc tính đầu ra không chuẩn hóa, thì không có ai trên đời này muốn thay thế ls đó bằng một ls khác rồi bị bất ngờ vì xung đột hành vi công cụ không chuẩn hóa."

Điều này chạm tới nguyên tắc cốt lõi của OpenBSD: hệ thống cơ sở là một chỉnh thể thống nhất. Các tiện ích được phát triển và kiểm thử cùng nhau. Việc thay thế từng thành phần bằng bản tái hiện — dù tương thích — có thể làm hỏng các script và pipeline phụ thuộc vào định dạng đầu ra, mã thoát (exit code) hay hành vi biên cụ thể.

Rust trở thành điểm nóng

Khi Collado đề cập sự không chắc chắn về việc cài đặt từng tiện ích riêng lẻ, với lý do cấu trúc metapackage của uutils và việc triển khai bằng Rust, de Raadt nắm bắt ngay: "Ồ, vì nó viết bằng Rust. Mục đích ngầm của bạn lộ ra rồi."

Câu hỏi về Rust đã nhiều lần nổi lên trong cộng đồng BSD. FreeBSD từng thử nghiệm Rust trong hệ thống cơ sở. OpenBSD thì chưa, với lý do chu kỳ phát hành nhanh của ngôn ngữ này, chuỗi phụ thuộc lớn và khó khăn khi khởi tạo bộ công cụ Rust trên các kiến trúc mà OpenBSD hỗ trợ. Dự án duy trì bộ biên dịch C riêng và từ trước đến nay tránh thêm runtime ngôn ngữ mới vào bản cài đặt cơ sở.

Độ chín muồi và gánh nặng bảo trì

Nhắc đến việc Ubuntu áp dụng mang theo một lưu ý ngầm: Ubuntu 26.10 chưa phát hành, và việc Canonical sẵn sàng tung ra phần mềm mới không đồng nghĩa với chu kỳ phát hành thận trọng của OpenBSD. OpenBSD 7.6 ra mắt tháng 10/2024; 7.7 dự kiến vào tháng 4/2025. Dự án ưu tiên ổn định hơn là mới lạ.

Ngoài độ chín muồi, bản thân cấu trúc port cũng gây lo ngại. Dự án uutils phân phối một binary đa năng duy nhất — một tệp thực thi điều phối tới các tiện ích khác nhau dựa trên argv[0]. Thiết kế vay mượn từ BusyBox này xung đột với quy ước đóng gói của OpenBSD, vốn yêu cầu từng binary riêng biệt. Cách tiếp cận metapackage cũng đồng nghĩa việc cập nhật một tiện ích đòi hỏi phải xây dựng lại và phân phối toàn bộ bộ công cụ.

Bối cảnh rộng hơn

Dự án uutils, đặt tại github.com/uutils/coreutils, đã đạt tiến bộ đáng kể. Tính đến năm 2024, nó vượt qua phần lớn các bộ kiểm thử của GNU coreutils và đã được một số bản phân phối Linux áp dụng cho các trường hợp sử dụng cụ thể. Giấy phép MIT hấp dẫn những dự án muốn tránh mã nguồn cấp phép GPL.

Nhưng việc OpenBSD từ chối cho thấy sự khác biệt triết lý căn bản. Các bản phân phối Linux thường coi tiện ích là những thành phần có thể thay thế cho nhau. OpenBSD coi chúng là một hệ thống tích hợp, được tuyển chọn kỹ lưỡng. Lệnh ls(1) của dự án không chỉ là "một bản triển khai ls" — đó là ls mà find(1), tar(1) và các script shell đã được kiểm thử cùng trong nhiều năm.

Điều gì sẽ xảy ra tiếp theo

Port này vẫn đang trong giai đoạn đề xuất. Trước sự phản đối từ cả nhà sáng lập dự án lẫn các lập trình viên ports kỳ cựu, khả năng được chấp nhận có vẻ khó xảy ra nếu không có thay đổi đáng kể — chẳng hạn tách binary đa năng thành từng tiện ích riêng biệt, chứng minh hành vi tương đương với các công cụ cơ sở của OpenBSD, và giải quyết lo ngại về việc khởi tạo Rust.

Hiện tại, người dùng OpenBSD muốn có tiện ích tương thích GNU vẫn sẽ tiếp tục dùng port sysutils/coreutils sẵn có, vốn đóng gói chính các bản triển khai GNU thực sự. Thí nghiệm uutils, ít nhất là trên OpenBSD, xem ra đã đâm phải một bức tường triết lý.