Flatpak akan bergantung pada systemd

• Flatpak selama ini menonjolkan keunggulan “membangun aplikasi untuk semua distro”, tetapi pada versi mayor berikutnya ada kemungkinan besar akan muncul ketergantungan pada systemd
• Flatpak Next atau Flatpak 2.0 lebih menyerupai penulisan ulang untuk melampaui keterbatasan desain yang sudah berumur puluhan tahun pada 1.x saat ini, dan masih berada pada tahap perencanaan
• Layanan baru systemd-appd akan berperan penting dengan menyimpan pengenal aplikasi dan izin, lalu memungkinkan komponen lain untuk menanyakannya, serta membuka jalan bagi subsandboxing
• Untuk distro non-systemd, sempat ada ruang bagi implementasi daemon independen seperti elogind, tetapi setelah kontroversi membesar, tampaknya kemauan pengembang untuk mengakomodasi hal itu melemah
• Jika ketergantungan pada systemd menjadi lebih ketat, penggunaan Flatpak di distro seperti Void, Guix, dan Alpine bisa menjadi sulit, dan netralitas lintas distro juga dapat melemah

---

Kemungkinan perubahan pada netralitas lintas distro Flatpak

• Situs web Flatpak menonjolkan “Build for every distro: create one app and distribute it to the entire Linux desktop market.” sebagai keunggulan utamanya, dan daftar distro yang didukung juga mencakup Void Linux, Guix, dan Alpine, yang memakai sistem init selain systemd
• Saat ini Flatpak tidak memedulikan sistem init yang digunakan pengguna, tetapi pada versi mayor berikutnya kemungkinan besar akan muncul ketergantungan pada systemd
• Jika perubahan ini benar-benar diterapkan, isu utamanya adalah apakah Flatpak masih bisa terus disediakan di distro yang tidak menggunakan systemd

Flatpak Next dan arah perancangan ulang

• Arian Vovk dan Sebastian Wick membawakan presentasi tentang masa depan Flatpak di Linux App Summit
• Versi Flatpak saat ini tetap akan terus ditingkatkan, tetapi semakin sulit untuk mengakali keterbatasan dari desain yang sudah berumur puluhan tahun
• Pekerjaan yang disebut Flatpak Next atau Flatpak 2.0 pada praktiknya mendekati penulisan ulang yang mencerminkan pengalaman yang terkumpul sejak Flatpak 1.x
• Desain baru ini direncanakan untuk memanfaatkan teknologi dan gagasan modern yang telah mapan sejak rancangan awal Flatpak
• Isi presentasinya masih berada pada tahap perencanaan, dan karena belum ada satu baris kode pun yang ditulis, hasil akhirnya bisa berubah besar selama pengerjaan dalam beberapa tahun ke depan

systemd-appd dan perpindahan pengelolaan izin

• Perubahan inti dalam arah pengembangan Flatpak adalah memindahkan pengelolaan izin dari dalam Flatpak ke lapisan layanan
• Layanan baru systemd-appd akan memberi aplikasi sebuah pengenal, menyimpan izin, dan memungkinkan komponen lain dalam sistem untuk menanyakan data tersebut
• Struktur ini memungkinkan berbagai fitur, dan khususnya subsandboxing disebut sebagai fungsi yang penting
• Rencana saat ini adalah menghadirkan fungsi ini ke versi Flatpak yang ada sekarang, yang akibatnya akan membuat Flatpak bergantung pada systemd

Ruang bagi distro non-systemd

• Menurut penjelasan Vovk, ada niat untuk “sangat mempertimbangkan” distro dan pengguna yang tidak memakai systemd
• Model yang dapat dibayangkan mirip dengan cara systemd-logind dipisahkan menjadi daemon tersendiri, elogind, sehingga distro dengan sistem init lain tetap bisa menggunakan lingkungan desktop yang bergantung pada systemd-logind
• Pengembang Flatpak juga tampaknya berusaha menyisakan ruang praktis semaksimal mungkin agar implementasi daemon independen serupa dapat dibuat untuk systemd-appd
• Jika pendekatan ini dipertahankan, Flatpak mungkin masih dapat terus tersedia di distro yang tidak memakai systemd

Meluasnya kontroversi dan perubahan respons pengembang

