Masa Depan Flatpak

• Flatpak saat ini populer di kalangan pengembang dan pengguna, tetapi masalah stagnasi pengembangan proyek itu sendiri mulai mencuat
• Karena hengkangnya pengembang inti dan bottleneck, penerapan fitur baru serta code review mengalami penundaan
• Berbagai fitur penguatan seperti dukungan image OCI, perincian izin, dan kontrol akses audio telah diusulkan, tetapi implementasi nyatanya berjalan lambat
• Untuk perkembangan jangka panjang proyek, dibahas penerapan standar teknologi container (OCI) dan opsi reimplementasi berbasis Rust
• Penyelesaian tantangan utama seperti peningkatan portal, dukungan driver, dan sandboxing jaringan menjadi kunci pertumbuhan Flatpak

---

Gambaran Umum dan Kondisi Proyek Flatpak

• Flatpak dimulai dari proyek serupa sejak 2007, pertama dirilis sebagai XDG-App pada 2015, lalu berganti nama menjadi Flatpak pada 2016
• Flatpak menyediakan alat command line, build tool, dan komponen runtime, serta memiliki karakteristik isolasi aplikasi (sandboxing) menggunakan cgroups, namespaces, bind mount, seccomp, Bubblewrap, dan lain-lain
• OSTree digunakan sebagai metode distribusi utama, dan belakangan dukungan image OCI juga ditambahkan untuk digunakan di Fedora dan lainnya
• Pertumbuhan app store Flathub dan adopsi distro tergolong sukses, tetapi di dalam proyek sendiri terjadi perlambatan pengembangan aktif

Kebuntuan Pengembangan dan Penyebab Utama

• Aktivitas pemeliharaan dan patch keamanan masih ada, tetapi pengembangan fitur baru berskala besar serta code review mengalami stagnasi berkepanjangan
• Karena hengkangnya pengembang utama (seperti Larsson), jumlah reviewer menjadi kurang, sehingga masuknya kontributor baru atau perubahan besar menjadi sulit
• Bahkan fitur preinstall Flatpak yang dikontribusikan oleh Red Hat dan lainnya berulang kali memerlukan waktu berbulan-bulan untuk integrasi penuh karena review tertunda dan penanggung jawab keluar

OSTree dan Dukungan Image OCI

• OSTree berhasil diterapkan di Flatpak, tetapi karena masalah alat yang nonstandar/terbatas, tidak banyak perkembangan aktif selain pemeliharaan
• OCI memiliki ekosistem alat yang luas untuk image container, sehingga dari sudut pandang tim pengembang Flatpak, adopsinya diharapkan dapat mengurangi beban pemeliharaan dan upaya yang tumpang tindih
• Dukungan format kompresi efisien seperti zstd:chunked juga telah diusulkan lewat PR baru, tetapi tetap berada dalam status tertunda/belum digabungkan

Manajemen Izin dan Perincian Sandbox

• Flatpak berfokus pada pembatasan akses sistem melalui sandboxing, dan pada Flatpak versi terbaru sudah didukung perincian izin (misalnya --device=input)
• Karena versi Flatpak berbeda di tiap distro Linux, muncul masalah fitur izin baru tidak dapat diterapkan secara luas serta masalah kompatibilitas versi
• Untuk izin audio, keterbatasan dukungan PulseAudio membuat pemisahan pemutaran dan perekaman sulit dilakukan, sehingga muncul kebutuhan perbaikan melalui PipeWire dan sejenisnya
• Dukungan nested sandboxing yang masih kurang membuat aplikasi seperti web browser tidak dapat memanfaatkan sandbox internal secara terpisah

D-Bus dan Sandboxing Jaringan

• Flatpak tidak mengakses D-Bus secara langsung, melainkan menggunakan xdg-dbus-proxy untuk komunikasi yang difilter
• Wick menunjukkan niat untuk memindahkan kebijakan filtering ke broker D-Bus agar penerapan kebijakan dinamis dan kontrol akses berbasis cgroup dapat diwujudkan
• Karena implementasi network namespace masih belum memadai, ada kemungkinan komunikasi tak disengaja antar aplikasi Flatpak saat port localhost terekspos (contoh nyata: AusweisApp)
• Driver NVIDIA disediakan terpisah untuk setiap runtime, yang menyebabkan trafik jaringan berlebihan dan sulitnya pembaruan. Dengan merujuk model Valve, sedang dijajaki pendekatan seperti berbagi dengan host dan kompilasi statis

