Flatpak का भविष्य

• Flatpak इस समय डेवलपर्स और उपयोगकर्ताओं के बीच लोकप्रिय हो रहा है, लेकिन प्रोजेक्ट के भीतर विकास ठहराव की समस्या उभर रही है
• मुख्य डेवलपर्स के हटने और bottleneck के कारण नई सुविधाओं को शामिल करने और code review में देरी हो रही है
• OCI image support, permissions का सूक्ष्म विभाजन, और audio access control जैसी कई सुदृढ़ीकरण सुविधाएँ प्रस्तावित हुईं, लेकिन उनका वास्तविक समावेशन धीमा रहा
• प्रोजेक्ट के दीर्घकालिक विकास के लिए container technology standard (OCI) अपनाने और Rust-आधारित पुनर्प्रयोग पर चर्चा हो रही है
• portal improvements, driver support, network sandboxing जैसी प्रमुख चुनौतियों का समाधान Flatpak की वृद्धि के लिए निर्णायक है

---

Flatpak प्रोजेक्ट का अवलोकन और वर्तमान स्थिति

• Flatpak की शुरुआत 2007 से मिलते-जुलते प्रोजेक्ट्स के रूप में हुई, 2015 में XDG-App के रूप में पहला रिलीज़ आया, और 2016 में इसका नाम बदलकर Flatpak रखा गया
• यह command-line tools, build tools, runtime components प्रदान करता है, और cgroups, namespaces, bind mount, seccomp, Bubblewrap आदि के जरिए application isolation (sandboxing) की संरचना देता है
• OSTree इसकी मूल डिलीवरी विधि है, और हाल के समय में OCI image support भी जोड़ा गया है, जिसका उपयोग Fedora आदि में हो रहा है
• Flathub app store की वृद्धि और distributions द्वारा अपनाए जाने जैसी सफलताओं के बावजूद, प्रोजेक्ट के भीतर सक्रिय विकास में मंदी देखी जा रही है

विकास ठहराव और उसके मुख्य कारण

• maintenance और security patch स्तर की गतिविधियाँ जारी हैं, लेकिन बड़े नए features का विकास और code review लंबे समय से ठहरे हुए हैं
• प्रमुख डेवलपर्स के हटने (जैसे Larsson) से reviewers की कमी हो गई है, जिससे नए contributors का आना या बड़े बदलाव करना कठिन हो गया है
• Red Hat आदि द्वारा योगदान की जा रही Flatpak preinstall सुविधा जैसी चीज़ों में भी review delay और ज़िम्मेदार लोगों के हटने के कारण integration पूरा होने में बार-बार कई महीने लगे हैं

OSTree और OCI image support

• OSTree को Flatpak में सफलतापूर्वक लागू किया गया, लेकिन गैर-मानक और सीमित tooling की समस्या के कारण maintenance से आगे इसमें सक्रिय प्रगति नहीं हो रही
• OCI के लिए container images का व्यापक tooling ecosystem उपलब्ध है, इसलिए Flatpak डेवलपमेंट टीम के नज़रिए से इसे अपनाने पर maintenance burden और duplicate effort कम होने की उम्मीद है
• zstd:chunked जैसे efficient compression formats के समर्थन के लिए नए PR भी प्रस्तावित हुए, लेकिन वे अब भी विलंबित और unmerged स्थिति में हैं

permission management और sandbox का सूक्ष्म विभाजन

• Flatpak sandboxing के ज़रिए system access सीमित करने पर केंद्रित है, और नए Flatpak versions में permissions का सूक्ष्म विभाजन (जैसे --device=input) समर्थित है
• अलग-अलग Linux distributions में Flatpak versions भिन्न होने से नई permission सुविधाओं के व्यापक रूप से लागू न हो पाने और version compatibility की समस्याएँ पैदा होती हैं
• audio permissions के मामले में PulseAudio की सीमाओं के कारण playback और recording को अलग-अलग नियंत्रित करना कठिन है, इसलिए PipeWire आदि के माध्यम से सुधार की ज़रूरत बताई गई है
• nested sandboxing का पर्याप्त समर्थन न होने से web browser जैसे apps अपने भीतर अलग sandbox का उपयोग नहीं कर पाते

D-Bus और network sandboxing

