Flatpak'in Geleceği

• Flatpak şu anda geliştiriciler ve kullanıcılar arasında popülerlik kazanıyor, ancak projenin kendisinde gelişimin duraksaması sorunu öne çıkıyor
• Çekirdek geliştiricilerin ayrılması ve darboğazlar nedeniyle yeni özelliklerin eklenmesi ve kod incelemeleri gecikiyor
• OCI image desteği, izinlerin daha ayrıntılı hale getirilmesi ve ses erişim kontrolü gibi çeşitli güçlendirme özellikleri önerildi, ancak bunların fiilen hayata geçirilmesi yavaş ilerliyor
• Projenin uzun vadeli gelişimi için kapsayıcı teknoloji standardı (OCI) benimsenmesi ve Rust tabanlı yeniden uygulama seçenekleri tartışılıyor
• Portal iyileştirmeleri, sürücü desteği ve ağ sandboxing'i gibi temel zorlukların çözümü, Flatpak'in büyümesi için kritik önem taşıyor

---

Flatpak projesine genel bakış ve mevcut durum

• Flatpak, 2007'den itibaren benzer projelerle başladı; 2015'te ilk kez XDG-App olarak yayımlandı ve 2016'da adı Flatpak olarak değiştirildi
• Komut satırı aracı, build araçları ve runtime bileşenleri sunar; cgroups, namespaces, bind mount, seccomp, Bubblewrap gibi teknolojilerle uygulama yalıtımı (sandboxing) sağlar
• Temel dağıtım yöntemi olarak OSTree kullanır; son dönemde OCI image desteği de eklenerek Fedora gibi ortamlarda kullanılmaktadır
• Flathub uygulama mağazasının büyümesi ve dağıtımlar tarafından benimsenmesi açısından başarılı olsa da, proje içinde aktif geliştirmede yavaşlama yaşanıyor

Geliştirme tıkanıklığı ve başlıca nedenler

• Bakım ve güvenlik yamaları düzeyinde faaliyet sürse de, büyük yeni özelliklerin geliştirilmesi ve kod incelemeleri uzun süredir durgun durumda
• Önemli geliştiricilerin ayrılması (Larsson vb.) nedeniyle inceleme yapacak kişi sayısı azaldı; bu da yeni katkıcıların katılımını ve büyük değişiklikleri zorlaştıran bir ortam yarattı
• Red Hat gibi kurumların katkı verdiği Flatpak preinstall özelliği de inceleme gecikmeleri ve sorumluların ayrılması nedeniyle entegrasyonun tamamlanmasına kadar aylar süren tekrar eden sorunlar yaşadı

OSTree ve OCI image desteği

• OSTree Flatpak'te başarılı şekilde kullanıldı, ancak standart dışı/sınırlı araçlar sorunu nedeniyle bakım dışında aktif bir gelişim göstermiyor
• OCI, kapsayıcı image'ları için geniş bir araç ekosistemine sahip olduğundan, Flatpak geliştirme ekibi açısından benimsenmesi bakım yükünü ve mükerrer çabayı azaltabilir
• zstd:chunked gibi verimli sıkıştırma biçimlerine destek de yeni PR'larla önerildi, ancak gecikmiş ve birleştirilmemiş durumda kalmaya devam ediyor

İzin yönetimi ve sandbox'ın daha ayrıntılı hale getirilmesi

• Flatpak, sandboxing yoluyla sistem erişimini kısıtlamaya odaklanır; güncel Flatpak sürümlerinde izinlerin ayrıntılılaştırılması (ör. --device=input) desteklenmektedir
• Linux dağıtımları arasında Flatpak sürümleri farklı olduğundan, yeni izin özelliklerinin yaygın olarak kullanılamaması ve sürüm uyumluluğu sorunları ortaya çıkıyor
• Ses izinleri konusunda PulseAudio'nun sınırlamaları nedeniyle oynatma ve kayıt ayrımını yapmak zor; bunun için PipeWire gibi çözümlerle iyileştirme gereği dile getiriliyor
• İç içe sandboxing desteğinin yetersizliği nedeniyle web tarayıcıları gibi uygulamalar içeride ayrı bir sandbox kullanamıyor

