Darling Q4/2026: chính sách AI, hỗ trợ ARM64

Dự án Darling - lớp tương thích (compatibility layer) cho phép chạy các ứng dụng macOS trên Linux - vừa công bố bản cập nhật phát triển quý 4/2026. Thay vì một tính năng mới, thay đổi lớn nhất năm nay lại là một chính sách: các quy định về đóng góp có sự hỗ trợ của AI.

Đi kèm là bước tiến kỹ thuật đầu tiên về ARM64, kiến trúc chủ đạo của phần cứng Apple hiện nay. Cả hai thay đổi cùng hướng tới một mục tiêu: giúp một nhóm nhỏ tình nguyện viên có thể theo kịp tốc độ phát triển của Apple.

Vì sao AI trở thành bước ngoặt

Tác giả dự án, người khởi tạo Darling từ năm 2012, thẳng thắn nhìn nhận thực tế: Apple là một công ty khổng lồ với nhiều kỹ sư liên tục tung ra tính năng mới, trong khi nhóm tình nguyện nhỏ không thể so được về năng lực. Cho đến gần đây, rất ít ứng dụng macOS thực tế chạy được trên Darling.

Darling cũng chưa bao giờ có lợi thế như Wine - lớp tương thích dành cho ứng dụng Windows. Bề mặt ứng dụng macOS nhỏ hơn nhiều so với Windows, nên ít người quan tâm chạy chúng trên Linux, và càng ít lập trình viên hiểu sâu nội bộ macOS để đóng góp. Điều này khiến việc thu hút cộng tác viên lẫn các nguồn tài trợ thương mại kiểu Valve dành cho Wine đều rất khó.

Quy mô nền tảng cũng là vấn đề. Apple liên tục thêm các framework chỉ đi kèm macOS: theo một thống kê, macOS 27 chứa 464 framework công khai và 2.754 framework riêng tư, tăng từ 273 và 878 ở macOS 10.14. Wine có thể dựa vào các runtime phân phối lại của Microsoft mà các công cụ như winetricks tải về giúp người dùng, còn với hầu hết framework của Apple thì không có gì để tải - nhóm phải tự hiện thực từng cái một.

Năm nay, điều đó đã thay đổi. Một số bản fork sử dụng nhiều AI đã đạt kết quả ấn tượng.

Trong số đó, một bản fork chạy được League of Legends là ví dụ dễ thấy nhất. Bản fork VibeDarling cũng đã đưa nhiều ứng dụng macOS gốc vào hoạt động.

Theo tác giả, từ chối AI sẽ dẫn đến hai hệ quả: Darling trở nên không còn đáng kể khi các bản fork tiến rất nhanh, và cộng đồng có nguy cơ phân mảnh khi mọi người chuyển sang nơi có tiến triển.

Chính sách AI: quyền lực đi kèm trách nhiệm

Chính sách mới được viết dưới dạng chỉ dẫn cho các AI agent (tác nhân AI), nhưng ràng buộc chính con người sử dụng chúng. Người mở pull request chịu trách nhiệm cho từng dòng code và phải giải thích được bằng lời của mình; câu hỏi của maintainer do người thật trả lời, không phải bot.

Phần còn lại mã hóa các quy tắc clean-room (phòng sạch - phát triển độc lập không dùng tài liệu độc quyền):

• Hiện thực theo hợp đồng đã được tài liệu hóa, thay vì dùng mẹo vá riêng cho một ứng dụng
• Tôn trọng cách phân lớp của macOS
• Cô lập và gắn nhãn các hành vi không được tài liệu hóa (quirk)
• Không bao giờ dùng tài liệu rò rỉ hay mã nguồn hạn chế của Apple như corecrypto
• Không dùng disassembly (dịch ngược mã máy) để tạo ra code trùng khớp