Pemanfaatan Portal dan Kebutuhan Peningkatan

• Portal adalah API akses sumber daya eksternal berbasis D-Bus, yang menangani beragam peran seperti file, cetak, URL, dan lainnya
• Portal seperti Documents efektif pada tingkat file per file, tetapi untuk aplikasi dengan kegunaan tinggi seperti GIMP dan Blender, model izin yang terlalu terperinci menjadi kendala
• Bersamaan dengan usulan API baru seperti autofill kata sandi, kunci FIDO, dan sintesis suara, dibahas pula ide untuk mempermudah tingkat kesulitan pengembangan serta reimplementasi Rust

Masa Depan Flatpak (Flatpak-next)

• Dengan asumsi Flatpak suatu saat tidak lagi dikembangkan, dibahas dalam perspektif jangka panjang peralihan besar ke ekosistem OCI (image, registry, alat, kebijakan, dan pemanfaatan yang luas)
• Melalui reimplementasi berbasis Rust dan penyatuan dengan ekosistem container, diharapkan ada keunggulan dari sisi beban pengelolaan, pemeliharaan, dan skalabilitas

Ringkasan Tanya Jawab

• Menanggapi pertanyaan tentang penanganan aplikasi Flatpak yang sudah ada saat beralih ke OCI, dijawab bahwa hal itu tidak akan menjadi masalah besar berkat otomatisasi build di Flathub
• Terkait kurangnya metadata di registry OCI, standar untuk data non-image sedang disiapkan, tetapi untuk penerapan nyata tetap diperlukan pengembangan dan integrasi
• Mengenai rencana dukungan langsung untuk PipeWire, diskusi teknis sedang berlangsung, dan arahnya adalah integrasi berbasis kebijakan PipeWire

Kesimpulan

• Flatpak telah memantapkan diri sebagai platform standar untuk distribusi dan sandboxing, tetapi masih memiliki berbagai tugas perbaikan seperti stagnasi review dan pengembangan baru, masalah izin/jaringan/driver, serta transisi ke standar masa depan
• Teknologi container berbasis OCI dan pemanfaatan Rust berpotensi muncul sebagai pendorong baru bagi perkembangan Flatpak
• Poin utama dapat diringkas sebagai menambah reviewer, standardisasi, perluasan ekosistem, dan peningkatan pengalaman pengguna

[ndrgrd]

Menurut saya, lebih baik bukan memblokir izin akses sepenuhnya, melainkan menampilkan dengan jelas direktori mana yang diakses.

Android cukup baik dalam hal itu, tetapi di sana izin digabungkan terlalu besar sehingga kita juga harus mengizinkan tingkat akses yang sebenarnya tidak diperlukan...

[GN⁺]

Opini Hacker News

• Membagikan poin dari presentasi Wick yang menekankan bahwa proyek Flatpak dari luar tampak berjalan baik, tetapi kenyataannya tidak banyak pengembangan aktif yang terjadi; pemeliharaan keamanan dan perawatan sederhana tetap berlanjut, tetapi hampir tidak ada fitur baru yang ditambahkan. Menilai situasi macet ini bermasalah karena banyak usulan fitur (Merge Request) diajukan, tetapi tidak ada yang meninjaunya. Terutama karena RHEL 10 menghentikan penyediaan paket desktop dan merekomendasikan pemasangan paket dari Flathub, peran Red Hat dianggap makin penting. Jika Red Hat benar-benar ingin menjadikan Flatpak sebagai alternatif yang layak, diharapkan mereka mengalokasikan lebih banyak sumber daya. Juga setuju dengan poin Wick bahwa dukungan izin baru berbeda-beda menurut versi Flatpak sehingga backward compatibility diperlukan. Ia sendiri mengalami langsung saat mendistribusikan game di Flathub: masalah izin audio dan kontroler, tidak didukungnya --device=input, serta tidak adanya pengaturan izin yang lebih rinci seperti hanya membuka speaker tetapi memblokir mikrofon
  • Menyebut contoh bahwa Red Hat awalnya hendak mendistribusikan Firefox dan Thunderbird di RHEL 10 hanya sebagai Flatpak, tetapi pada akhirnya juga menyediakan paket rpm setelah rilis GA. Berbagai alasan berperan bersama, seperti tidak didukungnya Native Messaging, tidak bisa melakukan deployment kebijakan terpusat, dan masalah integrasi desktop