• Flatpak सीधे D-Bus तक पहुँचने के बजाय xdg-dbus-proxy के माध्यम से filtered communication का उपयोग करता है
• Wick ने filtering policy को D-Bus broker में स्थानांतरित कर dynamic policy application और cgroup-आधारित access control लागू करने की इच्छा जताई है
• network namespace implementation के अधूरे होने के कारण localhost port exposure की स्थिति में Flatpak apps के बीच अनचाहा संचार संभव है (वास्तविक उदाहरण: AusweisApp)
• NVIDIA drivers हर runtime के लिए अलग से दिए जाते हैं, जिससे अत्यधिक network traffic और updates में कठिनाई होती है। Valve के मॉडल को देखते हुए host sharing और static compilation जैसे विकल्पों पर विचार हो रहा है

Portal का उपयोग और सुधार की आवश्यकता

• Portal D-Bus आधारित external resource access API है, जो file, print, URL आदि के लिए विभिन्न भूमिकाएँ निभाता है
• Documents portal जैसी व्यवस्थाएँ file-level access के लिए प्रभावी हैं, लेकिन GIMP और Blender जैसे high-usability apps में अत्यधिक सूक्ष्म permission model एक सीमा बन जाता है
• password autofill, FIDO keys, text-to-speech जैसी नई APIs के प्रस्तावों के साथ-साथ, development complexity कम करने और Rust पुनर्प्रयोग के विचार पर भी चर्चा हुई

Flatpak का भविष्य (Flatpak-next)

• भविष्य में यदि Flatpak का विकास रुक जाए, तो OCI ecosystem की ओर बड़े पैमाने पर बदलाव (images, registries, tools, policies आदि के व्यापक उपयोग सहित) पर दीर्घकालिक दृष्टि से चर्चा हो रही है
• Rust-आधारित पुनर्प्रयोग जैसे कदमों के जरिए container ecosystem का एकीकरण होने पर management burden, maintenance, और scalability के लिहाज़ से लाभ की उम्मीद है

प्रश्नोत्तर सारांश

• OCI migration के दौरान मौजूदा Flatpak apps के प्रबंधन पर पूछे गए प्रश्न के जवाब में कहा गया कि Flathub की build automation आदि के कारण बड़ी समस्या नहीं होगी
• OCI registries में metadata की कमी को लेकर बताया गया कि non-image data standards बन रहे हैं, लेकिन वास्तविक उपयोग के लिए development और integration अभी भी ज़रूरी हैं
• PipeWire direct support की योजना पर कहा गया कि technical discussions जारी हैं, और दिशा PipeWire policy-आधारित integration की ओर है

निष्कर्ष

• Flatpak ने distribution और sandboxing के लिए मानक platform के रूप में अपनी जगह बना ली है, लेकिन review और नए development में ठहराव, permission/network/driver समस्याएँ, और भविष्य के standards migration जैसी कई चुनौतियाँ अब भी मौजूद हैं
• OCI-आधारित container technology और Rust का उपयोग Flatpak के विकास के लिए नई ऊर्जा बन सकता है
• मुख्य बिंदुओं को reviewer secure karna, standardization, ecosystem expansion, और user experience improvement के रूप में संक्षेपित किया जा सकता है

[ndrgrd]

मुझे लगता है कि एक्सेस परमिशन को पूरी तरह ब्लॉक करने के बजाय यह साफ़-साफ़ दिखाने का तरीका बेहतर है कि किस डायरेक्टरी तक एक्सेस किया जा रहा है.

इस मामले में Android ठीक है, लेकिन वहाँ परमिशन को बहुत बड़े समूहों में बाँध दिया जाता है, इसलिए ज़रूरत न होने वाले स्तर की परमिशन भी साथ में देनी पड़ती है...

[GN⁺]

Hacker News की राय

• Wick की प्रस्तुति में यह बात रेखांकित की गई कि Flatpak प्रोजेक्ट ऊपर से देखने पर ठीक चलता हुआ लगता है, लेकिन वास्तव में सक्रिय development नहीं हो रहा। security maintenance और साधारण maintenance जारी हैं, लेकिन नए features लगभग नहीं जुड़ रहे। कई feature proposals (Merge Request) आए हुए हैं, पर उन्हें review करने वाला कोई नहीं, इसलिए वे अटके हुए हैं — यह एक समस्या लगती है। खासकर RHEL 10 में desktop packages देना बंद करके Flathub से packages install करने की सिफारिश के बाद Red Hat की भूमिका और भी महत्वपूर्ण हो गई है। अगर Red Hat सच में Flatpak को एक सही विकल्प बनाना चाहता है, तो वह इसमें अधिक resources लगाए — यही उम्मीद है। Flatpak के अलग-अलग versions में नए permissions support अलग होने के कारण backwards compatibility ज़रूरी है — Wick की इस बात से सहमति है। Flathub पर गेम distribute करते समय audio और controller permissions, --device=input के unsupported होने, और सिर्फ speaker खोलकर microphone block करने जैसे granular permission settings न कर पाने की समस्या का खुद अनुभव किया है
  • यह भी उल्लेख किया गया कि Red Hat ने शुरू में Firefox और Thunderbird को RHEL 10 में केवल Flatpak के रूप में देने की योजना बनाई थी, लेकिन GA release के बाद वास्तव में rpm packages भी दिए। इसके पीछे Native Messaging support न होना, central policy deployment न कर पाना, desktop integration issues जैसी कई वजहें थीं