D-Bus ve ağ sandboxing'i

• Flatpak, D-Bus'a doğrudan erişmek yerine xdg-dbus-proxy üzerinden filtrelenmiş iletişim modelini kullanır
• Wick, filtreleme politikasını D-Bus broker'a taşıyarak politikanın dinamik uygulanması ve cgroup tabanlı erişim kontrolünü hayata geçirme niyeti gösteriyor
• Ağ namespace'lerinin eksik uygulanması nedeniyle localhost portlarının açığa çıkması durumunda Flatpak uygulamaları arasında istenmeyen iletişim olasılığı bulunuyor (gerçek örnek: AusweisApp)
• NVIDIA sürücüleri her runtime için ayrı sunulduğundan aşırı ağ trafiğine ve güncelleme zorluklarına yol açıyor. Valve'ın modeli örnek alınarak host ile paylaşım ve statik derleme gibi seçenekler değerlendiriliyor

Portal kullanımı ve iyileştirme ihtiyacı

• Portal, D-Bus tabanlı harici kaynak erişim API'si olarak dosya, yazdırma, URL ve benzeri birçok rol üstlenir
• Documents portal gibi bileşenler dosya bazında etkili olsa da, GIMP ve Blender gibi kullanım yoğunluğu yüksek uygulamalarda aşırı ayrıntılı izin modeli sınırlayıcı hale geliyor
• Parola otomatik doldurma, FIDO anahtarları ve konuşma sentezi gibi yeni API'ler önerilirken, geliştirme zorluğunu azaltma ve Rust ile yeniden uygulama fikirleri de tartışılıyor

Flatpak'in geleceği (Flatpak-next)

• Gelecekte Flatpak'in artık geliştirilmediği bir senaryo varsayılarak, OCI ekosistemine büyük ölçekli geçiş (image, registry, araçlar, politikalar vb. geniş kullanım) uzun vadeli perspektifte tartışılıyor
• Rust tabanlı yeniden uygulama gibi kapsayıcı ekosisteminde birleşme adımlarının yönetim yükü, bakım ve genişletilebilirlik açısından avantaj sağlayabileceği düşünülüyor

Soru-cevap özeti

• OCI'ye geçişte mevcut Flatpak uygulamalarının nasıl ele alınacağı sorusuna, Flathub'un build otomasyonu sayesinde bunun büyük bir sorun olmayacağı yanıtı verildi
• OCI registry'lerinde metadata eksikliği konusunda, image dışı veri için standartlar hazırlanmakta olduğu, ancak gerçek hayata geçirilmesi için geliştirme ve entegrasyon gerektiği belirtildi
• Doğrudan PipeWire desteği planları hakkında, teknik tartışmaların sürdüğü ve yönelimin PipeWire politika tabanlı entegrasyona doğru olduğu ifade edildi

Sonuç

• Flatpak, dağıtım ve sandboxing için standart bir platform haline gelmiş olsa da, inceleme ve yeni geliştirmelerde durgunluk, izin/ağ/sürücü sorunları ve gelecekteki standart geçişi gibi çeşitli iyileştirme alanlarıyla karşı karşıya
• OCI tabanlı kapsayıcı teknolojileri ve Rust kullanımı, Flatpak'in gelişimi için yeni bir itici güç olma potansiyeli taşıyor
• Başlıca noktalar inceleyici sayısının artırılması, standardizasyon, ekosistemin genişletilmesi ve kullanıcı deneyiminin iyileştirilmesi olarak özetlenebilir

[ndrgrd]

Erişimi tamamen engellemek yerine, hangi dizine erişildiğini açıkça gösteren bir yaklaşımın daha iyi olduğunu düşünüyorum.

