31 điểm bởi unstabler 2026-02-17 | 8 bình luận | Chia sẻ qua WhatsApp

Xin chào, tôi là unstabler. Đây là lần đầu tôi viết bài.
Vì bình thường tôi không hay viết lắm nên bài có thể hơi dài dòng và thiếu mạch lạc, mong mọi người thông cảm!

Vì ghét macOS nên tôi bắt đầu ám ảnh với macOS

Từ năm 2011, tôi chủ yếu sử dụng desktop Linux. Đi qua Ubuntu, Debian, Fedora, rồi tôi tiếp tục dùng Arch Linux + KDE Plasma làm OS chính. Vì nhiều lý do khác nhau, từ năm 2021 tôi đã lập một công ty vận hành gần giống một nhà thầu SI, và nhận đủ loại công việc miễn là thấy thú vị: từ C++ nhúng, ứng dụng di động cho tới website đơn giản.

Trong lúc đó, tỷ trọng công việc làm ứng dụng iOS ngày càng tăng. Nhưng tôi lại không muốn dùng Mac cho lắm. Ban đầu tôi thử đổi keybind bằng Karabiner các kiểu, rồi kết nối bằng Google Remote Desktop để làm việc, nhưng nó quá chậm, lại còn có hiện tượng bàn phím hoặc chuột hoạt động bất thường trong Xcode, khiến tôi rất căng thẳng.

Nghĩ lại mới nhớ RDP! Có xrdp mà!

Tôi chợt nghĩ đến RDP. RDP là giao thức được phát triển cho Microsoft Windows, nhưng có một bản triển khai mã nguồn mở tên là xrdp. Tuy nhiên, xrdp mặc định giả định sử dụng X11, còn trên macOS thì có thể dùng tổ hợp chia sẻ màn hình mặc định + backend VNC, nhưng nếu độ phân giải màn hình không khớp 1:1 thì gần như không thể dùng nổi.

Vì vậy tôi đã tạo một plugin backend xrdp tên là ''麗 -ulalaca-' dựa trên backend VNC của xrdp và ScreenCaptureKit, nhưng cuối cùng vẫn chưa đạt đến mức có thể dùng thực tế.

  • Hỗ trợ GFX (H.264) / RFX đã biến mất trên các phiên bản Windows mới (mstsc.exe):
    Vào thời điểm tôi bắt đầu phát triển, việc hỗ trợ codec GFX / RemoteFX đã bắt đầu bị loại bỏ. FreeRDP, client cho Linux, vẫn còn hỗ trợ, nhưng trên các phiên bản Windows hiện tại dường như chỉ còn lại nén dựa trên RLE.
  • Độ khó phát triển / debug cực kỳ khủng khiếp: Ngoài tính năng hiển thị màn hình ra thì việc phát triển quá khó, và debug cũng quá khó. Ban đầu tôi còn đầy nhiệt huyết muốn làm thêm cả xuất âm thanh / đồng bộ clipboard, nhưng vì vốn dĩ tôi cũng bị ADHD nên hứng thú nguội đi rất nhanh.

Hãy làm lại một lần nữa với WebRTC! Nhưng mà...

Sau khi bỏ mặc ulalaca khoảng nửa năm, trong lúc lên ý tưởng cho Noctiluca, tôi đã nghĩ kiểu như “hãy làm lại cho ra hồn bằng WebRTC!”. Nhưng triển khai WebRTC cũng chẳng hề đơn giản.

  • Khó tùy biến: Để dùng dữ liệu màn hình làm nguồn video, tôi buộc phải tải mã nguồn của Google Chromium về rồi chỉnh sửa. Có lúc sau khi sửa tham số codec thì hardware encoding không hoạt động nữa; để tìm nguyên nhân, tôi phải lục tung mã nguồn, thêm log, rồi build lại từ đầu mỗi lần.
  • Không thể cố định cổng: Cần cả signaling server, lại cần TURN/STUN, và trên hết là không thể cố định cổng đi ra, cũng không thể tái sử dụng cổng. Thật sự rất khổ sở.
  • Lời nguyền của SCTP: WebRTC DataChannel nội bộ sử dụng SCTP. Khi kích thước payload của một message vượt quá MTU, sẽ xuất hiện vấn đề là luồng video / audio bắt đầu bị giật lag.

Cuối cùng, đi một vòng rồi lại đến QUIC

