Asterinas - dự án kernel mới tương thích Linux

 (lwn.net)
8 điểm bởi GN⁺ 2025-06-23 | 2 bình luận | Chia sẻ qua WhatsApp
  • Đây là kernel mới tương thích Linux ABI được viết bằng Rust, áp dụng kiến trúc "framekernel" nhằm kết hợp ưu điểm của monolithic kernel và microkernel
  • Bằng cách đóng gói toàn bộ mã unsafe داخل thư viện giới hạn, phần còn lại của các dịch vụ kernel có thể được phát triển bằng các trừu tượng Rust an toàn, qua đó đồng thời đạt được an toàn bộ nhớ và cấu trúc bộ nhớ chia sẻ đơn giản
  • Điểm khác biệt so với các Rust OS hiện có như RedLeaf, Tock, Rust for Linux là hỗ trợ cách ly phần cứng, mục đích sử dụng tổng quát, ABI tương thích Linux và khả năng chạy user space bằng nhiều ngôn ngữ
  • Dự án hướng tới giảm thiểu TCB (Trusted Computing Base) và kiểm chứng hình thức (sử dụng Verus), hỗ trợ phần cứng trusted execution environment như Intel TDX, đồng thời cũng cung cấp riêng framework phát triển OS như OSTD/OSDK
  • Hiện vẫn đang ở giai đoạn phát triển ban đầu, hỗ trợ x86/RISC-V và đã triển khai 206 system call, tập trung vào Docker/container/môi trường cloud nhưng cũng đang thử nghiệm mở rộng desktop như X11/Xfce

Asterinas là gì?

  • Asterinas là một dự án kernel mới tương thích Linux ABI được phát triển bằng Rust
  • Kiến trúc "framekernel" được thiết kế để giới hạn mã Rust unsafe (vùng không an toàn về bộ nhớ) trong thư viện framework và bọc chúng bằng API an toàn, còn toàn bộ dịch vụ kernel còn lại được phát triển bằng Rust an toàn
  • Dự án đồng thời theo đuổi cấu trúc đơn giản/hiệu năng cao của monolithic kernel và giảm thiểu TCB (Trusted Computing Base)/độ an toàn của microkernel
  • Các dịch vụ bên trong kernel hoạt động tách biệt trong cùng một không gian địa chỉ, và mỗi dịch vụ chỉ có thể sử dụng các tài nguyên được cấp từ thư viện core

Giải thích kiến trúc framekernel

  • Khái niệm framekernel lần đầu được đề xuất trong bài báo "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation"
  • Monolithic kernel là cấu trúc đưa toàn bộ mã vào một không gian địa chỉ ở kernel mode, còn microkernel chỉ cấp không gian kernel cho TCB tối thiểu và giao phần lớn chức năng cho các dịch vụ ở user mode
  • Framekernel đóng gói phần mã cần dùng tính năng unsafe của Rust thành thư viện, còn các dịch vụ kernel còn lại được phát triển bằng các trừu tượng Rust an toàn bộ nhớ
  • Mỗi dịch vụ chạy trong không gian địa chỉ kernel nhưng bị giới hạn chỉ được truy cập những tài nguyên mà thư viện cung cấp một cách tường minh
  • Giữ TCB nhỏ sẽ giúp kiểm chứng hình thức (chứng minh toán học) trở nên khả thi hơn, từ đó nâng cao độ tin cậy và tính ổn định của toàn hệ thống
  • Đây là cách tiếp cận kết hợp nền tảng bộ nhớ chia sẻ (hiệu năng cao như monolithic kernel) với phân tách đặc quyền nội bộ/tính bảo mật (ưu điểm của microkernel)

So sánh với các Rust OS hiện có và framekernel

  • RedLeaf: microkernel dựa trên Rust, không sử dụng cách ly phần cứng
  • Asterinas: OS mục đích tổng quát, tận dụng cách ly phần cứng, tương thích Linux ABI, hỗ trợ chạy user space bằng nhiều ngôn ngữ
  • Tock: nhắm tới SoC nhúng, có cấu trúc tách lõi (cho phép unsafe) và capsule (mã an toàn), không hỗ trợ cách ly phần cứng
  • Dự án Rust for Linux cũng nhằm bọc giao diện kernel bằng các trừu tượng an toàn để có thể viết kernel driver bằng Rust một cách an toàn