Android bu açıdan fena değil, ancak burada izinler fazla geniş gruplandırıldığı için gerekli olmayan düzeydeki izinleri de birlikte vermek gerekiyor...

[GN⁺]

Hacker News görüşü

• Wick’in sunumunda Flatpak projesinin dışarıdan bakınca iyi gidiyor gibi görünse de gerçekte aktif geliştirme yapılmadığının vurgulandığı paylaşılıyor; güvenliğin korunması ve basit bakım sürse de neredeyse hiç yeni özellik eklenmemesi, birçok özellik önerisi (Merge Request) açılsa da bunları inceleyen kimsenin olmaması nedeniyle ilerleme sağlanamaması sorun olarak görülüyor. Özellikle RHEL 10’da masaüstü paketleri sunmayı bırakıp paketlerin Flathub üzerinden kurulmasını önermesiyle Red Hat’in rolünün daha da önemli hale geldiği düşünülüyor. Red Hat Flatpak’i gerçekten doğru bir alternatif yapmak istiyorsa daha fazla kaynak ayırması isteniyor. Wick’in, Flatpak sürümlerine göre yeni izinlerin desteklenip desteklenmemesi değiştiği için geriye dönük uyumluluğun gerekli olduğu yönündeki tespitine katılınıyor. Kişi, Flathub’da oyun dağıtırken ses ve kontrolcü izinleri, --device=input desteğinin olmaması, yalnızca hoparlörü açıp mikrofonu kapatma gibi ayrıntılı izin ayarlarının yapılamaması gibi sorunları bizzat yaşadığını aktarıyor.
  • Red Hat’in başlangıçta Firefox ve Thunderbird’ü RHEL 10’da yalnızca Flatpak olarak dağıtmayı planladığı, ancak fiilen GA sürümünden sonra rpm paketleri de sunduğu örneği veriliyor. Native Messaging desteğinin olmaması, merkezi politika dağıtımının yapılamaması, masaüstü entegrasyonu sorunları gibi çeşitli nedenlerin birlikte etkili olduğu belirtiliyor.
• Flatpak ilk başladığında ana geliştiriciyle bizzat tanışıp tasarım felsefesi üzerine tartıştığını paylaşan biri, Flatpak’te izinlerin paket adına bağlanmasının ve örnek başına ayrım olmamasının yapısal sorun olduğunu anlatıyor. Yani aynı Flatpak uygulamasını birden fazla örnek olarak açıp her birini farklı izinlerle ayırmak mümkün değil; örneğin Documents altındaki yalnızca belirli dizinlere erişim verme gibi bir ayrım yapılamıyor. Bunun MS, Apple App Store ve macOS’ta da benzer olduğunu, yani dünyanın genel olarak yanlış tasarlanmış olduğunu düşünüyor. Örneğin bir LibreOffice belgesinde RCE (uzaktan kod çalıştırma) olsa bile diğer belgelere erişimin engellenmesi gerektiğini; üretici güvenliğe önem vermese bile Flatpak sandbox’ının güvenliği sağlaması gerektiğini savunuyor.
  • Bu güvenlik amacıyla artan karmaşıklığa eleştirel yaklaşan bir görüş de var. PC’nin kişiye ait olduğu, bu yüzden örnek başına izinler, sandbox, dosya paylaşımı kısıtları gibi şeylerin gereksiz olduğu ve “her şey dosyadır” anlayışının korunmasının istendiği söyleniyor. Örnek olarak Thunderbird ve Firefox’un /tmp dizinine erişememesi nedeniyle ekleri kaydetmenin ya da başka uygulamalarda açmanın aşırı derecede zahmetli hale geldiği sandbox ortamından şikâyet ediliyor. Bilgisayarın sahibinin geliştirici değil kullanıcı olması gerektiği, bu kadar aşırı güvenliğin üretkenliği düşürdüğü savunuluyor ve durum Useless Machine ile kıyaslanıyor.
  • Flatpak geliştiricilerinin de bu sorunu anlamış olabileceği öne sürülüyor. Flatpak teknik olarak kusursuz bir modeli seçmiş olsaydı, özellikle çok platformlu uygulama geliştiricileri için giriş eşiği fazla yükselecek ve Flatpak’in kendisi yaygınlaşamayacaktı deniyor.
  • Örnek başına izin modelinin çok cazip olduğu, ancak yapılandırmalar (git config, yazı tipi klasörleri vb.) için tüm örneklerin aynı erişim hakkına sahip olmasını sağlayan seçenekli hibrit bir yaklaşımın daha pratik olacağı öneriliyor.
  • İşletim sisteminin genelinin yeniden tasarlanarak çalışan her örneğe ayrı yetenekler (capabilities), disk kotası, loglama, proxy, ince taneli izin ayrımı gibi özellikler verilmesinin daha doğru olduğu; bunun yalnızca Flatpak’e özgü bir mesele olmadığı savunuluyor.
  • QubesOS gibi hipervizör tabanlı sandbox’larla çok katı ayrım isteyen ileri düzey ya da güvenliğe duyarlı kullanıcılar için örnek bazlı ayrımın iyi olduğu, ancak çoğu yalıtım işinin uygulama içinde yapılmasının daha sezgisel olduğu söyleniyor. Web tarayıcısı sandbox’ında olduğu gibi Flatpak’in de iç içe sandbox desteği sunmasının ideal olacağı, fakat şu anda bunun desteklenmediği belirtiliyor. Kod imzalama ile sandbox ilişkisinin kurulması, UID namespace’leri gibi oldukça karmaşık sorunların da var olduğu ekleniyor.