• Pengguna distro seperti Void atau Alpine menyuarakan kekhawatiran bahwa jika Flatpak sangat bergantung pada systemd, maka ia mungkin tidak lagi berjalan di sistem mereka
• Pertanyaan justru membanjiri orang yang tidak terlibat secara teknis dalam pengembangan Flatpak, dan tanggapannya dalam beberapa kasus tidak membantu, menghina, dan provokatif
• Banyak orang lalu salah paham dan mengira ia terlibat dalam pengembangan Flatpak, sehingga pertanyaan yang serius dan bersahabat bercampur dengan reaksi keras bernada anti-systemd, yang memperburuk situasi
• Akibatnya, para pengembang Flatpak menunjukkan respons bahwa mereka tidak ingin menghabiskan waktu untuk mengakomodasi distro dan pengguna yang tidak memakai systemd
• Jika arus ini berlanjut, ketergantungan pada systemd bisa menjadi lebih ketat, dan implementasi daemon independen yang meniru fungsi systemd-appd juga bisa menjadi jauh lebih sulit daripada yang semula diperkirakan

Dampak dan makna yang diperkirakan

• Dalam situasi saat ini, ada kemungkinan besar bahwa Flatpak akan memiliki ketergantungan pada systemd dalam beberapa tahun ke depan
• Ada pula kemungkinan bahwa perhatian untuk memungkinkan pembuatan daemon independen pengganti fungsi systemd-appd di distro non-systemd akan hilang
• Jika itu terjadi, Flatpak akan semakin sulit mengklaim netralitas lintas distro sebagai kemampuan untuk mendistribusikan satu aplikasi ke semua distro
• Karena Flatpak adalah alat yang benar-benar dibutuhkan terlepas dari sistem init yang digunakan pengguna, perubahan ini akan berdampak langsung pada cakupan distribusi aplikasi desktop Linux

[GN⁺]

Opini di Lobste.rs

