Buku Putih

Dokumen ini membahas secara mendalam desain arsitektur, pilihan teknologi, serta logika implementasi tingkat bawah dari fitur-fitur kunci WSL Dashboard, bertujuan memberikan perspektif kedalaman teknis bagi pengembang dan pengguna tingkat lanjut.

1. Gambaran Arsitektur

WSL Dashboard mengadopsi arsitektur klasik UI reaktif sebagai penggerak + tugas backend asinkron, memanfaatkan sistem tipe dan model kepemilikan bahasa Rust untuk menjamin keamanan memori dan kinerja konkurensi tinggi.

Komponen Inti

• Frontend (UI): Antarmuka deklaratif berbasis Slint. Thread UI bertanggung jawab atas rendering dan interaksi pengguna.
• Backend (Runtime): Runtime asinkron berbasis Tokio. Bertanggung jawab mendistribusikan dan mengeksekusi perintah sistem (CLI), I/O file, serta pendengaran jaringan.
• Komunikasi: Thread UI dan tugas asinkron berkomunikasi secara efisien dan aman terhadap thread melalui Channel (MPSC) dan Shared State (Arc/Mutex/RwLock).

2. Alasan Pemilihan Teknologi

Mengapa Memilih Rust?

• Kinerja: Abstraksi biaya nol, dikompilasi menjadi kode mesin native, tanpa jitter GC.
• Keamanan memori: Menghilangkan buffer overflow dan data race pada waktu kompilasi, sangat penting untuk alat yang melibatkan operasi tingkat bawah sistem (seperti migrasi disk, konfigurasi jaringan).
• Ukuran biner: Menautkan statis semua dependensi, menghasilkan program portabel file tunggal.

Mengapa Memilih Slint + Skia?

• Sintaks deklaratif: Deskripsi antarmuka terpisah dari logika, kode mudah dirawat.
• Rendering Skia: Langsung memanfaatkan akselerasi GPU (melalui mesin Skia), memberikan kejelasan teks tingkat sub-piksel dan efek animasi yang mulus.
• Overhead rendah: Dibandingkan Electron atau WPF, overhead runtime Slint sangat kecil.

3. Implementasi Teknologi Kunci

3.1 Deteksi dan Parsing Instance WSL

Aplikasi memperoleh status instance secara real-time dengan memanggil wsl.exe --list --verbose dan mem-parsing output-nya (menangani encoding UTF-16).

• Decoding tingkat bawah: Decoder encoding efisien buatan sendiri, memastikan output dapat diparsing dengan benar di lingkungan Windows dengan locale berbeda.
• Sinkronisasi status: Mengadopsi mekanisme sinkronisasi ganda polling berkala + pemicu operasi.

3.2 Migrasi Citra Disk (VHDX Move)

Fungsi migrasi memanfaatkan mekanisme impor-ekspor WSL, tetapi dengan abstraksi tinggi dan pemrosesan atomik.

• Jaminan transaksional: Sebelum migrasi dimulai, aplikasi mengunci distribusi target melalui Mutex, mencegah kerusakan data akibat operasi konkuren.
• Registrasi otomatis: Setelah migrasi selesai, aplikasi otomatis mengarahkan ulang jalur VHDX dan mendaftarkan ulang distribusi, pengguna tidak perlu campur tangan manual.

3.3 Port Forwarding dan Otomatisasi Firewall

Fungsi jaringan bukan hanya panggilan netsh interface portproxy sederhana.

• Manajemen siklus hidup aturan: Aplikasi otomatis mendeteksi aturan firewall yang ada. Saat pengguna membuat forwarding, aplikasi menggunakan Windows API atau CLI untuk membuat aturan pengecualian masuk (inbound) secara sinkron.
• Perolehan IP otomatis: Dengan mem-parsing hasil wsl hostname -I, otomatis memetakan IP jaringan virtual antara host dan instance.

3.4 Integrasi USBIP

Memanfaatkan antarmuka baris perintah usbipd-win.

• Penanganan peningkatan hak: Operasi bind memerlukan hak administrator, logika backend mengimplementasikan penerusan permintaan peningkatan UAC yang elegan.
• State machine status: Menjaga state machine koneksi perangkat USB secara internal, memastikan keterlacakan proses Attach/Detach.

3.5 Pemantauan Sumber Daya dan Ringannya

Aplikasi memantau penggunaan sumber daya sendiri dengan memanggil API native Windows (seperti GetProcessMemoryInfo).

• Sangat ringan: Dalam mode senyap tray, aplikasi secara proaktif membebaskan sumber daya UI yang tidak perlu. Untuk charset standar seperti Inggris, penggunaan memori dapat serendah 10MB; untuk charset kompleks seperti Cina-Jepang-Korea, karena perlu memuat cache rendering font yang besar, penggunaan sekitar 38MB.

4. Indikator Optimalisasi Kinerja

Indikator	Target/Terukur	Cara Optimalisasi
Kecepatan startup	< 500ms	Mengompilasi antarmuka Slint terlebih dahulu, mengurangi parsing runtime.
Memori dasar (tray)	~10MB	Meminimalkan frekuensi polling latar belakang, membebaskan cache rendering sesuai kebutuhan.
Penggunaan CPU (diam)	< 0.1%	Menggunakan model berbasis event Windows, menghindari polling loop kosong.
Frame rate rendering	60 FPS	Akselerasi GPU Skia, rendering anti-aliasing tingkat sub-piksel.

5. Logika Distribusi Tugas Backend

Untuk menjamin kelancaran UI, semua operasi yang memakan waktu (seperti ekspor VHDX) didistribusikan melalui tugas asinkron:

1. Pembungkusan permintaan: Thread UI membungkus operasi pengguna menjadi pesan Command.
2. Kanal pesan: Dikirim ke penangan tugas backend melalui tokio::sync::mpsc.
3. Pengembalian status: Setelah tugas backend selesai, UI diperbarui melalui callback atau status bersama. Desain ini memastikan bahwa bahkan saat memproses tugas pencadangan berukuran GB, antarmuka tetap dapat merespons klik pengguna secara real-time.

6. Pertimbangan Keamanan

• Operasi atomik: Untuk pencabutan registrasi dan migrasi instance yang kritis, menerapkan validasi sebelumnya.
• Manajemen peningkatan UAC: Hanya meminta izin saat diperlukan (seperti mengikat perangkat USB), mengikuti prinsip hak minimum.
• Penyimpanan lokal: Konfigurasi hanya disimpan secara lokal di ~\.wsldashboard, tanpa sinkronisasi cloud apa pun, melindungi privasi pengguna.