Lập luận phản đối của John Carmack về việc Meta xây dựng XR OS tùy biến

• John Carmack bày tỏ lập trường phản đối việc Meta phát triển XR OS tùy biến
• Ông nhấn mạnh rằng việc phát triển hệ điều hành riêng sẽ dẫn đến gia tăng độ phức tạp và rủi ro
• Ông cho rằng việc tận dụng các nền tảng hiện có sẽ hiệu quả hơn cho tốc độ phát triển và tối ưu hóa nguồn lực
• Carmack khuyến nghị chiến lược dựa trên OS tiêu chuẩn để đổi mới nhanh và phản ứng với thị trường
• Ông nhấn mạnh cần tránh chia rẽ kỹ thuật và phân mảnh không cần thiết

---

Lập luận của John Carmack phản đối XR OS tùy biến của Meta

Bối cảnh

• John Carmack được cho là có quan điểm tiêu cực về phương án Meta tự phát triển XR (thực tế mở rộng) OS tùy biến
• XR OS là hệ điều hành chạy trên các thiết bị thực tế mở rộng như AR/VR

Tóm tắt các luận điểm chính

• Carmack cho biết nếu phát triển trên các nền tảng đã có sẵn trên thị trường như Android, Windows..., tốc độ phát triển và đổi mới sẽ được đẩy nhanh hơn
• Việc phát triển OS tùy biến kéo theo nhiều vấn đề như gia tăng độ phức tạp, nguy cơ phát sinh lỗi, và gánh nặng bảo trì dài hạn
• Khi dồn nguồn lực vào việc xây dựng nền tảng riêng, doanh nghiệp sẽ phải đánh đổi lợi ích từ việc tận dụng các công cụ và công nghệ tiêu chuẩn hóa của hệ sinh thái hiện có
• Để phản ứng nhanh hơn trước công nghệ mới và thay đổi trong nhu cầu người dùng, chiến lược tận dụng OS hiện có là hiệu quả hơn
• OS tùy biến có thể gây ra vấn đề tương thích và chi phí học tập cho cả nhà phát triển lẫn người tiêu dùng

Kết luận

• Carmack về lâu dài ưu tiên chiến lược tận dụng các nền tảng hiện có hơn là phát triển XR OS tùy biến, nhằm ngăn chặn sự phân mảnh của công nghệ và dịch vụ, đồng thời tối đa hóa khả năng mở rộng và tính hữu dụng

[GN⁺]

Ý kiến trên Hacker News

• Vấn đề khi làm việc ở Meta là nếu tôi đạt được thành quả thì rốt cuộc lại đang giúp thế giới trở nên tệ hơn… Tôi nghĩ những anh hùng thực sự là những người làm lãng phí tiền bạc và hiệu suất<br>Nếu có năng lực, tôi khuyên nên xây dựng sự nghiệp ở nơi khác
  • Một trong những cách tốt nhất để kỹ sư phần mềm phụng sự nhân loại là vào các công ty như Meta hay TikTok rồi giả vờ kém cỏi được càng lâu càng tốt
  • Tôi sẽ chặn Facebook và các dịch vụ liên quan, còn zstd thì vẫn dùng<br>Thế giới không phải là logic trắng đen
  • Đó là một góc nhìn quá đơn giản<br>Dù bạn nghĩ gì về mảng kinh doanh cốt lõi của Meta, công ty này vẫn thuê rất nhiều kỹ sư để làm việc trên nhiều dự án mã nguồn mở và cả R&D ít liên quan đến mạng xã hội như VR hay công nghệ datacenter<br>Tôi cho rằng được trả lương để nghiên cứu lĩnh vực mình quan tâm vẫn còn đỡ hơn nhiều con đường khác
  • Đây là một ý kiến khá bi quan, nhưng nhìn vào dữ liệu cho đến nay thì cũng không dễ bác bỏ
  • Nhưng thật ra chẳng phải điều này đúng với mọi tập đoàn lớn, thậm chí mọi công ty niêm yết sao?<br>Người sáng lập ban đầu có thể còn có mục tiêu khác, nhưng theo thời gian cuối cùng chỉ còn lợi nhuận là mục tiêu, mà thường thì càng tập trung vào việc xấu lợi nhuận lại càng lớn<br>Đây là một vấn đề mang tính hệ thống