Kiểm chứng hình thức và bảo mật

  • Mục đích chính của việc giảm TCB là để kiểm chứng hình thức (formal verification) trở nên khả thi trong thực tế
  • Asterinas là trường hợp duy nhất hiện nhắm tới đồng thời TCB nhỏ và có thể kiểm chứng như seL4, tương thích Linux ABI và cấu trúc bộ nhớ chia sẻ
  • Dự án đang hợp tác với công ty chuyên audit bảo mật CertiK để thực hiện kiểm chứng hình thức dựa trên Verus
    • Báo cáo đánh giá bảo mật của CertiK công khai các điểm audit và các vấn đề được phát hiện trong dự án

Thư viện và công cụ phát triển

  • Ngoài chính kernel, dự án còn cung cấp OSTD (framework OS bằng Rust) và OSDK (công cụ phát triển dựa trên Cargo)
  • Mục tiêu chính của OSTD:
    • Giảm rào cản gia nhập trong phát triển OS và tạo nền tảng cho đổi mới
    • Tăng cường an toàn bộ nhớ cho hệ điều hành Rust và trừu tượng hóa API mức thấp
    • Thúc đẩy tái sử dụng mã giữa các dự án Rust OS
    • Cho phép kiểm thử mã mới ở user mode (tăng năng suất phát triển)
  • Kernel dựa trên OSD và OSTD không nhất thiết phải tương thích Linux, và cung cấp các API mức cao an toàn bộ nhớ cho điều khiển phần cứng x86, bộ nhớ ảo, đa xử lý (SMP), timer, v.v.
  • Intel tham gia với vai trò nhà tài trợ, đặc biệt phù hợp với Trust Domain Extensions (TDX) và các công nghệ liên quan đến cách ly máy ảo

Tình hình phát triển và các nhà tài trợ chính

  • Được công bố lần đầu dưới dạng mã nguồn mở (giấy phép MPL) vào đầu năm 2024, hiện có 45 người đóng góp; các contributor chính là nghiên cứu sinh từ SUSTech, Đại học Bắc Kinh, Đại học Fudan của Trung Quốc và Ant Group
  • Hỗ trợ x86, RISC-V, đã triển khai 206 system call Linux (trong tổng số 368)
  • Hiện vẫn chưa thể chạy ứng dụng, đang hướng tới phát triển bản phân phối ban đầu và hỗ trợ container (Docker), đồng thời thử nghiệm phân phối dựa trên Nix
  • Không hỗ trợ tải Linux kernel module và cũng không có kế hoạch bổ sung vĩnh viễn

Kế hoạch sắp tới

  • Nhiệm vụ ưu tiên ngắn hạn là mở rộng nhiều kiến trúc CPU hơn, mở rộng hỗ trợ phần cứng và tính khả dụng thực tế trong môi trường cloud
  • Đã hoàn tất hỗ trợ thiết bị Linux virtio, và nhắm tới thị trường cloud Trung Quốc (Alibaba Cloud, Aliyun) là mục tiêu chính
  • Mục tiêu trọng tâm là phát triển host OS cho container với TCB an toàn và được tinh gọn, đồng thời hỗ trợ các tính năng trusted computing của Intel
  • Dù có mục tiêu tương tự Rust for Linux, Rust for Linux chỉ giới hạn ở việc Rust hóa driver trong kernel hiện có, trong khi Asterinas theo đuổi thiết kế mới toàn bộ kernel và giảm thiểu TCB
  • Hiện dự án cũng đang thử nghiệm theo nhiều hướng khác nhau như hỗ trợ X11, Xfce, và bản thân OSTD cũng có tiềm năng thu hút sự chú ý từ các nhà phát triển OS nói chung

Khác biệt với Rust for Linux

  • Rust for Linux: chỉ đưa driver an toàn viết bằng Rust vào kernel Linux hiện có, còn toàn bộ kernel vẫn dựa trên C
  • Asterinas: triển khai một kernel mới hoàn toàn bằng Rust từ đầu, giới hạn nghiêm ngặt unsafe, thúc đẩy kiểm chứng hình thức, tập trung vào môi trường cloud/container

Tổng hợp và triển vọng

  • Asterinas đang thử nghiệm một cách tiếp cận đổi mới về an toàn bộ nhớ, kiểm chứng hình thức và tính thực dụng trong môi trường cloud
  • Hiện vẫn chưa có ví dụ triển khai thực tế hay sự kiểm chứng rộng rãi từ cộng đồng, nhưng đang thu hút sự quan tâm trong các lĩnh vực nghiên cứu OS, cloud và bảo mật
  • Framework OSTD cùng các thành phần liên quan có tiềm năng được sử dụng trong hệ sinh thái phát triển Rust OS trong tương lai