• Flatpak की शुरुआत के समय मूल developer से सीधे मिलकर उसकी design philosophy पर चर्चा करने का अनुभव साझा किया गया। Flatpak में permissions package name से बंधी होती हैं और instance-level isolation नहीं है — यही संरचनात्मक समस्या समझाने की कोशिश की थी। यानी एक ही Flatpak app की कई instances चलाकर उन्हें अलग-अलग permissions (जैसे Documents के भीतर केवल किसी खास directory की अनुमति) देकर अलग नहीं किया जा सकता। ऐसा मॉडल MS, Apple App Store और macOS में भी है, इसलिए लगता है कि पूरी दुनिया ने गलत design चुना है। उदाहरण के लिए, LibreOffice document में RCE (remote code execution) हो जाए, तब भी उसे मेरी दूसरी documents तक पहुँच नहीं होनी चाहिए। vendor security की परवाह करे या न करे, Flatpak sandbox को सुरक्षा देनी चाहिए — यह तर्क है
  • इस तरह security के लिए complexity बढ़ाने पर आलोचनात्मक नज़रिया भी है। PC मेरा है, इसलिए instance-level permissions, sandbox, file sharing restrictions जैसी चीज़ें अनावश्यक हैं, और “everything is a file” जैसी पारंपरिक अवधारणा बनी रहनी चाहिए। उदाहरण के तौर पर Thunderbird और Firefox का /tmp directory तक पहुँच न होना, जिससे attachments save करना या दूसरे apps में खोलना बेहद असुविधाजनक हो जाता है — ऐसे sandboxed environment से असंतोष है। तर्क यह है कि computer का मालिक developer नहीं बल्कि user होना चाहिए। ऐसी अति-सुरक्षा productivity घटाती है, और इसकी तुलना Useless Machine से की गई
  • यह संभावना भी रखी गई कि Flatpak developers इस समस्या को समझते थे। अगर Flatpak ने तकनीकी रूप से परिपूर्ण मॉडल चुना होता, तो वह app developers, खासकर multiplatform developers के लिए इतना बड़ा entry barrier बन जाता कि Flatpak फैल ही नहीं पाता — यह अधिक व्यावहारिक दृष्टिकोण है
  • Instance-level permission model बहुत आकर्षक है, लेकिन configuration (git config, font folders आदि) के लिए ऐसा hybrid तरीका व्यावहारिक हो सकता है जिसमें सभी instances को समान access देना एक option हो
  • बेहतर यह होगा कि पूरे operating system को फिर से design किया जाए ताकि चल रही हर instance को अलग capabilities, disk quota, logging, proxy, granular permission separation जैसी सुविधाएँ दी जा सकें। यह सिर्फ Flatpak की समस्या नहीं है — ऐसा मत है
  • QubesOS जैसे hypervisor-based sandboxing की तरह, power users और security-sensitive users के लिए instance-level isolation उपयोगी हो सकती है। लेकिन अधिकतर isolation app के भीतर होना अधिक intuitive है। Web browser sandboxing की तरह Flatpak में भी nested sandbox का support आदर्श होगा, लेकिन अभी यह supported नहीं है। Code signing और sandbox का integration, UID namespaces जैसी काफी जटिल समस्याएँ भी मौजूद हैं