• Membagikan pengalaman pernah bertemu langsung dengan pengembang awal Flatpak saat proyek ini baru dimulai dan berdiskusi tentang filosofi desainnya. Ia mencoba meyakinkan bahwa masalah Flatpak adalah izin terikat pada nama paket dan tidak terpisah per instans. Artinya, aplikasi Flatpak yang sama tidak bisa dijalankan dalam beberapa instans terpisah dengan izin berbeda, misalnya hanya mengizinkan direktori tertentu di bawah Documents untuk tiap instans. Menurutnya, struktur seperti ini juga sama pada MS, Apple App Store, dan macOS, sehingga seluruh dunia salah mendesainnya. Misalnya, walaupun terjadi RCE (eksekusi kode jarak jauh) pada dokumen LibreOffice, akses ke dokumen-dokumen lain seharusnya tetap diblokir. Ia berpendapat bahwa walaupun vendor tidak terlalu memperhatikan keamanan, sandbox Flatpak seharusnya tetap memberi perlindungan
  • Ada pula pandangan kritis terhadap bertambahnya kompleksitas demi tujuan keamanan ini. Karena PC adalah miliknya sendiri, izin per instans, sandbox, pembatasan berbagi file, dan sejenisnya dianggap tidak perlu, dan ia ingin mempertahankan konsep tradisional "semuanya adalah file". Sebagai contoh, ia tidak suka lingkungan sandbox tempat Thunderbird dan Firefox tidak dapat mengakses direktori /tmp, sehingga menyimpan lampiran dan membukanya di aplikasi lain menjadi sangat tidak praktis. Menurutnya pemilik komputer seharusnya adalah pengguna, bukan pengembang. Keamanan yang berlebihan seperti ini dianggap menurunkan produktivitas, dan ia mengibaratkannya dengan Useless Machine
  • Mengemukakan kemungkinan bahwa tim pengembang Flatpak juga memahami masalah ini. Jika Flatpak memilih model yang sempurna secara teknis, justru hambatan masuk bagi pengembang aplikasi, terutama pengembang multiplatform, akan terlalu besar sehingga Flatpak sendiri mungkin tidak akan pernah menyebar luas
  • Mengusulkan bahwa model izin per instans sangat menarik, tetapi untuk konfigurasi lingkungan seperti git config, folder font, dan sebagainya, pendekatan hibrida yang menjadikan semua instans memiliki izin akses yang sama sebagai opsi akan lebih praktis
  • Berpendapat bahwa yang ideal adalah merancang ulang sistem operasi secara menyeluruh agar tiap instans yang sedang berjalan memperoleh capabilities terpisah, serta mendukung berbagai fitur seperti kuota disk, logging, proxy, dan pemisahan izin yang rinci. Menurutnya ini bukan sekadar masalah Flatpak saja
  • Bagi power user dan pengguna yang sensitif terhadap keamanan yang membutuhkan pemisahan ketat seperti sandboxing berbasis hypervisor ala QubesOS, pemisahan per instans memang baik. Namun, bagi kebanyakan pekerjaan isolasi, pendekatan yang intuitif adalah melakukannya di dalam aplikasi. Seperti sandboxing pada browser web, idealnya Flatpak juga mendukung nested sandbox, tetapi saat ini belum didukung. Ada juga masalah yang cukup rumit seperti keterkaitan tanda tangan kode dengan sandbox dan UID namespace