• Tôi từng làm nhiều phần mềm cấp thấp, BSP, gần như toàn bộ hệ điều hành, và lý do thực sự khiến ngày nay người ta không tự làm OS là vì các nhà cung cấp silicon<br>Ngày xưa họ đưa tài liệu đặc tả chi tiết để bạn có thể tự viết driver, còn bây giờ chỉ quăng cho mấy mô tả mơ hồ cùng driver Linux chất lượng thấp<br>Một phần là vì lười, nhưng cũng vì độ phức tạp đã tăng lên<br>Phần cứng hiện đại quá phức tạp, chỉ riêng việc tài liệu hóa toàn bộ đã mất rất nhiều thời gian, còn tự viết driver thì còn lâu hơn nữa
  • Intel vẫn còn cung cấp tài liệu tử tế<br>Có tài liệu cực kỳ chi tiết công khai cho NIC tốc độ cao, và thực tế với card Ethernet e810 100Gb thì hoàn toàn có thể viết driver từ đầu chỉ với datasheet chính thức dài 2750 trang<br>Các vendor khác thì либо (1) phớt lờ, (2) yêu cầu NDA, hoặc (3) chỉ cho xem tài liệu driver Linux/FreeBSD tệ hại<br>Tôi không rõ tình hình với các loại phần cứng khác như SSD NVMe ra sao
  • Gần đây tôi cũng định hỗ trợ nút "soft reboot" trong hobby OS của mình mà vất vả quá nên bỏ cuộc luôn (để tăng tốc reboot trên GCP)<br>Tôi đã đọc hết hướng dẫn trên OS Dev Wiki, cả source Linux và FreeBSD mà vẫn không tiến triển gì<br>Đó là chức năng mà Windows hay Linux đều dùng khi khởi động lại<br>Tôi mất mấy ngày vào đó rồi cuối cùng đành bỏ<br>Những người làm OS đúng là được tạo ra từ một chất liệu khác, và có vẻ thường không bị áp lực kinh tế
  • Tôi nghe nhiều người nói “phần cứng hiện đại quá phức tạp nên khó tài liệu hóa”, nhưng tôi nghĩ đó chỉ là cái cớ<br>Đã phải đào tạo nhân viên mới trong team, lại còn phải quản lý testing, thì càng phức tạp càng phải tài liệu hóa kỹ hơn mới đúng<br>Nói cách khác, lời bào chữa của các nhà cung cấp silicon không thuyết phục tôi
  • Nếu bây giờ nghiêm túc muốn tự làm OS, có lẽ либо phải có quyền kiểm soát phần cứng cực mạnh, либо phải nhúng một instance Linux servant vào trong OS<br>Windows thì driver có sẵn dù trông như bug, còn Linux là đống driver bug miễn phí<br>Nếu chấp nhận để OS chạy như client trên hypervisor Linux thì đó cũng là một con đường; còn không thì chỉ còn cách chuyển dần từng phần hỗ trợ phần cứng sang OS của mình. Chỉ là tốc độ đó phải nhanh hơn tốc độ Linux phát sinh thêm dependency mới…
  • Với một số loại OS nhất định, tôi nghĩ có thể khá dễ lấy phần lớn hỗ trợ phần cứng của Linux bằng cách dùng LKL đã được port (https://github.com/lkl/linux) rồi chỉ thêm hook để truy cập phần cứng<br>Tất nhiên vẫn phải tự viết code cho core platform/chipset, nhưng các thiết bị I/O còn lại gần như được bao phủ hết<br>Có lẽ cách này sẽ hợp hơn với kiểu hỗ trợ driver ở user mode thay vì kernel monolithic thông thường
• Điều John nói mô tả đúng hệ thống mà tôi thực sự mong ai đó sẽ tạo ra<br>“Nếu muốn làm ra một cỗ máy tính hoàn toàn khác biệt, thì để thoát khỏi giếng hấp dẫn của các giải pháp đã tồn tại, gần như cần một cộng đồng kỹ sư ẩn dật như các tu sĩ”<br>Thử tưởng tượng nhé:<br>- Chọn nơi có chi phí sinh hoạt 200 USD/tháng<br>- Xây một ngôi làng đáng sống (không khí trong lành, thực phẩm lành mạnh, trường học tốt, v.v.) — rẻ đến mức một người giàu chống lưng cũng không thấy quá nặng<br>- Cung cấp thật nhiều máy tính hầu như không có phần mềm hay Internet<br>- Thử xây dựng một kiểu điện toán hoàn toàn mới từ đầu<br>Kiên nhẫn là yếu tố then chốt. Sẽ mất vài chục năm
  • Ý tưởng này thật sự rất thú vị Tôi tò mò không biết những nơi nào có mức chi phí sinh hoạt thấp như vậy Nhưng điều tôi thật sự thắc mắc là tại sao phải cố giải quyết ngay những bài toán hiện chưa khả thi? Có cần bắt đầu từ phần cứng như CPU không? Tôi nhớ lời một kỹ sư từng làm ở Intel — để học hết mọi thứ từ ISA hiện đại, CPU uArch, GPU rồi làm lại toàn bộ từ đầu, nếu còn phải tự trải nghiệm và va vấp đủ kiểu, thì chắc tới lúc nghỉ hưu mới xong
  • Tôi đã tự làm OS hơn 10 năm, và nếu thật sự muốn tạo ra thứ gì đó thì đây không phải việc nên làm<br>Tất nhiên nó vui, và đôi khi tôi cũng tưởng tượng xem nếu một ngày có cả đạo quân developer cực mạnh tham gia thì nó có thể phát triển tới đâu. (Dĩ nhiên sẽ không kiếm ra tiền)
  • Nói thật thì đây là một concept SF cực ngầu
• Ở Meta có khá nhiều người từ Microsoft sang liên quan đến hệ điều hành, và vốn dĩ họ rất thích làm OS<br>Nhưng ở Meta họ được đưa sang làm XR, nên đương nhiên họ muốn xây một OS tùy biến
• Sau những gì John Carmack đã làm ở Meta, giờ tôi thấy khó mà xem trọng ông ấy một cách nghiêm túc nữa Chỉ cần nhìn SerenityOS cũng đủ thấy hoàn toàn có thể tạo ra một hệ thống dễ dùng và nhất quán hơn Windows hay Linux<br>Tầm nhìn rõ ràng, khả năng thúc đẩy và sự tận tâm quan trọng hơn nhiều so với việc tuyển “top engineer” hay có “code chất lượng cao” — nếu có những thứ đó thì code tốt và nhân tài rồi cũng sẽ tự kéo đến<br>Đó là lý do điều này không thể xảy ra ở Meta, và cũng là lý do Linux thành ra như bây giờ Rào cản thực sự cuối cùng vẫn là driver. Tham khảo: vấn đề thirty-million line — blog caseymuratori.com
• Khi làm việc sau thương vụ sáp nhập Oculus, XROS thật sự là thứ rất phiền toái và gây xao nhãng đối với đội ngũ công nghệ cốt lõi<br>Đã có núi vấn đề cần giải quyết trong nhiều tech stack, vậy mà ý tưởng XROS chỉ xuất hiện sau khi Oculus được tích hợp hoàn toàn vào FB<br>Theo tôi thấy thì chỉ là một vài team (hoặc cá nhân) ở FB muốn leo lên chuyến tàu xu hướng AR/VR<br>Carmack hoàn toàn đúng, và từ sau đợt tái cơ cấu thì ảnh hưởng của ông ấy ngày càng giảm, tôi đã trực tiếp cảm nhận tác động xấu đó
  • Phần lớn team XROS không phải từ trụ sở FB mà được tuyển lateral hire từ trong ngành về (đa phần level E5/E6)<br>SWE của FB không hợp về năng lực kỹ thuật, có cả vài người từ bootcamp nhưng không thành công rồi nhanh chóng chuyển sang chỗ khác
  • Tôi rất tức giận vì họ đã phá hỏng cộng đồng mã nguồn mở Oculus, biến một dự án mà cộng đồng đã góp tiền nuôi sống thành thêm một mắt xích Meta để thu thập dữ liệu cá nhân<br>Dù vậy, tôi vẫn hy vọng lương của anh đủ dày
• Khoảng 2002~2004 tôi từng ở Microsoft và đã đọc một bài viết nội bộ do vài lập trình viên OS soạn kiểu hackathon cho Think Week của Bill Gates<br>Đó là một hệ điều hành hoàn toàn mới xây trên nền .NET, tự đưa cả GC lẫn memory management vào, boot được trên nhiều loại phần cứng và có khá nhiều tính năng thú vị<br>Thiết kế của nó rõ ràng là không tương thích chút nào với Windows, và có lẽ đó là lý do thất bại<br>Đó là thành quả của một vài chuyên gia OS tập trung khoảng một tháng, và thực sự rất thú vị
  • Có phải Singularity không?<br>Mô tả trên Wikipedia<br>Trang chính thức của Microsoft Research
  • Có vẻ là dự án Midori<br>Thực ra đó là một dự án quy mô lớn của Microsoft Research, kéo dài nhiều năm với hơn 100 người tham gia<br>Bài viết của ZDNet về dự án Midori
• Có chuyện John Carmack bị quản lý team XROS báo lên HR vì “làm tổn thương cảm xúc thành viên trong team” Thực ra tôi luôn cảm thấy Carmack rất chuyên nghiệp và lịch sự trong giao tiếp công khai Tôi cũng từng trải qua chuyện HR bị vũ khí hóa tương tự, và kiểu việc này làm bầu không khí công ty co cụm lại — một khi bạn nghĩ rằng chỉ vì ai đó không thích lời mình nói mà có thể kiện lên HR, thì từ đó về sau ai cũng cực kỳ dè dặt khi phát biểu
  • Tôi tiếp tục theo dõi các bài post nội bộ của Carmack trước khi ông ấy nghỉ việc, và ông ấy cực kỳ nghiêm khắc với chuyện lãng phí tài nguyên, nếu tính năng hand tracking hay bị hỏng thì ông ấy sẽ chỉ ra bằng số liệu cụ thể<br>Thông điệp của ông ấy luôn theo hướng “Apple đã nắm phần cứng, nên giờ phần mềm hiệu quả mới là chìa khóa của tương lai”, còn sự phung phí ở Meta rốt cuộc là do đấu đá quyền lực trong tổ chức
  • Lucovsky khăng khăng muốn tự làm OS từ đầu nên không nhìn thấy thực tế là các product team ngoài kia phải giao thứ gì đó thật cho khách hàng, vì thế bị gạt ra ngoài<br>Độc tính ông ấy để lại (dù bản thân có lẽ không nhận ra mức độ nghiêm trọng) cũng góp phần vào chuyện này<br>Hành vi tương tự lặp lại ở Google, và ở đó ông ấy cuối cùng cũng bị loại khỏi cuộc chơi, rồi chính thức được chốt lại là tự nguyện từ chức<br>Tham khảo Twitter 1 Tham khảo Twitter 2
  • John ngoài đời đôi khi rất thẳng và sắc

• Khi gặp những việc bản thân không có niềm tin, ông ấy có thể trở nên quá mức chỉ trích, và trong những lúc đó cán cân quyền lực khiến người khác cũng khó phản biện

• Lúc đó Meta có bầu không khí nội bộ hơi kỳ quặc<br>PSC (đánh giá hiệu suất) rất quan trọng, nên nếu một nhân vật huyền thoại như Carmack đánh giá dự án của tôi là “lãng phí tài nguyên” thì điều đó giáng thẳng vào kỳ đánh giá<br>“Impact” là một trục rất quan trọng ở Facebook để đo xem việc này hữu ích với công ty đến mức nào
• Tôi cũng từng thấy cảnh tương tự ở Google<br>Một distinguished engineer ban đầu nhẹ nhàng, sau đó rõ ràng nói với một kỹ sư junior rằng “đó là ý tưởng tồi, hãy dừng lại”, rồi HR vào cuộc<br>Trong những tình huống như vậy, cũng có lúc tôi chỉ bỏ qua vấn đề vì không còn muốn đổ thêm thời gian và công sức nữa
• Tôi từng ở Google khi team Flutter làm Fuchsia<br>Đó là những con người thật sự xuất sắc (những kỹ sư giỏi nhất tôi từng thấy), quân số lên đến hàng trăm và quy mô cũng rất lớn<br>Về mặt kỹ thuật thì cực kỳ ấn tượng, nhưng ngay từ đầu chẳng ai có thể trả lời rõ ràng là rốt cuộc ai sẽ dùng nó<br>Nếu mục tiêu chỉ là làm kernel mới để thay Linux hiện có thì còn ổn, nhưng ngược lại họ định tự xây toàn bộ hệ điều hành từ kernel, UI đến window manager từ đầu<br>Cuối cùng chỉ nhắm đến những thiết bị chuyên biệt có UI như Home Hub, mà ngay cả vậy cũng không chứng minh được vì sao cần phải đổi OS theo cách phức tạp như thế so với sản phẩm hiện có<br>Tôi vẫn thấy khó hiểu đến mức nực cười là Fuchsia đến giờ vẫn còn tiếp tục<br>Càng buồn hơn khi Google cắt giảm nhân lực ở các team thiết yếu trong lúc vẫn để người ở lại cho những dự án kiểu này<br>Thật sự tôi không hiểu vì sao họ vẫn giữ nó sống
  • Nếu chỉ nhìn kết quả ngắn hạn thì khó mà bào chữa, nhưng xét dài hạn thì việc phát triển OS mới là hợp lý Google thực sự quan tâm đến đầu tư dài hạn, và dự án cũng không cần phải đưa ra danh nghĩa đối ngoại<br>Nếu vậy thì bên chỉ trích lại có vẻ hơi kỳ. Cần thì tham gia, không thì cứ bỏ qua thôi Việc tạo ra hệ sinh thái ứng dụng mới vốn chưa bao giờ là mục tiêu, và điều khó nhất là phải tự triển khai toàn bộ vô số công nghệ mà bình thường ta xem là hiển nhiên. Khó nhưng không phải bất khả thi Có thêm lựa chọn thì chẳng có gì xấu — thay vì logic mâu thuẫn kiểu cho rằng thị trường trình duyệt cần đa dạng nhưng thị trường OS độc quyền lại chấp nhận được, thì nhiều OS hơn vẫn là điều tốt
  • Có lẽ họ coi một số thiết bị (Home Hub) là điểm khởi đầu, rồi từ đó tích lũy kinh nghiệm/doanh thu và mở rộng dần Tôi không nghĩ họ bắt đầu với ý định thay thế mọi thứ trong một lần
  • Tôi từng hiểu Fuchsia thực ra là một paradigm mới nơi nhiều OS và gói ứng dụng chạy trong container hoàn chỉnh<br>Trong tưởng tượng của tôi, đó là một OS tương lai có thể chạy cả trên web và trên nhiều máy cùng lúc<br>Tôi cũng từng kỳ vọng có thể chạy nhiều instance trên cùng một máy để tùy biến cho từng người dùng khác nhau
  • Tôi có cảm giác Fuchsia là một dự án kiểu tiêu hao, nhằm giữ chân các kernel engineer xuất sắc của Google không để họ sang đối thủ
  • Họ ép đẩy Fuchsia lên Home Hub, khiến stack cũ ngay lập tức thành legacy, rồi sau đó deadline cứ tiếp tục trễ mà không có kết quả gì<br>Tự làm OS có vẻ ngầu thật, nhưng cảm giác là toàn bộ dự án chỉ gây tác động xấu đến công việc của các team còn lại
• Dạo này việc bypass Linux kernel để truy cập trực tiếp phần cứng đã trở nên đơn giản hơn, và CPU nhiều core cũng rất phổ biến<br>Điểm mấu chốt là cô lập core để gán thread, rồi dùng kỹ thuật kernel bypass để điều khiển trực tiếp phần cứng. Giao tiếp giữa các core thì dùng ring buffer, như vậy vừa gần đạt hiệu năng tối ưu cho phần cứng, vừa tận dụng được ưu điểm của Linux kernel trong quản trị/giám sát/debug
  • Giống như mmap /dev/mem để truy cập trực tiếp physical memory, kernel bypass luôn là điều có thể làm bất cứ lúc nào