Vì sao Debian có diện mạo như hiện nay?
(blog.liw.fi)- Những tập quán đặc trưng của Debian bắt nguồn từ các lựa chọn mà một hệ điều hành đa dụng quy mô lớn đã 30 năm tuổi tích lũy để duy trì lâu dài chất lượng, bảo mật và các nguyên tắc phần mềm tự do
- Debian không phải là bản phân phối cho một mục đích cụ thể, mà hướng tới một bản phân phối đa dụng phù hợp với hầu hết mọi người và hầu hết mục đích; tiêu chí cốt lõi để đưa gói vào là tính phần mềm tự do và chất lượng bảo trì
- Hiến pháp, Khế ước Xã hội và DFSG là các cơ chế ra đời sau khi cách vận hành lỏng lẻo ban đầu bộc lộ giới hạn, thể chế hóa quy trình ra quyết định dân chủ và quyền hạn hạn chế của lãnh đạo
- Build tự chứa và tránh thư viện bundled là chiến lược bảo trì giúp Debian không bị lệ thuộc vào kho bên ngoài hay phụ thuộc trùng lặp, đồng thời có thể sửa bảo mật khẩn cấp, rebuild và port sang kiến trúc mới
- Quy trình xét duyệt thành viên, tên mã phát hành và tốc độ thay đổi chậm là cách một dự án có hàng nghìn gói và nền tảng cài đặt hàng chục triệu máy quản lý niềm tin, chi phí mirror và chi phí đạt đồng thuận
Hệ điều hành mà Debian hướng tới
- Debian hướng tới một hệ điều hành có chất lượng cao, bảo mật và tính đa dụng, đồng thời muốn được cấu thành chỉ từ phần mềm tự do và mã nguồn mở, chạy được trên hầu hết các máy tính đang được sử dụng tích cực
- Mục tiêu là một hệ điều hành đa dụng có nghĩa là Debian nên phù hợp với hầu hết mọi người trong hầu hết mục đích
- Không thể phù hợp với mọi tình huống, nhưng đó là một mục tiêu đáng theo đuổi
- Điều này dẫn tới các quyết định khác với những bản phân phối tập trung vào một mục đích cụ thể như desktop, server, chơi game hay nghiên cứu khoa học
- Việc có đóng gói một phần mềm hay không phụ thuộc nhiều hơn vào các tiêu chí sau so với công dụng của phần mềm
- Phần mềm đó có phải là phần mềm tự do hay không
- Debian có thể duy trì nó dưới dạng gói chất lượng cao hay không
Hiến pháp và quản trị
- Debian khá gần với một tổ chức mã nguồn mở dân chủ một cách rõ ràng
- Quy trình ra quyết định được định nghĩa rõ
- Mỗi năm bầu Debian Project Leader
- Quyền hạn của trưởng dự án bị giới hạn nghiêm ngặt, và nhiều quyền thường gắn với vai trò lãnh đạo được ủy quyền rõ ràng cho người khác
- Những Debian Project Leader thời kỳ đầu trên thực tế gần giống các nhà độc tài có toàn quyền cho đến khi họ tự rời vị trí
- Sau khi một trưởng dự án vượt quá giới hạn, sự phản đối đã khiến người đó rời đi, và kết quả là dân chủ được đưa vào
- Debian định nghĩa các quy tắc của dự án bằng hiến pháp chính thức
- Hệ thống quy tắc hiện nay bắt nguồn từ trải nghiệm trong giai đoạn đầu lịch sử rằng ít quy tắc hơn và ít quan liêu hơn đã không vận hành tốt trong Debian
Khế ước Xã hội và Debian Free Software Guidelines
- Vào giữa thập niên 1990, thuật ngữ “open source” còn chưa được đưa ra, còn “free software” đã được Free Software Foundation định nghĩa nhưng vẫn có nhiều khoảng diễn giải
- Debian muốn có các quy tắc rõ ràng hơn nên đã tạo ra Debian Free Software Guidelines(DFSG) và đưa nó thành một phần của Khế ước Xã hội
- Khế ước Xã hội là văn kiện nền tảng cam kết Debian là gì và làm gì đối với chính mình cũng như với thế giới
- DFSG là một phần của văn kiện đó
- Hiến pháp Debian cố ý khiến việc thay đổi Khế ước Xã hội trở nên khó khăn
- Các quy tắc chi tiết hơn giúp làm rõ Debian sẽ chấp nhận điều gì và đơn giản hóa các thảo luận liên quan
- DFSG về sau trở thành nền tảng của Open Source Definition
Nguyên tắc build tự chứa
- Debian kiên trì với nguyên tắc tự chứa(self-contained)
- Mọi thứ Debian đóng gói phải được build chỉ bằng các phụ thuộc nằm trong Debian
- Mọi thứ trong Debian phải do chính Debian build
- Nguyên tắc này có thể tạo ra rất nhiều công việc bổ sung
- Các công cụ ngôn ngữ lập trình hiện nay thường giả định rằng phụ thuộc sẽ được tải xuống từ kho trực tuyến tại thời điểm build
- Trong Debian, cách làm đó không được phép
- Lý do cốt lõi là các phụ thuộc bên ngoài có thể biến mất về sau
- Debian không kiểm soát các kho gói bên thứ ba
- Nếu một gói hoặc cả kho biến mất, Debian có thể không build lại được gói đó
- Việc nâng cấp trình biên dịch mới, sửa vấn đề bảo mật, port sang kiến trúc mới và đưa vào các bản sửa lỗi đều cần rebuild
- Nếu không tự chứa, tại thời điểm sửa bảo mật khẩn cấp, hàng chục nghìn gói cùng toàn bộ phụ thuộc của chúng đều phải còn khả dụng, nên Debian chọn đóng gói toàn bộ phụ thuộc
Vì sao tránh thư viện bundled
- Debian tránh dùng các bản sao thư viện hoặc bản sao phụ thuộc khác được kèm sẵn trong phần mềm cần đóng gói
- Nhiều dự án upstream thấy việc gói kèm phụ thuộc hoặc xử lý theo kiểu vendor là dễ hơn
- Từ góc nhìn Debian, có thể xuất hiện nhiều bản sao của một thư viện phổ biến
- Nếu thư viện đó có vấn đề bảo mật hoặc vấn đề nghiêm trọng, phải tìm và sửa mọi bản sao
- Với vấn đề bảo mật khẩn cấp, công việc này làm lãng phí thời gian quý giá
- Trong trường hợp zlib, Debian đã phát hiện hàng chục bản sao zlib được bundled trong archive, và đã bỏ ra nỗ lực đáng kể để khiến các gói Debian chỉ dùng phiên bản zlib được đóng gói trong Debian
- Vì vậy Debian làm trước ở giai đoạn đóng gói, trước khi tình huống khẩn cấp xảy ra, để các gói trong Debian dùng phiên bản thư viện được đóng gói trong Debian
- Các nhà phát triển upstream đôi khi chỉ muốn xử lý phiên bản bundled mà họ đã kiểm chứng, nên cách làm này thỉnh thoảng gây va chạm với Debian
Quy trình xét duyệt thành viên
- Vì Debian là một hệ điều hành có quy mô và độ phức tạp lớn, đồng thời được sử dụng rộng rãi, dự án phải tin tưởng các thành viên của mình
- Niềm tin đặc biệt quan trọng với những người upload gói mới
- Do các giới hạn kỹ thuật của Linux trong thập niên 1990, mọi gói Debian đều có toàn quyền root trong quá trình cài đặt
- Mọi nhà phát triển Debian về mặt tiềm năng có thể trở thành người dùng root trên bất kỳ máy nào chạy Debian
- Với việc Debian chạy trên hàng chục triệu máy, đây là một quyền hạn rất lớn
- Thành viên mới được xác minh bằng nhiều cách
- Lý tưởng nhất là họ đã tham gia cộng đồng phát triển Debian đủ lâu để được người khác biết đến
- Họ phải xây dựng được niềm tin trong cộng đồng
- Quy trình này có thể khá gây nản lòng với những người muốn tham gia Debian, đặc biệt là những người quen với các dự án mã nguồn mở nhỏ hơn
Tên mã phát hành
- Debian đặt tên mã cho mỗi bản phát hành lớn
- Tập quán này ban đầu ra đời để giảm chi phí mirror archive gói Debian
- Khi chuẩn bị bản phát hành Debian 1.0 vào giữa thập niên 1990, dự án không dùng tên mã mà tạo thư mục theo tên phiên bản
- Vì việc phát triển bản phát hành mới mất thời gian, thư mục “1.0” được tạo trước
- Một nhà xuất bản CD-ROM đã sản xuất hàng loạt sớm các đĩa ghi “1.0” trước khi Debian 1.0 hoàn tất
- Kết quả là những người nhận CD-ROM Debian 1.0 đã nhận được thứ không phải bản 1.0 thật sự
- Cách giải quyết đơn giản là chuẩn bị trong một thư mục như “1.0-not-released”, rồi đổi tên thành “1.0” sau khi phát hành xong
- Nhưng nếu tên thư mục thay đổi, mọi mirror đều phải tải lại bản phát hành, và với quy mô Debian lúc đó, chi phí là đáng kể
- Quy mô khi ấy ở mức “hàng trăm gói” và “vài chục MB”
- Về sau, archive Debian được bổ sung cấu trúc pool
- Tệp của mọi bản phát hành nằm trong cùng một cây thư mục, còn các tệp metadata chỉ định tệp nào thuộc về từng bản phát hành
- Cấu trúc này giúp việc mirror dễ dàng hơn
- Hiện nay có thể việc bỏ tên mã và chỉ dùng phiên bản là khả thi, nhưng không rõ Debian có quan tâm hay không
Vì sao Debian thay đổi chậm
- Debian là một dự án rất lớn, và các dự án lớn thì thay đổi chậm
- Những thay đổi ảnh hưởng đến nhiều gói có thể cần hàng trăm tình nguyện viên xử lý, nên khó diễn ra nhanh
- Một số việc có thể do số ít người xử lý, và Debian có quy trình để làm điều đó
- Ví dụ, khi một phiên bản mới của GNU C compiler được upload, việc tìm các chỉnh sửa cần thiết trong những gói khác thường có thể do một số ít người thực hiện
- Lý do thay đổi mất nhiều thời gian còn là vì cần hình thành đồng thuận
- Đồng thuận cần thảo luận rộng rãi
- Những thảo luận như vậy mất thời gian và hiếm khi có thể rút ngắn
- Các nhà phát triển Debian có xu hướng bảo thủ trong các quyết định kỹ thuật
- Họ thường ưu tiên các giải pháp không đòi hỏi thay đổi quy mô lớn
1 bình luận
Ý kiến trên Hacker News
Self-contained và không có thư viện được bundle là những khái niệm quan trọng mà một phần hệ sinh thái đã bỏ qua vì cho rằng quá phiền phức.
Chỉ sau khi gặp lại những vấn đề phát sinh từ đó, người ta mới gắn cho chúng các thuật ngữ như “chuỗi cung ứng phần mềm”; còn Debian ngay từ đầu đã làm theo cách tránh các vấn đề này, nên ít phải chịu cùng nỗi đau hơn.
Nếu muốn phân phối phần mềm trên nhiều bản phân phối và hệ điều hành, bundle dependency là hợp lý; còn từ góc nhìn của người bảo trì bản phân phối, thư viện dùng chung rõ ràng tốt hơn vì chỉ cần áp dụng bản vá bảo mật một lần.
Ở cấp hệ điều hành đang có các xu hướng như Nix và Silverblue, ở cấp ứng dụng thì có Snaps và Flatpak; tôi không biết giải pháp là gì, nhưng có vẻ Debian cũng sẽ sớm phải làm gì đó.
Nếu dùng phiên bản khác thì phải kiểm thử cẩn thận và sửa các lỗi phát hiện được; tôi không biết Debian có đủ tài nguyên để làm việc đó không, và rốt cuộc chẳng khác nào dùng các tổ hợp thư viện chưa được xác minh rồi hy vọng mọi thứ ổn, nhưng tôi không nghĩ điều đó sẽ xảy ra.
Từ lâu, firmware công khai lấy từ kho linux-firmware đã không được build từ mã nguồn mà chỉ phân phối dạng nhị phân, và chắc trong archive cũng còn những trường hợp tương tự.
Debian cũng không loại bỏ một cách có hệ thống các file được sinh ra khỏi mọi tarball rồi tái tạo lại chúng; đặc biệt ở mảng AI/ML, thậm chí có thể không lấy được dữ liệu huấn luyện, và chi phí huấn luyện cũng khó gánh nổi.
https://wiki.debian.org/EmbeddedCopies
Một số tổ chức phần mềm nguồn mở không chỉ đơn giản là hơi ấn tượng, mà còn đáng kinh ngạc đến mức cho thấy cách con người cộng tác có thể vượt trội hơn hẳn mô hình doanh nghiệp điển hình.
Tôi đã dùng Debian từ rất lâu nhưng không biết nhiều về tổ chức này, và bài viết này là một phần giới thiệu hay.
IETF cũng là tổ chức gần như đã tạo ra Internet, nhưng lại không có thành viên và cứ thế vận hành; thật ngạc nhiên là những tổ chức như vậy không được biết đến nhiều.
Cuộc chiến giao thức, khi thế giới doanh nghiệp cạnh tranh với IETF để giành quyền kiểm soát cách Internet vận hành, cũng rất thú vị: https://en.wikipedia.org/wiki/Protocol_Wars
Đã có thời OSI hằng tháng công bố dự án thay thế một phần Internet như TCP bằng các giao thức X., nhưng thứ sống sót và phát triển mạnh có lẽ chỉ là X.509.
Tôi tự hỏi liệu những tổ chức cộng tác dân chủ như vậy có thực sự vượt trội hơn nhiều so với mô hình doanh nghiệp truyền thống hay không.
Nếu nhìn theo quy mô kinh tế, doanh thu của IETF hay Debian không thể so với doanh nghiệp, nhưng từ góc nhìn của người đóng góp và người sáng tạo thì câu hỏi sẽ là “ai được lợi?”, và những người đóng góp thì chỉ cầm cự qua ngày.
Mô hình kiểu IETF hay Debian có vẻ đáng để thử nghiệm xem có thể cạnh tranh với mô hình doanh nghiệp hay không, và trong cuộc chiến giao thức thì nó đã thực sự hiệu quả một lần.
Trong các nhóm làm việc của IETF có nhiều kỹ sư từ các nhà cung cấp doanh nghiệp muốn cộng tác vì tính tương tác liên thông, trong khi ISO gần với một tổ chức truyền thống do chính phủ dẫn dắt theo kiểu từ trên xuống hơn.
Tôi đã dùng Ubuntu khoảng 13 năm rồi chuyển sang Debian trong năm nay, và khá hài lòng.
Trước đây tôi từng nghĩ mô hình đóng gói theo kiểu cập nhật toàn cục không phải là cách vững chắc nhất về mặt kỹ thuật, vì khó biết chuyện gì đang xảy ra và đôi khi cũng có xung đột phiên bản.
Nhưng theo thời gian, tôi ngày càng đánh giá cao sự ổn định của Debian và thiện chí của dự án.
Đôi khi mục đích và mục tiêu của dự án quan trọng hơn sự ưu việt về kỹ thuật.
Tôi có bất mãn với một số lựa chọn kỹ thuật, như việc daemon tự động khởi động sau khi cài đặt, nhưng lợi ích từ tính nhất quán của toàn bộ gói và nâng cấp lớn hơn.
Apt cũng là một trình quản lý gói thực sự tuyệt vời.
Ngay ở trạng thái mặc định nó đã nhanh, và còn hỗ trợ cả các kịch bản khá khó như giữ hệ thống ở stable nhưng chỉ dùng phiên bản Nginx mới từ backports.
Tôi thích cảm giác có thể nhận tính năng mới chỉ cho một hai gói mình quan tâm, còn phần còn lại thì ổn định và nhàm chán.
Lý do chính là vì Debian dùng công nghệ nhàm chán, cũ nhưng hoạt động tốt, và tôi không còn phải thấy netplan, snapd, systemd-resolver nữa.
Trừ khi bạn lấy từ Sid hoặc làm những việc thú vị như nâng cấp libc6, nếu mọi thứ đều được cài bằng apt thì thường không nên thấy xung đột phiên bản.
LIW đã bỏ sót một phần lớn: Debian là tổ chức tình nguyện, nên không ai có thể ép tình nguyện viên làm việc mà họ không muốn làm.
Những người không bị ép buộc tạo nên một cấu trúc dân chủ lỏng lẻo và tuần hoàn để ra quyết định, và tính tự lực xuất phát từ việc sử dụng tài nguyên thận trọng có vẻ là cốt lõi của tổ chức.
Với tôi, xung đột đó đã vĩnh viễn thay đổi khái niệm “Debian là gì”, và nó tốt hay xấu thì còn tùy bạn nghe ai nói.
Ngay cả trong những tổ chức như thế này, nếu bạn không làm theo những gì người khác bảo thì hiển nhiên sẽ bị mời ra cửa.
Thỉnh thoảng tôi tưởng tượng mình có một khoản tiền lớn đến mức hoàn toàn không phải lo chuyện tiền bạc
Những lúc đó tôi luôn lên kế hoạch xem sẽ quyên góp cho dự án mã nguồn mở nào, và Debian lúc nào cũng nằm trong vài ứng viên đầu tiên
Giờ chỉ cần có tiền nữa thôi; dĩ nhiên trong lúc đó tôi vẫn đang quyên góp cho Debian
Như vậy vui hơn nhiều
Debian có thể rất tuyệt, nhưng có vấn đề về hỗ trợ driver, và dường như họ chỉ thừa nhận điều này một cách khá thụ động
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
“Chúng tôi thừa nhận rằng một số người dùng cần các chương trình không phù hợp với Debian Free Software Guidelines. Vì những phần mềm như vậy, chúng tôi đã tạo các khu vực contrib và non-free trong kho lưu trữ FTP.”
Một, hai năm trước tôi chạy Debian trên vài máy, nhưng khi có bản cập nhật WiFi thì nó bị tê liệt; sau khi xem xét rollback các kiểu, tôi chỉ đơn giản chuyển sang Ubuntu, thực ra là Kubuntu, thì mọi thứ chạy tốt và không còn vấn đề
Debian 12 thậm chí còn tạo hẳn kho non-free-firmware riêng để những người theo chủ nghĩa thuần túy phần mềm tự do có thể nhượng bộ ít nhất ở driver không tự do nhằm dùng được phần cứng
Nếu là hệ thống đã cài sẵn, chỉ cần bật kho non-free rồi cài linux-firmware, hoặc gói firmware-* cụ thể hơn phù hợp với phần cứng, là có thể giải quyết được
Tôi từng làm việc cùng Ian Murdock ở Purdue vào thời bản phát hành đầu tiên
Anh ấy là quản trị viên hệ thống kiêm lập trình viên, còn tôi là nhà thiết kế web của thư viện
Anh ấy thật sự tin vào cách làm GNU/Linux và phần mềm “tự do như tự do ngôn luận”
Động lực ban đầu đến từ sự khó khăn của việc đóng gói và quản lý gói, và có lẽ đó là đóng góp lớn nhất của anh ấy
Anh ấy cũng rất nhiệt huyết với một ý tưởng giống hạ tầng P2P tên là Network-of-Workstations, tức NOW, nhưng nó chưa bao giờ thật sự bám rễ
Bruce Perens, người được anh ấy chuyển giao, chính là kiểu lãnh đạo độc đoán mà bài viết nói đến
Tôi quý ông ấy; đó là phong cách quản lý kiểu cựu trào giống Linus Torvalds, và trong một dự án lớn, phức tạp, có nhiều tình nguyện viên, phong cách đó lại hiệu quả
Thời Linux và Debian ngày xưa thật sự rất vui; tôi không dấn sâu như những người khác, nhưng tôi nhớ thời đó
Ngày nay có quá nhiều người mang mùi tiền bước vào, mà đời là vậy
Tuyên ngôn của Ian giải thích tất cả: https://www.debian.org/doc/manuals/project-history/manifesto...
Tôi chưa từng nghe câu chuyện đó, Google cũng không giúp được gì
Hành trình của ông ấy sau khi rời vị trí cho đến khi qua đời trông khá bất ổn
Nó còn cũ hơn cả tôi
Debian giống Toyota
Đáng tin cậy nhưng nhàm chán, hơn nữa lại do các tình nguyện viên làm ra
Vì chính sách của Debian, đôi khi người dùng nhận được một phiên bản RetroArch bị hạn chế nhiều chứ không phải phiên bản thực sự
RetroArch có chức năng quản lý gói riêng gọi là “Core Updater”, dùng để tải xuống và cài đặt các trình giả lập dưới dạng file thư viện, nhưng Debian cấm chức năng này vì cho rằng nó đi vòng qua toàn bộ hệ thống quản lý gói
Tuy nhiên, nếu cài các phụ thuộc của gói nguồn Debian rồi build từ mã nguồn gốc, bạn có thể tự build RetroArch với đầy đủ tính năng
Tôi đã học được điều đó một cách vất vả khi cố chạy Kodi và RetroArch, nhưng ngoài chuyện đó ra thì đây là một hệ điều hành tuyệt vời
Cá nhân tôi thích và dùng Debian vì các nguyên tắc và tính ổn định của nó
Tôi từng nghe người dùng các bản phân phối khác hoặc một số dự án upstream phàn nàn rằng Debian “chỉnh sửa” các gói
Tôi muốn biết điều đó có thật không, và nếu có thì hẳn phải có lý do chính đáng, nên muốn được nghe giải thích
Thứ nhất là các bản vá khiến phần mềm hoạt động theo cách Debian mong muốn: cấu hình được lưu trong /etc/, không tải thêm trong lúc chạy, và dùng thư viện hệ thống thay vì thư viện được bundle
Thứ hai là backport bảo mật
Debian đóng băng tính năng tại thời điểm phát hành và chỉ cung cấp cập nhật bảo mật, nhưng ngày nay nhiều phần mềm gộp cả bản sửa bảo mật vào các bản phát hành mới cùng với tính năng mới
Khi hai loại này cộng lại, khác biệt giữa 1.2 của Debian và 1.2 “thật” sẽ lớn hơn, khiến việc xử lý báo cáo lỗi trở nên khó khăn
Ví dụ, họ nhận báo cáo lỗi cho 1.2-Debian, nhưng dự án upstream chỉ hỗ trợ 1.4 “thật” cùng với một bộ thư viện đã được cập nhật
Thứ ba là cách hiện nay đã giảm đi nhiều: Debian vá khi cho rằng có thể cải thiện phần mềm
Điều này từng gây ra những vấn đề như loại bỏ tính ngẫu nhiên khỏi khóa SSH: https://github.com/g0tmi1k/debian-ssh
Một là kiểu phiên bản tăng dần, như Chrome, gần như không có bản phát hành chỉ sửa lỗi riêng, mà bản sửa lỗi được đưa vào phiên bản mới
Kiểu còn lại là xoay quanh phiên bản chính, như quản lý phiên bản ngữ nghĩa: có phiên bản 1 và 2, và ngay cả sau phiên bản 2 vẫn có 1.1 chỉ áp dụng bản sửa lỗi cho phiên bản 1
Về cơ bản Debian chỉ hoạt động tốt với kiểu thứ hai
Vì duy trì tính ổn định API, nó không phù hợp với phần mềm được phát triển theo kiểu thứ nhất
Để lách qua điều này, Debian backport “bản sửa” của phiên bản 3 về phiên bản 1 và tạo ra 1.debian-2 của riêng mình
Vấn đề là lúc này dự án upstream sẽ nhận lỗi về một hành vi mà họ chưa từng phát hành
Debian có quyền tự do làm như vậy, nhưng dự án upstream cũng có quyền tự do không hài lòng với khối lượng công việc bổ sung mà Debian đẩy sang họ
Khi cần, họ vá những dự án upstream không đáp ứng kỳ vọng đó, và việc có thể làm như vậy chính là cốt lõi của phần mềm tự do
Xem https://www.debian.org/security/2008/dsa-1571 là rõ