• Flatpak का लंबे समय से उत्साही user होने के नाते, यह अनुभव साझा किया गया कि यह कभी बहुत innovative था और सभी Linux distributions पर latest apps आसानी से उपयोग करने देता था, लेकिन कई वर्षों से इसमें बदलाव न होने के कारण धीरे-धीरे रुचि कम हो गई। अब अधिकतर ज़रूरतें AUR से पूरी हो जाती हैं, इसलिए Flatpak का ठहराव खलता है
  • User के रूप में Flatpak का बस आसान होना ही अच्छा लगा, इसके अलावा अनुभव खास अच्छा नहीं रहा। Theme, cursor, file picker, permissions, Drag&Drop जैसी integration समस्याएँ, features के लिए अतिरिक्त tools की आवश्यकता — इन सब के कारण UX कमजोर लगता है। ऐसा मानना है कि जब UX अच्छा न हो, तो sandboxing जैसी security benefits भी अर्थहीन हो जाती हैं। अगर Linux में binary portability की समस्या ही न होती, तो Flatpak की ज़रूरत नहीं पड़ती
  • Fedora+GNOME+Flatpak का संयोजन कभी बहुत innovative लगा था, लेकिन हाल में फिर Arch पर लौटने का अनुभव साझा किया गया। Arch repositories अब काफी समृद्ध हो गए हैं और AUR की ज़रूरत लगभग नहीं पड़ती
  • कई packages manage कर चुके किसी व्यक्ति से makedeb का अनुभव पूछा गया, और कहा गया कि makedeb PKGBUILD आधारित होने के कारण काफी portable लगता है, इसलिए हैरानी है कि यह अधिक प्रसिद्ध क्यों नहीं है
• Drew DeVault के “distributions को app packaging संभालनी चाहिए” वाले तर्क से 100% सहमति नहीं, लेकिन उनकी पुरानी विस्तृत पोस्ट और संदर्भ लिंक साझा किया गया। यह दृष्टिकोण है कि community (distribution) users का प्रतिनिधित्व करते हुए packages manage करे — यही सही मॉडल है। Flatpak/Snap/AppImage की तरह distribution के बाहर packaging करना मूलतः अच्छा नहीं — ऐसा दावा है
  • इसके जवाब में कहा गया कि package management के लिए सबसे उपयुक्त व्यक्ति वही developer है जो app खुद बनाता है। खासकर closed-source software में distribution और packaging के अधिकार कानूनी रूप से उसी के पास होते हैं, और open source में भी core team के बाहर का कोई व्यक्ति packaging में मनमाने ढंग से हस्तक्षेप करे तो अनावश्यक bugs, release delays और नई समस्याएँ पैदा हो सकती हैं। लोग तेज़ और latest updates, तथा packaging में बिना बदलाव वाला मूल software चाहते हैं। समस्या यह है कि Flatpak बहुत ज्यादा भूमिकाएँ निभाने की कोशिश कर रहा है। App store model पर भी संदेह है: Windows और macOS में app store के बिना भी binary distribution स्वतंत्र है, और न्यूनतम security OS level पर code signing जैसी चीज़ों से मिलती है। इसलिए third-party packaging system की प्रधानता अनावश्यक लगती है
  • App developers को सीधे distribute कर पाने की क्षमता होनी चाहिए, और Windows के सरल installation अनुभव को उदाहरण के रूप में दिया गया। Maintainers के लिए सभी distributions को support करने लायक scale बनाना कठिन है, और इसे Linux desktop की प्रगति में बाधा माना गया
  • हर distribution के लिए अलग-अलग packaging करने की मेहनत के कारण इसका मूल्य ही घट जाता है — ऐसा भी कहा गया
  • दुनिया के सारे software को distribution द्वारा package करना अवास्तविक है — यह मत भी सामने आया
  • जो लोग मानते हैं कि distributions app packaging ठीक से नहीं कर पाते, उनके लिए Flatpak का बढ़ता अपनाव खुशी की बात है। उनका मानना है कि developer को बिना किसी middleman के अपना app आसानी से distribute कर पाना चाहिए
• Flatpak अब भी PulseAudio का उपयोग करता है और PipeWire अपनाने में पीछे है — इस बात से सहमति जताई गई। PulseAudio speaker और microphone permissions को अलग नहीं करता, यानी किसी app को sound output की अनुमति देते ही वह microphone तक भी पहुँच सकता है — इसे security का बड़ा छेद माना गया
  • Linux users अक्सर Windows/Mac की design mistakes या स्वतंत्रता की कमी का मज़ाक उड़ाते हैं, लेकिन ऐसी बुनियादी design समस्याओं को भी स्वीकार करना चाहिए — ऐसा तर्क है। Linux ecosystem पर यह आरोप भी है कि वह जिम्मेदारी स्पष्ट किए बिना समस्याओं को छोड़ देता है