Tóm tắt các điểm chính trong phần bình luận LWN về Asterinas

  • Tranh luận về Singularity OS và ranh giới bảo mật dựa trên ngôn ngữ
    • Framekernel của Asterinas tương tự Singularity OS của Microsoft, nhưng tận dụng borrow checker của Rust để tăng cường an toàn bộ nhớ
    • Với cách tiếp cận dùng bản thân ngôn ngữ (ví dụ: Rust, Java, WASM/JS) làm ranh giới bảo mật để bảo vệ hệ thống, có ý kiến phê phán rằng "không thể tin tưởng hoàn toàn và trên thực tế vẫn phải dùng song song với sandbox ở cấp phần cứng/OS", đối lập với ý kiến cho rằng "nó có ưu điểm trong việc ngăn lỗi và kiểm chứng hình thức"
    • WASM, JS, Java cũng có tranh cãi về bảo mật, nhưng trong dịch vụ thực tế, chỉ sandbox ở cấp ngôn ngữ thì không được tin cậy hoàn toàn; thông thường vẫn phải kết hợp với sandbox phần cứng hoặc OS
  • Xu hướng phát triển hệ điều hành và bối cảnh địa chính trị
    • Trong vài năm gần đây đã xuất hiện nhiều dự án OS mới, cho thấy bầu không khí đổi mới trong lĩnh vực OS đang lan rộng
    • Trung Quốc đang đẩy nhanh phát triển OS thay thế Linux để đối phó với các lệnh hạn chế công nghệ của Mỹ và rủi ro chuỗi cung ứng
    • Các tranh luận chính trị xoay quanh lệnh trừng phạt của Mỹ, GPL và quản trị toàn cầu của mã nguồn mở, cũng như quan điểm cho rằng Trung Quốc, châu Âu và các khu vực khác cần theo đuổi hệ sinh thái công nghệ độc lập, diễn ra rất gay gắt
    • Độ khó của việc duy trì một bản fork từ Linux so với phát triển kernel hoàn toàn mới, sự phụ thuộc vào tri thức/kinh nghiệm cộng đồng và rào cản ngôn ngữ cũng là chủ đề tranh luận
  • Tranh luận về tương thích Linux/số lượng system call
    • Nhiều ý kiến cho rằng đo mức độ tương thích bằng số lượng system call Linux là không phù hợp
    • Một system call đơn lẻ (như ioctl) có thể bao hàm rất nhiều API chi tiết, vì vậy để đánh giá tương thích thực chất thì việc chạy được ứng dụng thực tế và các kernel test suite mới quan trọng
    • Cũng có ý kiến thực tế rằng trong giai đoạn đầu Linux đã phát triển bằng cách triển khai từng syscall một để đạt tương thích POSIX, và chỉ cần hỗ trợ 99% các syscall quan trọng cũng có thể chạy được khá nhiều phần mềm
  • Giấy phép và hệ sinh thái Rust
    • Có thảo luận về việc Asterinas chọn MPL: một số ý kiến tích cực cho rằng MPL rất phù hợp với hệ sinh thái crate của Rust và mô hình giấy phép theo module
    • Cũng có góc nhìn cho rằng GPL không phải lúc nào cũng tối ưu, và nếu nhận tài trợ từ doanh nghiệp thì có thể chọn giấy phép thân thiện hơn với doanh nghiệp như MPL
  • Phụ thuộc dự án/bảo mật
    • Có nghi vấn về việc sử dụng nhiều crate bên ngoài trong OS viết bằng Rust có an toàn hay không, và cần tự động hóa audit/bảo mật chuỗi cung ứng qua cargo deny/vet
    • Cũng có nhận xét rằng chỉ từ lockfile thì khó nắm được toàn bộ bề mặt phụ thuộc, và hệ sinh thái Rust có thêm độ phức tạp như phụ thuộc bắc cầu, phụ thuộc theo từng OS, v.v.
  • Nguồn cảm hứng kỹ thuật/kiến trúc tương tự
    • Có ý kiến chỉ ra rằng khái niệm framekernel tương tự kiến trúc SPIN OS của University of Washington trong thập niên 90
    • SPIN cũng nhấn mạnh tính mô-đun mạnh và kiểm soát giao diện/truy cập bởi compiler
  • Tranh cãi về thành phần committer
    • Có nhắc đến việc trong số 45 contributor, nhiều commit tập trung vào một số ít nghiên cứu sinh
    • Cũng có ý kiến phản bác sự hiểu lầm rằng đóng góp do nghiên cứu sinh dẫn dắt thì giá trị thấp với tư cách committer, cho rằng dự án vẫn có ý nghĩa như một sáng kiến đổi mới mang tính nghiên cứu
  • Tranh luận chính trị/lịch sử và chỉ ra tính off-topic
    • Thảo luận về OS đã lan sang tranh luận địa chính trị/chính trị/lịch sử giữa Mỹ, châu Âu và Trung Quốc, khiến biên tập viên nhiều lần phải cảnh báo là "off-topic"
    • Một số người dùng nhấn mạnh rằng hệ sinh thái mã nguồn mở/FOSS cũng có thể bị ảnh hưởng bởi thay đổi trong môi trường địa chính trị
  • Khác
    • Có chia sẻ các bài báo học thuật về bảo mật WASM
    • Các góc nhìn tích cực và phê phán về tình hình phát triển kernel cùng tồn tại