• Saya tidak paham kenapa orang begitu membenci systemd. Secara pribadi, saya melihatnya menyediakan fitur yang berguna lewat API yang mudah ditangani serta manajemen dependensi·konflik yang masuk akal
  Pihak yang membenci systemd sering kali hanya memberi alasan yang kabur seperti “tidak seperti Unix”, “terlalu tersentralisasi”, atau “format file systemd-journald bukan teks biasa”
  Kalau menentangnya, saya ingin mendengar alasan yang spesifik, solusinya, dan kenapa sistem init lain lebih baik. Dengan begitu saya bisa menjelaskan kenapa skrip rc adalah hack yang sangat berantakan

  • Sebagian besar perdebatan Mastodon yang ditautkan pada dasarnya lebih dekat ke penolakan terhadap sentralisasi daripada benar-benar penolakan terhadap systemd. Jika Flatpak jadi bergantung pada systemd, keluarga Linux yang memakai sistem init lain akan kehilangan akses ke flatpak
    Filosofi Linux, setidaknya bagi saya, pada dasarnya adalah soal pilihan, dan jika Flatpak mewajibkan sistem init tertentu, maka pilihan pengguna saat menyusun sistem demi mendapatkan hasil yang diinginkan jadi berkurang
  • Saya memakai systemd dengan baik-baik saja, tetapi untuk kasus seperti Flatpak saya bisa memahami penolakannya. Flatpak pada dasarnya adalah sesuatu yang “membuatnya bisa berjalan di distro Linux mana pun”, dan ketergantungan pada systemd agak mengurangi kegunaannya
  • Keluhan saya terhadap systemd yang belum terselesaikan kira-kira seperti ini: implementasi journald kurang bagus, tetapi idenya sendiri oke, dan antrian pekerjaan yang menjadi abstraksi nyata dalam pengelolaan unit oleh systemd memiliki kasus tepi aneh yang tidak terdokumentasi atau sulit ditemukan
    Seharusnya lebih mudah dimasukkan ke image kontainer, dan systemd pengguna seharusnya memiliki akses API baca ke instance sistem sehingga setidaknya bisa menjadwalkan unit dengan hal-hal seperti After, Requires
    Meski begitu, saya tetap menganggapnya sebagai hal terbaik yang terjadi pada Linux sejak penghapusan HAL, dan saya bahkan pernah menjabat tangan Lennart untuk berterima kasih atas proyek ini
  • Pihak seperti Chimera yang benar-benar mengimplementasikan stack alternatif yang dapat dipercaya justru ramah dan rendah hati tanpa menyebarkan FUD. Sebaliknya, gerombolan kemarahan online secara terang-terangan tidak punya solusi dan tidak akan punya solusi ke depan
    Yang secara efektif diklaim para “penentang” ini lebih dekat pada gagasan bahwa solusinya sendiri tidak boleh ada. Mereka bertingkah seperti HOA-nya Linux, dan saya melihatnya sebagai politik reaksioner yang menghambat kemajuan sistem yang benar-benar solid, bisa dipakai, dan kompetitif untuk menyingkirkan sistem operasi proprietari
  • Saya tidak membenci systemd jika hanya dipakai pada sistem yang tujuannya menyediakan halaman web atau menampilkan halaman web lewat browser GUI. Saya juga tidak masalah menulis unit systemd langsung untuk deployment ke VPS, dan kalau itu SysV init atau upstart pun saya mungkin tidak akan banyak keberatan
    Tetapi di laptop, yang saya inginkan berbeda. Saya punya pandangan sendiri tentang bagaimana lingkungan pribadi saya harus bekerja, saya juga menginginkan fitur kenyamanan yang biasanya tidak diinginkan pengguna Linux umum, dan saya tidak ingin hal-hal yang tidak saya minta secara eksplisit terjadi. Saya jauh lebih membenci “usaha untuk membuat sesuatu tidak terjadi” daripada “usaha untuk membuatnya berjalan”
    Alasan utama saya meninggalkan NixOS karena systemd adalah cakupannya yang terus membesar dan default yang sangat opinionated. Saat manajemen daya dan penanganan login diintegrasikan, perilaku seperti laptop selalu masuk suspend saat tutup layar ditutup harus saya perbaiki lagi setiap saat; perubahan cakupan izin linger merusak nohup dan screen yang diwajibkan POSIX; dan pengelolaan VT yang lebih ketat membuat hal seperti “sekali login lalu menjalankan beberapa instance Xorg” atau “merebut VT” harus didesain ulang dengan cara systemd
    Pada akhirnya saya memutuskan bahwa init minimal sinit tanpa pengawasan layanan lebih baik, lalu menulis sendiri skrip boot shell dan mengimplementasikan sebagian fungsi sistem dalam shell, sebagian lagi dalam Common Lisp. Di laptop, hal seperti PostgreSQL sekali jalan biasanya terus berjalan; kalau berhenti saya bisa menyadarinya; jika restart sudah cukup maka itu sederhana, dan jika tidak cukup maka pengawas layanan pun tidak akan banyak membantu
    Contoh hilangnya kepercayaan termasuk pengalaman pribadi saat journald di HDD tidak menampilkan output meski sudah menunggu beberapa menit dalam kondisi cache dingin, pernah mengalami langsung https://github.com/systemd/systemd/issues/2913, dan fakta bahwa mereka tidak ragu merusak nohup
    Dalam proses pengembangannya juga, sikap pada https://github.com/systemd/systemd/issues/437 yang terasa seperti “kami memberi default yang bagus, tetapi kalau default-nya buruk distro bisa memperbaikinya”, serta sikap seperti http://lists.freedesktop.org/archives/systemd-devel/… yang enggan berkomitmen pada API stabil, menurunkan kepercayaan saya
    Meski begitu, keluhan-keluhan ini sudah lama. Setelah melihat systemd menyelesaikan masalah tertentu sambil menciptakan masalah lain, dan keduanya bukan masalah yang awalnya saya miliki, saya beralih ke skrip shell untuk boot di laptop, dan sekarang biaya untuk mempertahankan keadaan itu sudah terlalu rendah sehingga tidak ada alasan untuk mencoba systemd lagi. Di VPS, saya memakai systemd dalam batas yang familier seperti di Debian

• Yang membuat frustrasi adalah semua ini dimulai oleh orang yang bukan pengembang Flatpak dengan informasi yang keliru, lalu memicu reaksi emosional, dan selama thread aslinya berjalan, ungkapan yang lebih keras terus ditambahkan hingga orang-orang menyerbu reputasi proyek Flatpak dan para pengembangnya
  Karena itu, tidak mengejutkan jika pengembang Flatpak yang sebenarnya ikut terdampak secara emosional dan ingin menjaga jarak dari massa yang marah
  Saya harap semua orang bisa tenang dan tidak membesar-besarkan masalah ini. Jika ada kecurigaan atau kekhawatiran, bicaralah dengan maintainer yang sebenarnya, tunjukkan dukungan bahwa Anda ingin mencari titik tengah, dan tunjukkan bahwa ini adalah insiden terisolasi dari individu tertentu yang tidak mewakili seluruh komunitas
  Sama seperti gagasan untuk bergantung pada systemd juga belum diputuskan dan masih sebatas ide, saya rasa kemungkinan maintainer meninjau ulang dukungan untuk proyek yang lebih beragam juga masih belum tertutup