• Sebagai pengguna Flatpak yang sudah lama sangat antusias, ia merasa Flatpak dulu inovatif dan memudahkan penggunaan aplikasi terbaru di semua distribusi Linux, tetapi karena beberapa tahun hampir tidak ada perubahan, minatnya perlahan memudar. Sekarang kebutuhannya sebagian besar terpenuhi oleh AUR, dan stagnasi Flatpak disayangkan
  • Sebagai pengguna, selain mudah dipakai, ia merasa tidak ada pengalaman yang benar-benar baik dari Flatpak. Ada banyak masalah integrasi seperti tema, kursor, file picker, permission, Drag&Drop, dan kebutuhan akan alat tambahan untuk menggunakan fitur tertentu. Menurutnya jika UX-nya buruk, manfaat keamanan seperti sandboxing menjadi tidak berarti. Jika Linux tidak punya masalah portabilitas biner, Flatpak menurutnya tidak akan diperlukan
  • Ia pernah merasa kombinasi Fedora+GNOME+Flatpak sangat inovatif, tetapi belakangan kembali ke Arch. Repositori Arch kini jauh lebih kaya dan hampir tidak perlu lagi memakai AUR
  • Sambil menanyakan pengalaman menggunakan makedeb kepada orang yang pernah mengelola banyak paket, ia menyebut makedeb berbasis PKGBUILD sehingga sangat portabel, dan heran mengapa tidak lebih dikenal luas
• Tidak 100% setuju dengan argumen Drew DeVault bahwa "distribusi seharusnya menangani packaging aplikasi", tetapi memperkenalkan tulisan panjang yang sudah lama dibahas dan tautan referensi. Ada pandangan bahwa model yang benar adalah komunitas (distribusi) mengelola paket sebagai wakil pengguna, dan bahwa model packaging di luar distribusi seperti Flatpak/Snap/AppImage pada dasarnya tidak baik
  • Menyanggah hal itu dengan mengatakan bahwa pengembang yang langsung membuat aplikasi adalah pihak yang paling cocok menangani manajemen paket. Terutama untuk perangkat lunak proprietari, secara hukum hak distribusi dan packaging bersifat eksklusif. Bahkan untuk open source pun, campur tangan orang di luar tim inti dalam packaging dianggap menimbulkan bug yang tidak perlu, keterlambatan rilis, dan masalah baru. Ia menginginkan pembaruan yang cepat dan terbaru serta perangkat lunak murni tanpa modifikasi packaging. Menurutnya masalahnya adalah Flatpak mencoba mengambil terlalu banyak peran, dan ia juga skeptis terhadap model app store itu sendiri. Di Windows dan macOS, distribusi biner bebas dilakukan tanpa app store, dan keamanan minimum disediakan di level OS melalui hal seperti tanda tangan kode, sehingga sistem packaging pihak ketiga yang dominan dianggap tidak perlu
  • Berpendapat bahwa pengembang aplikasi harus bisa mendistribusikan langsung, dengan mencontohkan pengalaman instalasi yang sederhana di Windows. Menurutnya sulit bagi maintainer untuk memiliki skala yang cukup guna mendukung semua distribusi, dan ini menjadi hambatan perkembangan desktop Linux
  • Menunjukkan bahwa upaya harus melakukan packaging satu per satu untuk banyak distribusi justru membuatnya makin kehilangan makna
  • Ada pendapat bahwa tidak realistis jika semua perangkat lunak di dunia dikemas oleh distribusi
  • Dari sudut pandang bahwa distribusi tidak pandai melakukan packaging aplikasi, ia senang melihat adopsi Flatpak meningkat dan berpikir pengembang harus bisa mendistribusikan aplikasinya sendiri dengan mudah tanpa perantara
• Setuju dengan kritik bahwa Flatpak masih terus memakai PulseAudio dan tertinggal dalam adopsi PipeWire. Karena PulseAudio menyatukan izin speaker dan mikrofon sehingga tidak bisa dipisah, memberi izin output suara ke aplikasi secara otomatis juga memungkinkan akses ke mikrofon, yang dianggap sebagai celah keamanan besar
  • Berpendapat bahwa pengguna Linux sering mengejek kesalahan desain atau kurangnya kebebasan di Windows/Mac, tetapi masalah desain mendasar seperti ini juga harus diakui. Menurutnya ekosistem Linux cenderung membiarkan masalah tetap ada tanpa kejelasan pihak yang bertanggung jawab
