31 poin oleh unstabler 2026-02-17 | 8 komentar | Bagikan ke WhatsApp

Halo, saya unstabler. Ini pertama kalinya saya menulis artikel.
Saya memang bukan orang yang sering menulis, jadi tulisannya mungkin panjang dan agak tidak terstruktur, mohon dimaklumi!

Karena tidak suka macOS, saya malah mulai terobsesi dengan macOS

Sejak 2011, saya terutama menggunakan desktop Linux. Setelah melalui Ubuntu, Debian, dan Fedora, saya terus memakai Arch Linux + KDE Plasma sebagai OS utama. Karena berbagai keadaan, sejak 2021 saya mendirikan perusahaan yang berjalan mirip vendor SI, dan menerima berbagai pekerjaan selama itu menarik untuk dikerjakan, entah embedded C++, aplikasi mobile, maupun situs web sederhana.

Di tengah itu, porsi pekerjaan membuat aplikasi iOS makin lama makin besar. Namun, saya tidak terlalu ingin menggunakan Mac. Awalnya saya sempat mengubah keybind sana-sini dengan Karabiner, lalu bekerja dengan terhubung lewat Google Remote Desktop, tetapi terlalu lambat, dan di Xcode input keyboard maupun mouse kadang berperilaku aneh, sehingga cukup membuat stres.

Ngomong-ngomong, RDP! Ada xrdp, kan!

Saya tiba-tiba teringat RDP. RDP adalah protokol yang dikembangkan untuk Microsoft Windows, tetapi ada implementasi open source bernama xrdp. Namun, xrdp pada dasarnya mengasumsikan penggunaan X11, dan di macOS kombinasi screen sharing bawaan + backend VNC memang bisa dipakai, tetapi jika resolusi layar tidak pas 1:1, rasanya nyaris mustahil digunakan.

Karena itu, saya membuat plugin backend xrdp bernama ''麗 -ulalaca-' yang berbasis backend VNC milik xrdp dan ScreenCaptureKit, tetapi belum sampai pada tingkat yang layak untuk penggunaan nyata.

  • Dukungan GFX (H.264) / RFX yang hilang dari Windows versi terbaru (mstsc.exe):
    Saat saya mulai mengembangkannya, dukungan untuk codec GFX / RemoteFX sebenarnya sudah mulai dihapus. Di FreeRDP, klien untuk Linux, dukungannya masih tersisa, tetapi pada Windows versi sekarang tampaknya yang tersisa hanya kompresi berbasis RLE.
  • Tingkat kesulitan pengembangan / debugging yang sangat parah: selain fitur tampilan layar, pengembangannya terlalu sulit, dan debugging-nya juga sangat sulit. Awalnya saya sangat bersemangat dan ingin membuat output audio / sinkronisasi clipboard juga, tetapi karena saya memang mengidap ADHD, minat saya cepat sekali hilang.

Mari kita buat lagi dengan WebRTC! Tapi...

Setelah menelantarkan ulalaca selama sekitar setengah tahun, saat memikirkan Noctiluca saya sempat terpikir, “Mari kita buat dengan benar sekali lagi memakai WebRTC!” Namun, implementasi WebRTC juga tidak mudah.

  • Sulit untuk dikustomisasi: untuk menggunakan data layar sebagai video source, saya harus mengambil source code Google Chromium lalu memodifikasinya. Saat hardware encoding berhenti bekerja setelah saya mengubah parameter codec, saya harus mengobrak-abrik source code untuk mencari penyebabnya, menambahkan log, dan membangun ulang setiap kali.
  • Port tidak bisa dipatok: perlu signaling server, perlu TURN/STUN, dan yang paling parah, port keluar tidak bisa dipatok dan port reuse juga tidak bisa dilakukan. Sangat menyiksa.
  • Kutukan SCTP: WebRTC DataChannel secara internal menggunakan SCTP. Ada masalah bahwa jika ukuran payload satu pesan lebih besar dari MTU, stream video / audio mulai mengalami lag.

Pada akhirnya, berputar-putar lalu kembali ke QUIC

