31 puan yazan unstabler 2026-02-17 | 8 yorum | WhatsApp'ta paylaş

Merhaba, ben unstabler. İlk kez bir yazı yazıyorum.
Normalde sık yazan biri olmadığım için biraz dağınık ve uzun bir yazı olabilir, anlayışınız için şimdiden teşekkür ederim!

macOS’tan hoşlanmadığım için macOS’a takıntılı hale geldim

Ben 2011’den beri ağırlıklı olarak Linux masaüstü kullanıyorum. Ubuntu, Debian ve Fedora’dan sonra ana işletim sistemi olarak Arch Linux + KDE Plasma kullanmaya devam ettim. Çeşitli nedenlerle 2021’den itibaren SI şirketi gibi işleyen bir firma kurdum; embedded C++ olsun, mobil uygulama olsun, basit bir web sitesi olsun, eğlenceli bulduğum her işi alıp yaptım.

Bu sırada iOS uygulaması geliştirme işlerinin payı giderek arttı. Ama Mac kullanmak pek istemiyordum. Başta Karabiner ile tuş atamalarını oradan oraya değiştirip denedim, sonra Google Remote Desktop ile bağlanarak çalıştım; ama hem çok yavaştı hem de Xcode içinde klavye girişi ve fare bazı durumlarda garip çalışıyordu, bu da ciddi stres yaratıyordu.

Düşününce, RDP! xrdp vardı ya!

Bir anda aklıma RDP geldi. RDP, Microsoft Windows için geliştirilmiş bir protokol ama xrdp adında açık kaynak bir uygulaması da vardı. Ancak xrdp varsayılan olarak X11 kullanımını temel alıyor ve macOS tarafında ise varsayılan ekran paylaşımı + VNC backend birleşimi kullanılabiliyordu; fakat ekran çözünürlüğü bire bir uyuşmadığında kullanmak neredeyse imkansız hale geliyordu.

Bu yüzden xrdp’nin VNC backend’i ile ScreenCaptureKit’i temel alan ''麗 -ulalaca-' adlı bir xrdp backend eklentisi yaptım, ama gerçek kullanım seviyesine kadar getiremedim.

  • Windows’un güncel sürümünde (mstsc.exe) artık kaybolmuş olan GFX (H.264) / RFX desteği:
    Geliştirmeye başladığım dönemde bile GFX / RemoteFX codec desteği kaldırılmaya başlamıştı. Linux istemcisi olan FreeRDP’de destek hâlâ duruyor, ancak Windows’un mevcut sürümünde yalnızca RLE tabanlı sıkıştırmanın kaldığı anlaşılıyor.
  • Aşırı zor geliştirme / debug süreci: ekran gösterimi dışında geliştirme çok zordu, debug etmek de aynı şekilde çok zordu. Başta oldukça hevesliydim; ses çıkışı, pano senkronizasyonu gibi şeyleri de yapmak istiyordum ama zaten ADHD ile uğraştığım için ilgim hızla söndü.

Bir kez daha WebRTC ile yapalım! Ama...

Ulalaca’yı kaderine terk ettikten yaklaşık yarım yıl sonra, Noctiluca’yı düşünürken “Bu işi bu kez WebRTC ile düzgün yapalım!” diye düşündüm. Ama WebRTC uygulaması da hiç kolay değildi.

  • Özelleştirme zorluğu: ekran verisini video kaynağı olarak kullanmak için Google Chromium’un kaynak kodunu indirip değiştirmem gerekti. Codec parametrelerini değiştirdikten sonra donanım kodlamanın çalışmadığı dönemlerde, nedenini anlamak için kaynak kodun içinde didik didik gezip log ekliyor ve her seferinde yeniden derleme yapıyordum.
  • Port sabitleme imkânsızlığı: hem signaling sunucusu gerekiyordu hem TURN/STUN gerekiyordu; hepsinden önemlisi giden portu sabitlemek ve port reuse yapmak mümkün değildi. Gerçekten çok yıpratıcıydı.
  • SCTP’nin laneti: WebRTC DataChannel içeride SCTP kullanıyor. Bir mesajın payload boyutu MTU’dan büyük olduğunda video / ses akışında takılmalar başlaması gibi bir sorun var.

Sonunda döne döne QUIC’e geldim