Chính sách cũng nêu rõ: tùy luật địa phương, có thể chấp nhận việc dùng disassembly để ghi lại cách một thứ hoạt động rồi tái hiện theo kiểu clean-room - agent viết code không bao giờ thấy disassembly, mà chỉ thấy bản mô tả hành vi được tạo ra trong một ngữ cảnh riêng.

Darling có hỗ trợ ARM64 ban đầu

Darling giờ đã có hỗ trợ ARM64 ban đầu. Điều này quan trọng vì ARM64 là kiến trúc chủ đạo của phần cứng Apple hiện tại: từ khi Apple chuyển sang chip tự phát triển, mọi chiếc Mac mới đều dựa trên ARM64, và phần mềm viết cho macOS ngày nay ngày càng nhắm tới nền tảng này trước tiên hoặc duy nhất. Thiếu ARM64, Darling sẽ bị giới hạn ở một kiến trúc mà chính Apple đang rời bỏ.

Một lý do nữa khiến nhóm tự tin: bản fork VibeDarling được phát triển trên ARM64, nên công việc hàng ngày của nó liên tục kiểm tra các đường code ARM64. Khi fork được gộp trở lại Darling gốc, họ kỳ vọng sẽ có hỗ trợ tốt cho kiến trúc này ngay từ đầu.

Kế hoạch phía trước

Hai tháng tới, mục tiêu ngắn hạn là gộp côngviệc từ tất cả các fork trở lại Darling. Nhóm đang dùng logic gộp do agent điều khiển, đến nay đã tự động sửa được nhiều lỗi, cả trong code từ các fork lẫn lỗi có sẵn trong Darling. Dự án dự kiến chính thức hỗ trợ ba kiến trúc: i386, x86-64 và ARM64 (aarch64).

Riêng tác giả đang chậm rãi thử chạy ứng dụng ARM64 trên máy x86-64 bằng cách tái sử dụng Dynarmic - một trình biên dịch động (JIT) cho ARM. Đây là việc khó, nhiều rủi ro, nên tác giả không khuyến khích đặt kỳ vọng vào nó.

Về dài hạn, kế hoạch cá nhân của tác giả là ổn định hỗ trợ AppKit và làm cho giao diện trông đẹp hơn, cùng việc đưa một số ứng dụng cụ thể vào hoạt động - nhất là các ứng dụng mã nguồn mở, vì agent có cơ hội tốt hơn để tìm ra ứng dụng mong đợi gì từ hệ thống. Dự án cũng muốn thêm chính các ứng dụng GUI vào Darling, như tiện ích cấu hình và trình xem log theo tinh thần Console.app của macOS; chúng vừa là công cụ quản lý thực tế, vừa là bài kiểm tra thực tế cho hỗ trợ AppKit.

Dự án kêu gọi người muốn đóng góp - kể cả những sửa lỗi nhỏ - trao đổi trên Discord, đọc kỹ chính sách AI trước, và có thể hỗ trợ tài chính qua OpenCollective để trang trải hạ tầng, lưu trữ và có thể cả chi phí LLM.

Góc nhìn

Với các lập trình viên Việt Nam quan tâm đến cross-platform, câu chuyện của Darling đáng chú ý ở chỗ nó cho thấy AI đang thay đổi cách các dự án mã nguồn mở nhỏ đối phó với những nền tảng đóng, quy mô lớn. Thay vì bỏ cuộc trước khối lượng framework khổng lồ của Apple, nhóm chọn dùng LLM như một công cụ tăng năng suất - nhưng đặt trách nhiệm giải trình lên con người.

Cách xây dựng chính sách ở đây cũng là mẫu tham khảo thực tế: quy định rõ ai chịu trách nhiệm từng dòng code, cấm dùng tài liệu rò rỉ và mã hạn chế, và định nghĩa rạch ròi giữa disassembly để tìm hiểu hành vi với việc sao chép code. Những dự án hoặc doanh nghiệp Việt Nam muốn đưa AI vào quy trình phát triển có thể học cách phân tách như vậy để giảm rủi ro pháp lý.