Karena lelah dengan kompleksitas WebRTC, kali ini pun saya menelantarkan Noctiluca hampir setengah tahun. Dalam perjalanan pulang setelah melamun di kafe, saya tiba-tiba teringat QUIC yang menjadi dasar HTTP/3. Kebetulan di macOS / iOS juga tersedia implementasi QUIC di Network.framework, jadi dengan menjadikan source code yang sudah ada sebagai basis, saya bisa cepat membuat prototipe, dan pada level prototipe masalah-masalah berikut langsung teratasi.

  • Mengatasi Head-of-Line Blocking (HOL): masalah terbesar solusi berbasis TCP maupun WebRTC DataChannel yang memakai SCTP adalah ketika satu paket hilang, semua data setelahnya ikut berhenti. Namun pada QUIC, stream bersifat independen. Walaupun satu paket audio tersendat, input mouse atau frame video tetap terus mengalir masuk.

  • Satu port UDP dan Connection Migration: tidak perlu lagi konfigurasi rumit seperti WebRTC dengan signaling server, STUN/TURN, dan sebagainya. Cukup buka satu port UDP, selesai. Bahkan saat berpindah Wi‑Fi AP, koneksi tetap terjaga berkat Connection Migration.

Kesimpulan: Saya mencari beta tester!

Saya sedang mencari para beta tester untuk software kendali jarak jauh bernama 'Noctiluca', yang lahir dari perjalanan di atas.

  • Menggunakan protokol rancangan sendiri bernama 'Sirius' yang berbasis QUIC.

    • Begitu spesifikasi dan hal-hal terkait segera final, saya berencana merilisnya sebagai open source!
  • Mendukung H.264 / H.265 (HEVC).

    • Juga mendukung codec gambar berbasis tile tradisional untuk lingkungan VM (MJPG, RLE, WebP).
  • Mendukung transmisi konten HDR. (eksperimental)

  • Dapat menegosiasikan persyaratan codec antara klien dan server.

  • Mendukung autentikasi PAM (username-password), password-only, dan kunci SSH.

  • Fungsinya dapat diperluas melalui plugin. Ke depannya saya berencana mengimplementasikan hal seperti fail2ban dan menyediakannya sebagai fitur tambahan.

    • Mekanisme autentikasi juga dapat diperluas dengan menulis plugin sendiri.
  • Saat ini klien hanya tersedia untuk iOS / macOS.

    • Saya berencana mengembangkan klien Linux / Windows berbasis Qt / C++!

Sampai hari ketika saya bisa mengembangkan aplikasi iOS dari laptop Linux saya!
Hari ini pun perjalanan saya untuk kembali ke laptop Linux saya masih terus berlanjut.

Terima kasih.

(+ Sebenarnya saya tidak tahu apakah boleh langsung mengunggah link Google Drive di sini, jadi untuk sementara saya menautkan postingan X yang saya unggah saat memperkenalkannya dulu..!)

(++ Ini sebenarnya produk sampingan(?) yang saya buat dengan vibe coding saat mengembangkan Noctiluca, tapi mohon dukungannya juga..!)

8 komentar

 
channprj 2026-02-18

Keren sekali!! 👍🏻

 
jjpark78 2026-02-18

Saya pakai Parsec

 
jjpark78 2026-02-18

Kalau mengesampingkan batasan bahwa ukuran monitor harus sama, ini sepertinya alat akses jarak jauh terbaik.
Karena iPad tidak didukung itu sama sekali bukan pertimbangan buat saya.

 
lux1024 2026-02-18

Saya juga pakai Parsec, dan sepertinya saya benar-benar kaget waktu tahu ternyata di mobile memang tidak didukung. Sampai sempat mikir, masa iya... hehe.

Sebenarnya untuk development iOS/macOS, rasanya yang paling bagus memang cukup pakai Mac mini atau MacBook yang dihubungkan lewat KVM, tapi itu juga lumayan merepotkan.

 
unstabler 2026-02-18

Sebenarnya, jika pengembangan Noctiluca bisa terus dilanjutkan, saya ingin membuat fitur yang mirip dengan konsep 'RemoteApp' milik Microsoft RDP. Dan juga fitur USB redirection!

Kalau saya mencolokkan iPhone ke ThinkPad saya lalu perangkat itu dikenali persis sama di Mac yang ada di ruangan lain, dan saya bisa menarik keluar hanya jendela Xcode untuk dipakai alih-alih 'layar penuh' Mac, saya rasa saya akan sangat bahagia.

 
unstabler 2026-02-18

Jadi, kami juga sedang merancang / mengimplementasikan fitur yang terkait dengan ini..!

Karena sampai sekarang masih belum ada yang benar-benar tertata, satu-satunya yang bisa saya tunjukkan untuk saat ini hanya ini T_T

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

 
moderator 2026-02-18

Tautan asli telah diganti dengan tautan Drive, dan tautan postingan X telah ditautkan di dalam artikel.

 
bus710 2026-02-17

Saya sempat memikirkan cara mengakses Mac, tetapi selama ini hanya punya bayangan samar bahwa mungkin bisa diakali dengan jetkvm dan tailscale.
Kalau pakai cara di artikel ini, sepertinya bahkan bisa tanpa KVM.