Mệt mỏi vì sự phức tạp của WebRTC, lần này tôi cũng lại bỏ mặc Noctiluca gần nửa năm. Trên đường rời quán cà phê trong trạng thái đầu óc trống rỗng, tôi chợt nghĩ đến QUIC, thứ làm nền tảng cho HTTP/3. Đúng lúc Network.framework trên macOS / iOS cũng cung cấp bản triển khai QUIC, nên tôi có thể nhanh chóng tạo prototype dựa trên mã nguồn hiện có, và ngay ở cấp độ prototype thì các vấn đề dưới đây đã được giải quyết ngay lập tức.

  • Giải quyết Head-of-Line Blocking (HOL): Vấn đề lớn nhất của các giải pháp dựa trên TCP, hay WebRTC DataChannel dùng SCTP, là chỉ cần mất một gói tin thì toàn bộ dữ liệu phía sau sẽ dừng lại. Nhưng QUIC có các stream độc lập. Dù một gói audio có bị lỗi, input chuột hay frame video vẫn tiếp tục đổ vào.

  • Một cổng UDP duy nhất và Connection Migration: Không cần cấu hình phức tạp với signaling server hay STUN/TURN như WebRTC. Chỉ cần mở một cổng UDP là xong. Ngay cả khi chuyển Wi‑Fi AP, kết nối vẫn được duy trì nhờ Connection Migration.

Kết luận: Tôi đang tìm beta tester!

Tôi xin mời các bạn tham gia beta test phần mềm điều khiển từ xa có tên 'Noctiluca' với toàn bộ câu chuyện như trên.

  • Sử dụng giao thức tự thiết kế tên là 'Sirius' dựa trên QUIC.

    • Khi đặc tả và các chi tiết liên quan sớm được chốt, tôi dự định sẽ công bố mã nguồn mở!
  • Hỗ trợ H.264 / H.265 (HEVC).

    • Cũng hỗ trợ các codec ảnh dạng tile truyền thống (MJPG, RLE, WebP) cho môi trường VM.
  • Hỗ trợ truyền nội dung HDR. (thử nghiệm)

  • Có thể thương lượng yêu cầu codec giữa client và server.

  • Hỗ trợ xác thực bằng PAM (username-password), chỉ password, và khóa SSH.

  • Có thể mở rộng tính năng bằng plugin. Sau này tôi dự định triển khai cả fail2ban v.v. và cung cấp như tính năng bổ sung.

    • Bạn cũng có thể tự viết plugin để mở rộng cơ chế xác thực.
  • Hiện tại mới chỉ có client cho iOS / macOS.

    • Tôi dự định sẽ phát triển client Linux / Windows dựa trên Qt / C++!

Cho đến ngày tôi có thể phát triển ứng dụng iOS bằng chiếc laptop Linux của mình!
Hôm nay hành trình quay trở lại với chiếc laptop Linux của tôi vẫn tiếp tục.

Xin cảm ơn.

(+ Thật ra tôi không chắc có thể đăng trực tiếp link Google Drive ở đây hay không, nên trước mắt tôi gắn link bài đăng X mà tôi đã dùng để giới thiệu trước đây..!)

(++ Trong lúc phát triển Noctiluca, tôi còn tạo ra vài “sản phẩm phụ” bằng vibe coding(?), bên này cũng mong mọi người quan tâm giúp..!)

8 bình luận

 
channprj 2026-02-18

Tuyệt vời!! 👍🏻

 
jjpark78 2026-02-18

Tôi dùng Parsec

 
jjpark78 2026-02-18

Nếu bỏ qua ràng buộc phải có cùng kích thước màn hình thì có lẽ đây là công cụ truy cập từ xa tốt nhất.
Việc iPad không dùng được thì với tôi hoàn toàn không thành vấn đề.

 
lux1024 2026-02-18

Tôi cũng dùng Parsec, và hình như đã khá sốc khi biết nó thật sự không hỗ trợ mobile. Cứ tưởng là có chứ... haha.

Thật ra với việc phát triển iOS/macOS thì có lẽ cứ nối Mac mini hoặc MacBook qua KVM rồi dùng vẫn là tốt nhất, nhưng cũng khá phiền.

 
unstabler 2026-02-18

Thật ra, nếu có thể tiếp tục phát triển Noctiluca, tôi muốn tạo ra tính năng tương tự khái niệm 'RemoteApp' của Microsoft RDP. Và cả tính năng chuyển hướng USB nữa!

Nếu tôi cắm iPhone vào chiếc ThinkPad của mình mà máy Mac ở phòng khác cũng nhận diện y hệt, rồi tôi có thể chỉ tách riêng đúng cửa sổ Xcode ra để dùng thay vì phải dùng 'toàn màn hình' của Mac, thì chắc tôi sẽ rất hạnh phúc.

 
unstabler 2026-02-18

Vì vậy, chúng tôi cũng đang thiết kế/triển khai các tính năng liên quan..!

Hiện vẫn chưa sắp xếp được gì cả nên thứ duy nhất có thể cho mọi người xem chỉ là cái này thôi T_T

https://gist.github.com/unstabler/25679baab3a65a3c19f747c38f30c1b3

 
moderator 2026-02-18

Đã thay liên kết gốc bằng liên kết Drive, và liên kết bài đăng trên X đã được gắn trong nội dung bài viết.

 
bus710 2026-02-17

Tôi từng băn khoăn không biết nên truy cập vào máy Mac như thế nào, nhưng chỉ mơ hồ nghĩ rằng chắc bằng cách nào đó có thể làm được với jetkvm và tailscale.
Nếu theo cách trong bài thì có lẽ ngay cả khi không có KVM cũng làm được.