• Uzun süredir Flatpak’in hevesli bir kullanıcısı olduğunu söyleyen biri, bunun yenilikçi olduğunu ve tüm Linux dağıtımlarında güncel uygulamaları kolayca kullanmayı sağladığını; ancak birkaç yıldır değişim olmayınca ilgisinin giderek azaldığını anlatıyor. Şu anda ihtiyaçlarının çoğunu AUR ile karşıladığını ve Flatpak’in durgunluğunu üzücü bulduğunu belirtiyor.
  • Kullanıcı olarak kolay olması dışında Flatpak ile pek iyi deneyim yaşamadığını; tema, imleç, dosya seçici, izinler, Drag&Drop gibi pek çok entegrasyon sorunu bulunduğunu, özellikleri kullanmak için ek araçlara ihtiyaç duyulduğunu söylüyor. UX düşük kaldığı sürece sandbox gibi güvenlik faydalarının anlamsız olduğunu, Linux’ta ikili taşınabilirliği sorunu olmasaydı Flatpak’e ihtiyaç olmayacağını düşünüyor.
  • Fedora + GNOME + Flatpak birleşiminin bir dönem çok yenilikçi geldiğini ama sonrasında yeniden Arch’a döndüğünü; Arch depolarının çok daha zengin hale geldiğini ve AUR’ye neredeyse hiç ihtiyaç duymadığını aktarıyor.
  • Çok sayıda paket yönetmiş birine makedeb deneyimi sorulurken, makedeb�in PKGBUILD tabanlı olduğu için taşınabilirliğinin yüksek olduğu ve neden daha yaygın bilinmediğinin merak edildiği belirtiliyor.