Bài viết liên quan

2 bình luận

 
eususu 2025-06-24

Mình rất thích những nỗ lực thử nghiệm như thế này.
Biết đâu chẳng bao lâu nữa sẽ xuất hiện một kernel không chết.
 
GN⁺ 2025-06-23
Ý kiến trên Hacker News

  • Tôi thấy đây là một cách tiếp cận thú vị và hy vọng nó thành công. Nhưng tôi vẫn còn hoài nghi. Tôi vẫn nhớ điều Linus từng nói về đối thủ trong một cuộc phỏng vấn TV vào cuối thập niên 90 hoặc đầu những năm 2000. Linus từng nói đại ý rằng “không ai thích viết driver cả, nên vẫn an toàn cho đến khi có một người trẻ, đầy khát vọng xuất hiện như một kỹ sư driver xuất sắc”. Ngay từ thời điểm đó ông ấy dường như đã nhận thức rằng việc giữ giao diện driver không ổn định là một biện pháp phòng thủ. Sau 25 năm, kernel chạy trên phần cứng ảo hóa đã trở nên rất phổ biến, nhưng số hệ điều hành thực sự hữu dụng, chạy được trên phần cứng thật và trừu tượng hóa thành công phần cứng đó, vẫn chỉ đếm trên đầu ngón tay

    • Về ý “giữ giao diện driver không ổn định là một biện pháp phòng thủ”, tôi nghĩ trong tương lai có thể sẽ xuất hiện những nhà nghiên cứu hệ thống trẻ đầy tham vọng hoặc AI, và một hướng khả thi là AI agent dịch driver Linux viết bằng C sang driver Asterinas viết bằng Rust an toàn. Một cách tiếp cận thực tế khác là tái sử dụng chính Linux kernel bằng cách đặt nó trong một môi trường cô lập nào đó. Ví dụ, kernel HongMeng tái sử dụng driver bằng User-Mode Linux. Asterinas cũng có thể áp dụng chiến lược tương tự. Tham khảo: https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • Tôi nghi ngờ việc Linus thực sự muốn hay cố tình dựng “hàng rào phòng thủ”. Ông ấy không phải nhà sáng lập startup công nghệ, vốn chỉ là một kernel hacker, và từ lâu đã có nền tảng bảo đảm cuộc sống cả đời. Cách diễn giải rằng sự bất ổn định của giao diện driver trong kernel là một chiến lược có chủ ý để ngăn cạnh tranh có vẻ là sự suy diễn quá mức

    • Trước đây cũng đã có các tiền lệ như SPIN OS (Modula 3), JX OS (Java), House OS (Haskell), Verve. Tất cả đều dùng ngôn ngữ type-safe và memory-safe để hiện thực chức năng kernel. Nhìn chung, chúng có cấu trúc giấu phần nguy hiểm phía sau các lời gọi hàm đã được kiểm tra, một số còn dùng VM. Bỏ qua vấn đề hiệu năng hay mức độ chấp nhận, điểm yếu chính là các lỗ hổng trong lớp trừu tượng, việc lách qua mã unsafe, sự sụp đổ của mô hình an toàn do compiler/JIT, và các lỗi phần cứng nói chung như cosmic ray trong tàu vũ trụ. Dù vậy, chúng vẫn an toàn hơn rất nhiều so với kernel/app viết bằng ngôn ngữ unsafe. Để tiến xa hơn, có thể dùng phân tích tĩnh cho mã unsafe, bảo đảm mọi hàm unsafe đều tuân thủ giao diện type-safe và memory-safe, dùng compiler bảo toàn tính an toàn của lớp trừu tượng khi tích hợp, và cả compiler được chứng minh cho từng thành phần. Hầu hết công cụ năng suất đều đã tồn tại; chỉ còn thiếu “biên dịch trừu tượng hóa hoàn toàn an toàn”, hiện vẫn đang được nghiên cứu, dù kiểm tra thủ công cũng có thể làm được

    • Có lý do khiến số hệ điều hành thực sự dùng được lại ít đến vậy. Thế giới phần cứng đầy rẫy các “chuẩn” giao diện, nhưng phần cứng thực tế hiếm khi vận hành đúng theo chuẩn. Nếu không có thời gian viết mã trong driver để xử lý đủ loại dị biệt và lỗi không thể sửa được (errata), thì việc đạt được hiệu năng và mức hỗ trợ tốt trên phần cứng vật lý là cực kỳ khó

    • Mặt khác, thực tế 98% Linux mà tôi dùng đều chạy trong môi trường ảo hóa. Trên desktop/laptop, tôi chạy VirtualBox toàn màn hình và chỉ dùng driver cho Windows khi thực sự cần; trên Mac thì là VM headless do Docker.app quản lý. Toàn bộ workload vận hành ở công ty đều chạy trên AWS VM. Phần cứng Linux duy nhất tôi dùng ở nhà cũng chỉ là home server, và tôi định sớm thay nó bằng một Mac mini VM mua trên eBay. Nếu có một kernel tương thích Linux nhưng bảo mật hơn và hiệu năng tương đương, thì ngày nay dù thiếu driver, việc chọn giải pháp thay thế vẫn khá dễ

  • Gần đây tôi nghe nói microkernel đã cải thiện rất nhiều vấn đề hiệu năng IPC. Tôi không nhớ chính xác đã cải thiện đến mức nào, nhưng có vẻ chấn thương tâm lý mà Mach để lại cho ngành là rất lớn. Nhìn vào trang dự án thì cấu trúc lại là chỉ Framework (chế độ đặc quyền) mới được dùng unsafe của Rust, còn Services (không đặc quyền) thì chỉ dùng Rust an toàn. Cảm giác có gì đó hơi lạ: nếu mã không đặc quyền mà unsafe thì chẳng phải vẫn nguy hiểm sao, dù nó không đặc quyền? Trong khi đó phía thực sự cần kiểm chứng vì dùng unsafe lại được phép dùng không giới hạn? Và nhìn giấy phép thì Asterinas chủ yếu dùng Mozilla Public License (MPL) 2.0, một số thành phần dùng giấy phép dễ dãi hơn. Không phải GPL, cũng không phải BSD, cảm giác như ở giữa

    • Với câu hỏi “mã không đặc quyền mà unsafe vẫn nguy hiểm, còn mã thật sự cần kiểm chứng thì lại dồn hết về phía đặc quyền nghe có vẻ lạ”, cấu trúc này cần được hiểu trong bối cảnh framekernel. Toàn bộ framekernel dựa trên Rust chạy trong kernel space, nhưng về mặt logic được chia thành hai phần: framework hệ điều hành đặc quyền và các dịch vụ hệ điều hành không đặc quyền. Phần đặc quyền bao gồm cả mã kernel Rust safe lẫn unsafe; phần không đặc quyền chỉ bao gồm mã kernel Rust safe. Chính sách này đều áp dụng cho mã kernel. Trong framekernel, ngôn ngữ của chương trình người dùng không bị ràng buộc

    • Tôi hiểu là hầu hết microkernel gần đây đã cải thiện hiệu năng IPC rất mạnh. Điển hình như SeL4 tối ưu IPC cực kỳ quyết liệt, đến mức IPC của nó còn nhanh hơn nhiều syscall thông thường của Linux. Phần lớn chương trình có lẽ thậm chí còn chạy nhanh hơn trên Sel4. Tôi khá muốn xem dữ liệu so sánh hiệu năng thực tế

    • Đúng là các microkernel hiện đại đã cải thiện vấn đề IPC. Thực ra vấn đề sâu xa hơn là trên phần cứng hiện đại, ngay cả syscall của monolithic kernel cũng rất chậm. Vì thế những giao diện như io_uring hay virtio có hiệu năng tốt là vì chúng xử lý request và response bằng hàng đợi giữa hệ thống và ứng dụng (hoặc giữa hypervisor và guest), tránh phải chuyển đổi address space. Hệ điều hành tương lai, bất kể cấu trúc nào, đều sẽ cần cơ chế syscall dựa trên “queueing”. Và khi đã chọn cách này thì hiệu năng sẽ không khác biệt lớn dù OS là monolithic, microkernel hay kiểu khác

    • Trong framekernel, sự phân tách privileged/unprivileged không mang nghĩa kernel/userspace. Toàn bộ OS đều chạy ở mức đặc quyền của kernel. Chỉ là về mặt logic, nó được chia thành mã thư viện lõi (được phép dùng unsafe, privileged) và phần còn lại của mã thành phần kernel (dùng thư viện đó, không được trực tiếp dùng unsafe, unprivileged). Có lẽ điều này được cưỡng chế bằng linter hoặc các kiểm tra tĩnh tương tự. Cấu trúc này dễ gây nhầm lẫn vì dùng trùng thuật ngữ

    • Task không đặc quyền cũng chạy trong cùng không gian bộ nhớ với lõi kernel, nên không có cách nào chặn hành vi không an toàn ở runtime. Muốn tách đặc quyền ở runtime thực sự thì cần kiến trúc microkernel. Ở đây, đặc quyền được hiện thực theo kiểu tĩnh thay vì runtime, tức là bằng cách cấm mã unsafe

  • Tôi tò mò liệu ý tưởng tách kernel thành một lõi unsafe nhỏ và các module safe lớn có phải là một thử nghiệm mới không. Nó rất hấp dẫn và đáng kỳ vọng ở chỗ không có overhead phần cứng của microkernel, tránh được vấn đề an toàn của monolithic, đồng thời tận dụng rất tốt đặc tính phân tách safe/unsafe của ngôn ngữ hệ thống

  • Bài review về Rust in Linux của Drew DeVault làm tôi nhớ tới. Cũng có thể nối sang thảo luận HN này https://news.ycombinator.com/item?id=41404733

  • Tôi nghĩ đây thực sự là một nỗ lực tuyệt vời, và việc tác giả có mặt trong thread này cũng rất ấn tượng. Tôi tò mò không biết nó usable đến mức nào; tôi muốn thử build một server image để thử nghiệm, dù chỉ trong một số môi trường hạn chế

    • Asterinas vẫn là một kernel tương đối mới nên còn nhiều điểm cần mài giũa nếu muốn dùng phổ thông. Tuy nhiên, nếu mục tiêu là vận hành dịch vụ thực tế một cách hiệu quả và đáng tin cậy, thì khoảng cách đó không quá lớn và có khả năng đạt mục tiêu trong vòng một năm. Hiện tại họ đang triển khai các tính năng cốt lõi như Linux namespaces, cgroups, và cả bản phân phối đầu tiên dựa trên Asterinas. Mục tiêu ban đầu là dùng Asterinas làm guest OS cho Confidential VMs, nơi tính an toàn bộ nhớ và TCB nhỏ mang lại lợi thế bảo mật rõ rệt so với Linux

  • Khi thấy người ta giải thích rằng microkernel IPC chậm nên ít được ưa chuộng, tôi thấy yên tâm hơn vì ngay cả những người rất giỏi về kỹ thuật cũng có thể hiểu sai về lý do chấp nhận thực tế và quá trình dẫn tới điều đó

    • Vậy thì nên chỉ ra chính xác họ đang hiểu sai ở điểm nào để mọi người cùng có ích hơn

  • Giấy phép là MPL, cá nhân tôi nghĩ vẫn có những giấy phép tốt hơn như GPLv3

    • Tài liệu có giải thích trực tiếp lý do chọn MPL. Không phải lựa chọn tôi thích nhất, nhưng lý do thì có thể hiểu được

  • Tôi thấy đây là một ý tưởng rất ổn. Đã có rất nhiều phần mềm được xây dựng rồi, và có một nền tảng thay thế có thể mang lại lợi ích hoặc lựa chọn lớn ngay cả vì những lý do ngoài kỹ thuật. Nó làm tôi nhớ đến kFreeBSD và GNU/Hurd

  • Tôi đang băn khoăn không biết nên gọi những kernel kiểu này là gì. *nux?