WebRTC’nin karmaşıklığından yorulup bu kez de Noctiluca’yı neredeyse yarım yıl boyunca kaderine terk ettim. Bir gün kafede boş boş oturup eve dönerken birden HTTP/3’ün temeli olan QUIC aklıma geldi. Tam da macOS / iOS’ta Network.framework üzerinden QUIC implementasyonu sunuluyordu; bu yüzden mevcut kaynak kodu temel alarak prototipi hızlıca yapabildim ve daha prototip aşamasında aşağıdaki sorunlar hemen çözüldü.

  • Head-of-Line Blocking (HOL) çözümü: TCP tabanlı çözümlerin ya da SCTP kullanan WebRTC DataChannel’ın en büyük sorunu, tek bir paketin kaybolması halinde arkasından gelen tüm verinin durmasıdır. Ama QUIC’te stream’ler bağımsızdır. Tek bir ses paketi aksasa bile fare girdisi ya da video kareleri akmaya devam eder.

  • Tek UDP portu ve Connection Migration: WebRTC’deki gibi signaling sunucusu, STUN/TURN gibi karmaşık yapılar kurmaya gerek kalmadı. Sadece tek bir UDP portu açmanız yeterli. Wi‑Fi AP değişse bile Connection Migration sayesinde bağlantı korunabildi.

Sonuç: Beta test kullanıcıları arıyorum!

Bu hikâyenin sonucu olarak ortaya çıkan 'Noctiluca' adlı uzaktan kontrol yazılımı için beta test kullanıcıları arıyorum.

  • QUIC tabanlı, kendi tasarımımız olan 'Sirius' adlı protokolü kullanıyor.

    • Spesifikasyon vb. netleşir netleşmez açık kaynak olarak yayımlamayı planlıyorum!
  • H.264 / H.265 (HEVC) desteği sunuyor.

    • VM ortamları için geleneksel tile tabanlı görüntü codec’leri (MJPG, RLE, WebP) de destekleniyor.
  • HDR içeriğin aktarımını destekliyor. (deneysel)

  • İstemci ile sunucu arasında codec gereksinimleri üzerinde pazarlık yapılabiliyor.

  • PAM (username-password), yalnızca parola ve SSH anahtarı kullanan kimlik doğrulamayı destekliyor.

  • Eklentilerle işlevler genişletilebiliyor. İleride fail2ban vb. şeyleri implemente ederek ek özellik olarak sunmayı planlıyorum.

    • Eklentileri doğrudan yazarak kimlik doğrulama mekanizmasını genişletebilirsiniz.
  • İstemcinin şu anda yalnızca iOS / macOS sürümleri var.

    • Qt / C++ tabanlı Linux / Windows istemcisi de geliştirmeyi planlıyorum!

Linux dizüstü bilgisayarımla iOS uygulama geliştirebildiğim o güne kadar!
Bugün de Linux dizüstü bilgisayarıma geri dönme yolculuğum devam ediyor.

Teşekkür ederim.

(+ Aslında Google Drive bağlantısını doğrudan buraya koymanın uygun olup olmadığından emin olamadığım için, şimdilik daha önce tanıtırken paylaştığım X gönderisini bağlantı olarak ekliyorum..!)

(++ Noctiluca’yı geliştirirken vibe coding ile ortaya çıkan bir yan ürün(?) ama buna da ilgi göstermenizi rica ederim..!)

8 yorum

 
channprj 2026-02-18

Harika!! 👍🏻

 
jjpark78 2026-02-18

Parsec kullanıyorum

 
jjpark78 2026-02-18

Monitör boyutlarının aynı olması gerekliliği dışında bence en iyi uzaktan erişim araçlarından biri.
iPad’in desteklenmemesi ise benim için pek önemli değil.

 
lux1024 2026-02-18

Ben de Parsec kullanıyorum; mobilde gerçekten çalışmadığını öğrenince biraz şok olmuştum. İnsan pek ihtimal vermiyor... haha.

Aslında iOS/macOS geliştirme için bir Mac mini ya da MacBook’u KVM’e bağlayıp kullanmak en iyisi gibi geliyor ama uğraştırıcı olabiliyor.

 
unstabler 2026-02-18

Açıkçası, Noctiluca’nın geliştirilmesini sürdürebilirsem, Microsoft RDP’nin RemoteApp kavramına benzer bir özellik yapmak istiyorum. Bir de USB yönlendirme özelliği!

ThinkPad’ime iPhone’u taktığımda, diğer odadaki Mac’te de aynı şekilde algılansa ve Mac’in 'tam ekran'ı yerine sadece Xcode penceresini çekip kullanabilsem gerçekten çok mutlu olurdum.

 
unstabler 2026-02-18

Bu nedenle ilgili özellikleri de tasarlayıp uygulama sürecindeyim..!

Henüz hiçbir şey toparlanmış değil, bu yüzden gösterebileceğim tek şey şimdilik bu T_T

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

 
moderator 2026-02-18

Orijinal bağlantıyı Drive bağlantısıyla değiştirdim ve X gönderisi bağlantısını yazının içine ekledim.

 
bus710 2026-02-17

Mac'e nasıl erişeceğimi düşünüyordum ama jetkvm ve tailscale ile bir şekilde halledilemez mi diye sadece belirsiz bir fikir vardı aklımda.
Metindeki yöntemle olursa, kvm olmadan da mümkün olacak gibi görünüyor.