• Drew DeVault’un “paketlemeyi dağıtımlar yapmalı” görüşüne yüzde 100 katılınmasa da, uzun değerlendirme yazısı ve ilgili bağlantı paylaşılıyor. Topluluğun (dağıtımın) kullanıcıyı temsil ederek paketleri yönetmesi modelinin doğru olduğu; Flatpak/Snap/AppImage gibi dağıtım dışı paketleme modellerinin temelde iyi olmadığı savunuluyor.
  • Buna karşı çıkan bir görüş ise, uygulamayı doğrudan geliştiren kişinin paket yönetimi için en uygun kişi olduğunu söylüyor. Özellikle kaynak kodu kapalı yazılımlarda dağıtım ve paketleme hakkının hukuken zaten tek elde olduğu, açık kaynakta bile çekirdek ekip dışındaki birinin keyfi paketleme müdahalesinin gereksiz hatalar, sürüm gecikmeleri ve yeni sorunlar doğurduğu düşünülüyor. Hızlı ve güncel güncellemeler, paketleme sırasında değiştirilmemiş saf yazılım isteniyor. Sorunun Flatpak’in çok fazla rol üstlenmeye çalışması olduğu; uygulama mağazası modelinin kendisine de kuşkuyla bakıldığı ifade ediliyor. Windows ve macOS’ta uygulama mağazası olmadan da ikili dağıtımın serbest olduğu ve temel güvenliğin kod imzalama gibi OS düzeyinde sağlandığı, üçüncü taraf paketleme sistemlerinin yön verici olmasının gereksiz olduğu savunuluyor.
  • Uygulama geliştiricilerinin doğrudan dağıtım yapabilmesi gerektiği ve Windows’taki basit kurulum deneyiminin buna örnek olduğu söyleniyor. Bakımcıların tüm dağıtımları destekleyecek ölçeğe sahip olmasının zor olduğu ve bunun Linux masaüstünün gelişimini yavaşlattığı düşünülüyor.
  • Birden çok dağıtıma tek tek paket hazırlama zahmetinin yüzünden bunun anlamının daha da azaldığı belirtiliyor.
  • Dünyadaki tüm yazılımları dağıtımların paketlemesinin gerçekçi olmadığı görüşü dile getiriliyor.
  • Dağıtımların uygulama paketleme işini iyi yapamadığını düşünen biri, Flatpak’in daha fazla benimsenmesinden memnun olduğunu; geliştiricilerin aracı olmadan kendi uygulamalarını kolayca dağıtabilmesi gerektiğini savunuyor.
• Flatpak’in hâlâ PulseAudio kullanması nedeniyle PipeWire’a geçişte geride kaldığı, PulseAudio’nun hoparlör ve mikrofon izinlerini birleştirip ayıramadığı; yani bir uygulamaya ses çıkışı izni verildiğinde mikrofon erişiminin de fiilen açılabildiği, bunun ciddi bir güvenlik açığı olduğu eleştirisine katılım var.
  • Windows/macOS tasarım hataları ya da özgürlük eksikliğiyle dalga geçen Linux kullanıcılarının sık görüldüğü, ama bu tür temel tasarım sorunlarının da kabul edilmesi gerektiği söyleniyor. Linux ekosisteminin sorumluluğu netleştiremeden sorunları ortada bırakma eğiliminde olduğu düşünülüyor.
• VSCode/Codium’u Python hata ayıklama amacıyla Flatpak olarak kurduğunu, fakat izin ve ayar sorunları yüzünden debugger kurulumunun çok uzun sürdüğünü; sonunda Snap sürümünü kurunca tüm sorunların çözüldüğünü yaşayan biri var.
  • Flatpak’in Chrome, Chromium gibi büyük masaüstü uygulamaları için uygun ama sistem araçları için uygun olmadığını düşünüyor.
  • Emacs’in Flatpak sürümünün verimsizlik ve hayal kırıklığından başka bir şey getirmediği deneyimi de paylaşılıyor.