• Python debugging के लिए VSCode/Codium को Flatpak के रूप में install किया था, लेकिन permissions और configuration समस्याओं के कारण debugger setup में बहुत समय लग गया। अंत में Snap version install करने पर सारी समस्याएँ हल हो गईं — ऐसा अनुभव साझा किया गया
  • Flatpak desktop applications, खासकर बड़े apps (जैसे Chrome, Chromium) के लिए उपयुक्त है, लेकिन system tools के लिए उपयुक्त नहीं — ऐसा मानना है
  • Emacs का Flatpak version केवल inefficiency और frustration देता है — ऐसा अनुभव भी साझा किया गया
• Immutable distro में Flatpak-आधारित workflow अपनाने पर, जब सब ठीक चले तो अनुभव अच्छा होता है, लेकिन उम्मीद से कहीं अधिक चीज़ें काम नहीं करतीं। उदाहरण के लिए Godot के लिए external tools चलाना, कई permission tweaks, Flatpak apps के बीच integration issues (जैसे Firefox और KeepassDX), Godot और Krita Flatpak के crashes, non-Flatpak AppImage/.rpm जैसे मिश्रित environments — इनसे कई असुविधाएँ हुईं। Flatpak में और innovation की अपेक्षा जताई गई
• Flatpak की संरचना में Tailscale जैसे virtual network interface बनाने वाले apps को package करना संभव नहीं। macOS में API के माध्यम से network permissions को granular रूप से बाँटा जा सकता है, इसलिए Tailscale को Mac App Store में sandboxed app के रूप में distribute किया जा सकता है
  • इसी API की वजह से Tailscale का macOS sandboxed app distribution संभव है, जबकि Silverblue, Bluefin जैसे Flatpak-निर्भर “atomic” Linux distributions में इस तरह का software चलाना कठिन है
  • OBS Studio जैसे बड़े desktop apps के लिए Flatpak उपयोगी है, लेकिन Tailscale जैसा system service की तरह चलने वाला software Flatpak की बजाय distribution के मूल package के रूप में अधिक उपयुक्त है। Arch Linux में यह official package के रूप में उपलब्ध है
  • Flatpak में flatpak-spawn, polkit-exec जैसे workaround संभव हैं, लेकिन ऐसा करने पर sandbox protection लगभग छोड़नी पड़ती है
  • Linux के ऊपरी स्तर पर granular permission system और packaging को एक साथ हल करने की कोशिश जरूरत से ज्यादा जटिल है। Flatpak का ठहराव या developer burnout भी शायद इसी वजह से हो सकता है। आधुनिक Linux में बुनियादी permission architecture ही नहीं है, इसलिए परिपूर्ण permission settings से पहले तत्काल प्राथमिकता software distribution, packaging और update system होनी चाहिए — ऐसा यथार्थवादी दृष्टिकोण है
  • Tailscale जैसी चीज़ों को sysext के रूप में जाना चाहिए, Flatpak इसके लिए उपयुक्त नहीं — ऐसा मत है
• Flatpak distribution के प्रस्ताव के संदर्भ में, Java-आधारित KmCaster app बनाते समय Flatpak porting का अनुरोध मिला, लेकिन दो installation methods, download statistics प्रबंधन, third-party repository पर भरोसा, एक और package manager का बढ़ना, repositories का दोहराव — इन सब से सिर्फ अतिरिक्त बोझ महसूस हुआ, कोई वास्तविक लाभ नहीं
  • फिर भी Flatpak के सकारात्मक पक्ष के रूप में immutable distro में उपयोग की सुविधा, Java version management की आवश्यकता खत्म होना, Flathub search visibility, automatic updates जैसी बातें गिनाई गईं
• Open source maintainer या developer न होने के बावजूद, यह समझ से बाहर लगता है कि इतने सारे Linux distributions एक ही package management समस्या से जूझ रहे हैं, फिर भी वे मिलकर Flatpak को बेहतर और अधिक सार्वभौमिक बनाने पर ध्यान क्यों नहीं देते
  • हर distribution का अपना distribution model अलग होता है, इसलिए सब कुछ एक में एकीकृत करना मुश्किल है। विविध विकल्प open source ecosystem की ताकत हैं, और व्यक्तिगत रूप से पारंपरिक system package manager अधिक पसंद है
  • इस तर्क से तो केवल GNOME ही होना चाहिए — ऐसा पलटकर कहा गया, यानी community diversity और decision-making diversity महत्वपूर्ण है
  • Flatpak मेरे लिए बिल्कुल उपयोगी नहीं है, और मैं जिस software का इस्तेमाल नहीं करता उसके लिए योगदान देने को बाध्य नहीं होना चाहता