• Saya berharap kondisinya tetap baik sehingga sistem yang tidak berjalan di atas systemd masih bisa terus didukung. Flatpak dan pendekatan berbasis kontainer lainnya membantu pengguna menjalankan paket yang tidak mudah dibangun di platform target, dan akan bagus jika Flatpak bisa dijalankan di sistem semacam itu saat perangkat lunak tertentu dibutuhkan
  Kontainer juga punya peran serupa, tetapi membuat sesuatu seperti x11docker benar-benar berjalan di konfigurasi yang cukup unik bisa menjengkelkan dan merepotkan

  • Saya sudah lebih dari 10 tahun memakai Void dengan puas. Saya bahkan tidak ingat kapan terakhir kali saya memikirkan sistem init atau integrasi systemd. Terima kasih atas semua kerja keras yang telah dicurahkan untuk Void

• Saya memakai Void di laptop; efisien untuk bekerja dan dokumentasinya juga cukup baik. Terima kasih atas semua kerja keras para pengembang, dan semoga perubahan pada Flatpak tidak menjadi beban yang terlalu besar

• “Inilah Linux modern, dan yang ada hanya systemd.”
  Ini dengan jelas mengingatkan bahwa komunitas Linux lebih mirip WeWork daripada sebuah komunitas. Di sekelilingnya, semua orang digaji dengan bergantung pada keberadaan Red Hat, sementara ada seseorang yang mengutak-atik GNU readline gratis

  • Sulit dibilang bahwa tulisan itu keliru pada bagian ini: bagian yang mengatakan “menarik para anti-systemd fanatik, teoritikus konspirasi Red Hat (dan golongan yang lebih buruk)”

• Pada tahap ini, masih terlalu dini untuk dengan tegas mengatakan “akan menjadi bergantung”, dan itu tampak sangat spekulatif

• Menarik bahwa judulnya jauh lebih tegas daripada isi tulisannya. Banyak komentar jelas hanya bereaksi terhadap judul, dan syukurlah tidak semuanya, tetapi fenomena seperti ini bukan hal baru di internet
  Belakangan ini saya juga sering melihat di lobste.rs orang hanya bereaksi pada judul atau satu kalimat di komentar panjang, dan itu mengkhawatirkan. Biasanya mereka hampir tidak memberi ruang bagi kemungkinan lain selain tafsiran pertama yang muncul di kepala mereka, yang sering kali agresif
  Kalau membaca tulisannya, tampaknya hal serupa juga terjadi dalam diskursus Flatpak 2.0. Sepertinya sempat ada upaya memberi ruang bagi sistem init lain, tetapi diskursus di sekitarnya cepat berubah menjadi bermusuhan sehingga tampaknya pada praktiknya itu ditinggalkan

• Dari sudut pandang pengguna sistem init alternatif, ini benar-benar menjengkelkan. Saya menjalankan satu laptop dengan Alpine Linux, dan selama ini memakai Flatpak untuk menjalankan perangkat lunak yang hanya bekerja di glibc. Perubahan ini akan membuat saya meninggalkan lingkungan itu
  Saya tidak membenci systemd. Semua sistem Gentoo saya berbasis systemd. Hanya saja saya tidak suka cara systemd membuat perangkat lunak bebas dan sumber terbuka makin bergantung pada GNU/Linux