• Ia memasang VSCode/Codium sebagai Flatpak untuk keperluan debugging Python, tetapi menghabiskan banyak waktu untuk pengaturan debugger akibat masalah izin dan konfigurasi. Pada akhirnya, ketika memasang versi Snap, semua masalah terselesaikan
  • Menurutnya Flatpak cocok untuk aplikasi desktop besar seperti Chrome atau Chromium, tetapi tidak cocok untuk alat sistem
  • Ia juga berbagi pengalaman bahwa versi Flatpak dari Emacs hanya memberinya inefisiensi dan frustrasi
• Saat beralih ke distribusi immutable berbasis Flatpak, ia merasa cocok saat semuanya berjalan baik, tetapi ternyata lebih banyak hal yang tidak berfungsi dari perkiraannya sehingga hasilnya tidak memenuhi harapan. Misalnya menjalankan alat eksternal untuk Godot, berbagai tweak permission, masalah interoperabilitas antarsesama Flatpak seperti Firefox dan KeepassDX, crash pada Flatpak Godot dan Krita, serta lingkungan campuran seperti AppImage/.rpm non-Flatpak. Ia berharap ada lebih banyak inovasi dari Flatpak
• Flatpak dianggap secara struktural tidak memungkinkan packaging aplikasi seperti Tailscale yang membuat antarmuka jaringan virtual. Di macOS, izin jaringan bisa dipecah secara rinci lewat API sehingga Tailscale juga bisa didistribusikan sebagai aplikasi sandbox di Mac App Store
  • Berkat API tersebut, aplikasi sandbox macOS milik Tailscale dapat didistribusikan, sedangkan pada distribusi Linux "atomic" yang bergantung pada Flatpak seperti Silverblue dan Bluefin, penggunaan perangkat lunak jenis ini menjadi sulit
  • Menurutnya Flatpak bermakna untuk aplikasi desktop besar seperti OBS Studio, tetapi untuk Tailscale yang bekerja seperti layanan sistem, paket bawaan distribusi lebih cocok daripada Flatpak. Di Arch Linux, itu tersedia sebagai paket resmi
  • Ada jalan memutar di Flatpak seperti flatpak-spawn dan polkit-exec, tetapi jika demikian perlindungan sandbox pada dasarnya hampir ditinggalkan
  • Ia mencurigai bahwa upaya menyelesaikan sekaligus sistem izin rinci dan packaging di lapisan paling atas Linux menjadi terlalu kompleks, dan mungkin inilah sebab stagnasi Flatpak atau kelelahan pengembang. Karena Linux modern tidak punya sistem perizinan dasar yang fundamental, ia menilai tugas yang lebih mendesak daripada pengaturan izin yang sempurna adalah distribusi perangkat lunak, packaging, dan sistem pembaruan
  • Ada pendapat bahwa hal seperti Tailscale seharusnya memakai sysext (ekstensi sistem), dan Flatpak tidak cocok untuk itu
• Terkait usulan distribusi via Flatpak, ia mengembangkan aplikasi KmCaster berbasis Java dan menerima permintaan untuk mem-porting-nya ke Flatpak, tetapi yang dirasakan hanya beban tambahan: dua metode instalasi, pengelolaan statistik unduhan, kepercayaan terhadap repositori pihak ketiga, bertambahnya package manager baru, dan duplikasi repositori. Secara praktis ia merasa tidak ada keuntungan nyata
  • Meski begitu, ia juga menyebut sisi positif Flatpak seperti kemudahan penggunaan di distribusi immutable, tidak perlunya lagi mengelola versi Java, visibilitas pencarian di Flathub, dan pembaruan otomatis
• Ia bukan maintainer atau pengembang open source, tetapi merasa sulit memahami mengapa begitu banyak distribusi Linux yang semuanya punya masalah manajemen paket yang sama tidak bisa bersatu dan fokus memperbaiki serta memasyarakatkan Flatpak
  • Namun ada pendapat bahwa karena setiap distribusi memiliki cara distribusi yang berbeda-beda, sulit untuk disatukan menjadi satu, dan beragam pilihan justru merupakan kelebihan ekosistem open source. Secara pribadi ia lebih menyukai package manager sistem tradisional
  • Dengan logika itu, seolah hanya GNOME yang boleh ada, padahal keberagaman komunitas dan keberagaman pengambilan keputusan itu penting
  • Flatpak sama sekali tidak berguna baginya, dan ia tidak ingin dipaksa berkontribusi pada perangkat lunak yang tidak ia gunakan