• immutable distro üzerinde Flatpak temelli bir düzene geçildiğinde işler yolundayken iyi hissettirdiği, ancak beklenmedik derecede çok şeyin çalışmaması nedeniyle beklentileri karşılamadığı anlatılıyor. Örneğin Godot için harici araç çalıştırma, çeşitli izin ayarlamaları, Flatpak’ler arası birlikte çalışma sorunları (örneğin Firefox ile KeepassDX), Godot ve Krita Flatpak’lerinde çökme, Flatpak olmayan AppImage/.rpm gibi heterojen ortamlar gibi pek çok sıkıntıdan söz ediliyor. Flatpak’ten daha fazla yenilik beklendiği söyleniyor.
• Flatpak’in, Tailscale gibi sanal ağ arayüzü oluşturan uygulamaları paketlemeye uygun bir yapıda olmadığı belirtiliyor. macOS’un API’ler üzerinden ağ izinlerini daha ayrıntılı verebildiği ve bu sayede Tailscale’in Mac App Store’da sandbox’lı uygulama olarak dağıtılabildiği söyleniyor.
  • Bu API sayesinde Tailscale’in macOS için sandbox uygulaması olarak dağıtımı mümkünken, Silverblue, Bluefin gibi Flatpak’e dayanan “atomic” Linux dağıtımlarında bu tür yazılımların kullanımının zor olduğu ifade ediliyor.
  • OBS Studio gibi masaüstünde çalışan büyük uygulamalar için Flatpak’in anlamlı olduğu, fakat sistem servisi gibi çalışan Tailscale için Flatpak yerine dağıtımın yerel paketinin daha uygun olduğu düşünülüyor. Arch Linux’ta bunun resmî paket olarak bulunduğu da ekleniyor.
  • Flatpak içinde flatpak-spawn, polkit-exec gibi dolaylı yollarla bunun aşılabildiği, ancak bu durumda sandbox korumasından büyük ölçüde vazgeçilmiş olduğu belirtiliyor.
  • Linux’un en üstüne hem ayrıntılı izin sistemi hem de paketlemeyi aynı anda oturtmaya çalışmanın aşırı karmaşık olduğu; Flatpak’in durgunluğu ya da geliştirici tükenmişliğinin de bundan kaynaklanabileceği şüphesi dile getiriliyor. Modern Linux’ta köklü bir izin sistemi olmadığı için, kusursuz izin yapılandırmasından önce asıl acil konunun yazılım dağıtımı, paketleme ve güncelleme sistemi olduğu yönünde daha gerçekçi bir bakış sunuluyor.
  • Tailscale gibi şeylerin sysext (sistem uzantısı) olarak ele alınması gerektiği ve Flatpak’in buna uygun olmadığı görüşü de var.
• Flatpak ile dağıtım önerileri bağlamında, Java tabanlı KmCaster uygulamasını geliştiren biri Flatpak’e taşıma talebi aldığını; ama iki ayrı kurulum yöntemi, indirme istatistiklerini takip etme, üçüncü taraf depolara güven, yeni bir paket yöneticisi daha, depo tekrarları gibi ek yükler dışında anlamlı bir fayda görmediğini söylüyor.
  • Buna rağmen Flatpak’in olumlu yanları olarak immutable distro üzerinde kullanım kolaylığı, Java sürüm yönetimi ihtiyacını ortadan kaldırması, Flathub’da görünürlük sağlaması ve otomatik güncellemeler sayılıyor.
• Açık kaynak bakımcısı ya da geliştiricisi olmadığını söyleyen biri, bu kadar çok Linux dağıtımının aynı paket yönetimi sorunuyla uğraşmasına rağmen güçlerini birleştirip Flatpak’i geliştirme ve yaygınlaştırma yönünde odaklanmamasını anlayamadığını belirtiyor.
  • Buna karşılık, her dağıtımın “distribution” anlayışının farklı olduğu için tek bir yapıda birleşmenin zor olduğu; çeşitli tercihlerin açık kaynak ekosisteminin güçlü yanı olduğu ve kişisel olarak geleneksel sistem paket yöneticisinin daha çok sevildiği söyleniyor.
  • Bu mantıkla giderse yalnızca GNOME’un var olması gerekeceği; oysa topluluk çeşitliliği ve karar alma çeşitliliğinin önemli olduğu savunuluyor.
  • Flatpak’in kendisi için hiçbir faydası olmadığı, kullanmadığı bir yazılıma katkı yapmaya zorlanmak istemediği de söyleniyor.