• Ini jelas hal yang baik
  systemd terdiri dari daemon dengan API yang stabil dan terdefinisi dengan baik, jadi saya rasa bagian mana pun dari systemd yang akan menjadi ketergantungan Flatpak dapat diimplementasikan ulang dengan bersih dari nol jika ada yang mau mengerahkan usaha
  Ini hasil terbaik yang mungkin. Fragmentasi berkurang, dan orang-orang dengan kebutuhan yang tidak biasa mendapatkan target yang stabil untuk diimplementasikan ulang

  • Awalnya saya mulai membaca dengan mengira ini satire, ternyata bukan
    API systemd sering kali didefinisikan secara samar di man page, dan karena pihak systemd tidak mengharapkan implementasi lain, API itu juga tidak stabil dua arah ataupun dikelola versinya
    Dalam kasus API soket notify, malah kestabilannya hanya ke satu arah. Penambahan dukungan vsock pada praktiknya merusak daemon yang diimplementasikan tanpa bergantung pada libsystemd. Kerusakan ini tidak banyak diketahui karena vsock terutama dipakai untuk komunikasi antarsystemd melintasi batas virtualisasi. Kalau dirancang dengan benar, itu seharusnya dibuat sebagai ekstensi yang hanya dipakai pada batas tersebut
    Disebut “daemon-daemon”, tetapi pada praktiknya sebagian besar adalah logind dan systemd, dan karena keduanya mengekspos seluruh permukaan API, kemungkinan penggabungannya terbatas. Ini dilakukan lewat beberapa antarmuka DBus, sekarang juga varlink, dan melalui satu pustaka tunggal
    Untuk menggantikan systemd, Anda harus menggantinya secara utuh sambil bersusah payah menyesuaikan model internal agar mengekspos API bergaya systemd, atau terlebih dulu mengurai pilihan desain API systemd lalu membuat lapisan perantara yang menyediakan backend yang bisa dipasang
    Saya sudah menangani masalah ini selama beberapa tahun. Saya menganggap banyak prinsip desain systemd masuk akal, tetapi desain saat ini mendorong kompleksitas yang tidak dibutuhkan kebanyakan orang ke bagian depan. Desain yang lebih modular dan dapat diganti itu mungkin, dan rancangan antarmuka sederhana yang dapat dipisahkan juga relatif mudah dibayangkan atau menggunakan kembali yang sudah ada
    Namun masalahnya adalah perangkat lunak yang memilih bergantung pada API systemd. Agar bisa berjalan dengan hal lain, Anda harus memasukkan patch ke upstream untuk memisahkan dukungan fitur yang terikat pada seluruh libsystemd, atau menambahkan dukungan API individual baru; yang pertama tidak pernah berhasil, dan yang kedua sulit diterima karena beban pemeliharaan untuk API minoritas dan pra-rilis
    Atau Anda bisa hanya mengimplementasikan API yang dipakai perangkat lunak tersebut. Misalnya dengan memakai layanan DBus login1 yang tidak mengimplementasikan sebagian besar API. Tetapi lalu itu bentrok dengan implementasi lain yang mencoba menggantikan bagian lain dari API, dan Anda harus mengimplementasikan tiga varian: API asli yang bersih, API DBus logind/systemd, dan API untuk varlink
    Dalam jangka panjang, router yang mengimplementasikan seluruh API systemd atau logind lalu menghubungkannya ke API terpisah di belakangnya mungkin bisa menjadi solusi. Hanya saja, karena desain saat ini mengandung redundansi yang sangat besar dan kekhususan systemd, membuatnya dengan benar sangat rumit
    Entah itu memang disengaja atau tidak, dari ucapan para pengembang systemd setidaknya ini adalah masalah yang sengaja tidak mereka pedulikan. Sangat sulit membuat pengganti systemd tanpa membangun lapisan perantara yang rumit atau menulis ulang systemd, dan meskipun aplikasi hanya bergantung pada sebagian API yang bisa disediakan sebagai komponen terisolasi, pada praktiknya tetap sulit mengganti hanya satu bagian systemd dengan rapi
  • Apakah anggapan bahwa sebagian dari systemd bisa diimplementasikan ulang dengan bersih dari nol itu benar dalam praktik saat ini? Tulisan itu menyebut elogind sebagai contohnya

• Saya tidak suka cara Red Hat memiliki terlalu banyak kendali atas ekosistem Linux

  • Saya juga, tetapi akhir-akhir ini saya tidak begitu tahu seberapa besar kendali Red Hat atas systemd
  • Ini memang serba dua sisi. Memusatkan kendali itu buruk, tetapi membayar orang agar membuat perangkat lunak bebas dan sumber terbuka itu baik. Dan sebagian besar kendali yang mereka peroleh justru muncul karena mereka membayar orang agar membuat perangkat lunak bebas dan sumber terbuka
    Meski begitu, fakta bahwa Red Hat menerima perangkat lunak bebas agak meredakan kekhawatiran soal pengaruhnya. Kalau melihat teknologi yang mereka akuisisi selama bertahun-tahun, untuk hal-hal yang sebelumnya bahkan tidak punya upstream pun mereka kadang membuat upstream bebas dan sumber terbuka sendiri. Dogtag PKI dan 389 Directory Server sangat terlintas di pikiran
    Secara keseluruhan, saya rasa dampaknya pada ekosistem tidak terlalu buruk, dan lebih sering memajukan daripada merusak

• Saya tidak punya kepentingan langsung dalam perdebatan ini, tetapi tidak ada hal di sini yang meredakan kecemasan tentang kompleksitas dan abstraksi yang tidak perlu yang terus bertambah di sistem Linux
  Linux sedang dengan cepat menjadi Java-nya sistem operasi. Sungguh menyedihkan