อนาคตของ Flatpak

• Flatpak กำลังได้รับ ความนิยมจากนักพัฒนาและผู้ใช้ แต่ตัวโครงการเองกำลังเผชิญปัญหา การพัฒนาชะงักงัน
• จากการถอนตัวของนักพัฒนาหลักและ คอขวด ต่างๆ ทำให้การเพิ่มฟีเจอร์ใหม่และการรีวิวโค้ดเกิด ความล่าช้า
• มีการเสนอ ฟีเจอร์เสริม หลายอย่าง เช่น รองรับอิมเมจ OCI, การแยกสิทธิ์ให้ละเอียดขึ้น, การควบคุมการเข้าถึงระบบเสียง แต่การนำมาใช้จริงยังเป็นไปอย่างล่าช้า
• เพื่อการพัฒนาโครงการในระยะยาว มีการพูดคุยถึงแนวทาง นำมาตรฐานเทคโนโลยีคอนเทนเนอร์ (OCI) มาใช้ และ การเขียนใหม่บน Rust
• การแก้โจทย์สำคัญอย่าง การปรับปรุงพอร์ทัล, การรองรับไดรเวอร์, และ network sandboxing จะเป็นกุญแจต่อการเติบโตของ Flatpak

---

ภาพรวมและสถานะของโครงการ Flatpak

• Flatpak เริ่มต้นจากโครงการลักษณะใกล้เคียงกันมาตั้งแต่ปี 2007 เปิดตัวครั้งแรกในชื่อ XDG-App ปี 2015 และเปลี่ยนชื่อเป็น Flatpak ในปี 2016
• มี เครื่องมือบรรทัดคำสั่ง, เครื่องมือสำหรับบิลด์, และองค์ประกอบรันไทม์ โดยใช้ cgroups, namespaces, bind mount, seccomp, Bubblewrap เป็นต้น เพื่อแยกแอปพลิเคชันออกจากระบบ (sandboxing)
• เดิมใช้ OSTree เป็นวิธีส่งมอบหลัก และช่วงหลังได้เพิ่ม การรองรับอิมเมจ OCI ซึ่งถูกใช้งานใน Fedora เป็นต้น
• แม้จะประสบความสำเร็จจากการเติบโตของ Flathub app store และการยอมรับจากดิสโทรต่างๆ แต่ภายในโครงการกลับเผชิญภาวะ การพัฒนาเชิงรุกชะลอตัว

ภาวะชะงักงันของการพัฒนาและสาเหตุหลัก

• แม้ยังมีงานด้านการดูแลรักษาและแพตช์ความปลอดภัยอยู่ แต่การพัฒนา ฟีเจอร์ใหม่ขนาดใหญ่ และการรีวิวโค้ดเกิดภาวะ หยุดนิ่งเป็นเวลานาน
• การถอนตัวของนักพัฒนาหลัก (เช่น Larsson) ทำให้ผู้รีวิวมีไม่พอ ส่งผลให้สภาพแวดล้อมไม่เอื้อต่อการดึงผู้มีส่วนร่วมรายใหม่หรือการเปลี่ยนแปลงขนาดใหญ่
• แม้แต่ฟีเจอร์อย่าง Flatpak preinstall ที่มีผู้สนับสนุนจาก Red Hat ก็ยังประสบปัญหาการรีวิวล่าช้าและผู้รับผิดชอบถอนตัว ทำให้ต้องใช้เวลาหลายเดือนกว่าจะรวมเข้าระบบได้ และเหตุการณ์ลักษณะนี้เกิดซ้ำหลายครั้ง

OSTree และการรองรับอิมเมจ OCI

• OSTree ถูกนำมาใช้กับ Flatpak ได้อย่างประสบความสำเร็จ แต่เนื่องจากปัญหาเรื่อง ความไม่เป็นมาตรฐาน/เครื่องมือที่จำกัด จึงแทบไม่มีการพัฒนาเชิงรุกนอกจากการบำรุงรักษา
• ฝั่ง OCI มี ecosystem ของเครื่องมือที่กว้างขวาง สำหรับอิมเมจคอนเทนเนอร์ ดังนั้นสำหรับทีมพัฒนา Flatpak การนำมาใช้อาจช่วยลดภาระการดูแลรักษาและลดงานที่ซ้ำซ้อน
• ข้อเสนอใหม่อย่างการรองรับฟอร์แมตบีบอัดที่มีประสิทธิภาพ เช่น zstd:chunked ถูกเสนอผ่าน PR แล้ว แต่ยังคงอยู่ในสถานะ ล่าช้าหรือยังไม่ถูกรวม

การจัดการสิทธิ์และการแยก sandbox ให้ละเอียดขึ้น

• Flatpak มุ่งเน้นการจำกัดการเข้าถึงระบบผ่าน sandboxing และใน Flatpak รุ่นใหม่มีการรองรับ การแยกสิทธิ์อย่างละเอียด แล้ว (เช่น --device=input)
• เนื่องจากแต่ละดิสโทรลินุกซ์ใช้ Flatpak คนละเวอร์ชัน จึงเกิดปัญหาที่ ฟีเจอร์สิทธิ์แบบใหม่ยังไม่ถูกใช้อย่างแพร่หลาย รวมถึงปัญหา ความเข้ากันได้ของเวอร์ชัน
• ในกรณีของสิทธิ์ด้านเสียง เนื่องจากข้อจำกัดในการรองรับ PulseAudio จึงแยกสิทธิ์เล่นเสียงและบันทึกเสียงได้ยาก ทำให้มีการเสนอว่าควรปรับปรุงผ่าน PipeWire เป็นต้น
• การรองรับ nested sandboxing ยังไม่เพียงพอ ทำให้แอปอย่างเว็บเบราว์เซอร์ไม่สามารถใช้ sandbox ภายในเพิ่มเติมได้

D-Bus และ network sandboxing

• Flatpak ไม่เข้าถึง D-Bus โดยตรง แต่ใช้การสื่อสารแบบกรองผ่าน xdg-dbus-proxy
• Wick แสดงเจตนาที่จะย้าย นโยบายการกรอง ไปไว้ใน D-Bus broker เพื่อให้สามารถใช้นโยบายแบบไดนามิกและควบคุมการเข้าถึงบนพื้นฐานของ cgroup ได้
• จากการที่การทำ network namespace ยังไม่สมบูรณ์ เมื่อมีการเปิดเผยพอร์ตบน localhost จึงอาจเกิด การสื่อสารที่ไม่ตั้งใจระหว่างแอป Flatpak ได้ (กรณีจริง: AusweisApp)
• ไดรเวอร์ NVIDIA ถูกจัดเตรียมแยกตามแต่ละรันไทม์ ทำให้เกิด ทราฟฟิกเครือข่ายมากเกินไปและอัปเดตได้ยาก จึงมีการมองหาแนวทางอย่าง การแชร์จากโฮสต์ หรือ การคอมไพล์แบบสแตติก โดยอ้างอิงโมเดลของ Valve

การใช้งานพอร์ทัล (Portal) และความจำเป็นในการปรับปรุง

• พอร์ทัล คือ API สำหรับเข้าถึงทรัพยากรภายนอกบนพื้นฐาน D-Bus โดยรองรับบทบาทหลากหลาย เช่น ไฟล์ การพิมพ์ และ URL
• พอร์ทัลอย่าง Documents มีประสิทธิภาพในระดับไฟล์รายชิ้น แต่สำหรับแอปที่เน้นการใช้งานจริงสูงอย่าง GIMP หรือ Blender โมเดลสิทธิ์ที่ ละเอียดเกินไป กลับกลายเป็นข้อจำกัด
• มีการพูดคุยถึงข้อเสนอ API ใหม่ เช่น การกรอกรหัสผ่านอัตโนมัติ, FIDO key, การสังเคราะห์เสียง พร้อมทั้งแนวคิดเรื่องการลดความยากในการพัฒนาและ การเขียนใหม่ด้วย Rust

อนาคตของ Flatpak (Flatpak-next)

• มีการพูดคุยในมุมมองระยะยาวโดยสมมติว่า Flatpak อาจไม่ถูกพัฒนาต่อในอนาคต ซึ่งนำไปสู่แนวคิด เปลี่ยนผ่านครั้งใหญ่ไปสู่ ecosystem ของ OCI (ครอบคลุมอิมเมจ รีจิสทรี เครื่องมือ นโยบาย ฯลฯ)
• การเขียนใหม่ด้วย Rust และแนวทาง ทำให้เป็นส่วนหนึ่งของ ecosystem คอนเทนเนอร์แบบรวมศูนย์ อาจมีข้อดีด้านภาระการจัดการ การบำรุงรักษา และความสามารถในการขยายระบบ

สรุปคำถาม-คำตอบ

• ต่อคำถามเรื่อง การจัดการแอป Flatpak เดิมเมื่อย้ายไป OCI มีคำตอบว่าไม่น่ามีปัญหาใหญ่ เพราะ Flathub มีระบบอัตโนมัติด้านบิลด์อยู่แล้ว
• ส่วนปัญหา การขาด metadata ใน OCI registry แม้กำลังมีการจัดทำมาตรฐานสำหรับข้อมูลที่ไม่ใช่อิมเมจ แต่การใช้งานจริงยังต้องอาศัยการพัฒนาและการบูรณาการเพิ่มเติม
• สำหรับแผน รองรับ PipeWire โดยตรง มีการระบุว่าการหารือเชิงเทคนิคกำลังดำเนินอยู่ และทิศทางคือการผสานรวมบนฐานของนโยบาย PipeWire

บทสรุป

• Flatpak ได้กลายเป็น แพลตฟอร์มมาตรฐานด้านการแจกจ่ายและ sandboxing ไปแล้ว แต่ยังมีโจทย์ให้ปรับปรุงอีกหลายด้าน เช่น การรีวิวและการพัฒนาฟีเจอร์ใหม่ที่ชะงักงัน, ปัญหาเรื่องสิทธิ์/เครือข่าย/ไดรเวอร์, และการเปลี่ยนผ่านไปสู่มาตรฐานในอนาคต
• เทคโนโลยีคอนเทนเนอร์บนฐาน OCI และการใช้ Rust อาจกลายเป็นแรงขับใหม่ของการพัฒนา Flatpak
• ประเด็นสำคัญสามารถสรุปได้เป็น การเพิ่มจำนวนผู้รีวิว, การทำมาตรฐาน, การขยาย ecosystem, และการปรับปรุงประสบการณ์ผู้ใช้

[ndrgrd]

ผมคิดว่าวิธีที่ดีกว่าคือไม่ใช่การบล็อกสิทธิ์การเข้าถึงไปเลย แต่เป็นการแสดงให้ชัดเจนว่าเข้าถึงไดเรกทอรีไหนอยู่

Android ก็โอเคในแง่นั้น แต่ฝั่งนี้กลับมัดสิทธิ์เป็นก้อนใหญ่เกินไป จนต้องอนุญาตสิทธิ์ในระดับที่ไม่จำเป็นไปด้วย...

[GN⁺]

ความคิดเห็นบน Hacker News

• มีการแชร์ประเด็นจากการบรรยายของ Wick ที่เน้นว่าโปรเจกต์ Flatpak ภายนอกดูเหมือนยังไปได้ดี แต่ในความเป็นจริงกลับไม่มีการพัฒนาอย่างคึกคัก มีเพียงการดูแลด้านความปลอดภัยและงานบำรุงรักษาง่าย ๆ ต่อเนื่อง แต่แทบไม่มีฟีเจอร์ใหม่เพิ่มเข้ามา มองว่าเป็นปัญหาที่มีข้อเสนอฟีเจอร์จำนวนมาก (Merge Request) ถูกส่งเข้ามาแต่ไม่มีคนตรวจจนค้างเติ่ง โดยเฉพาะเมื่อ RHEL 10 หยุดจัดหาแพ็กเกจเดสก์ท็อปและแนะนำให้ติดตั้งแพ็กเกจจาก Flathub ทำให้บทบาทของ Red Hat สำคัญยิ่งขึ้น หาก Red Hat ต้องการให้ Flatpak เป็นทางเลือกทดแทนที่ใช้งานได้จริง ก็ควรทุ่มทรัพยากรมากกว่านี้ อีกทั้งยังเห็นด้วยกับข้อสังเกตของ Wick ว่าการรองรับสิทธิ์ใหม่ ๆ แตกต่างกันไปตามแต่ละเวอร์ชันของ Flatpak จึงจำเป็นต้องมี backwards compatibility ผู้แสดงความเห็นยังเคยเจอปัญหาด้วยตัวเองตอนแจกจ่ายเกมบน Flathub ทั้งเรื่องสิทธิ์เสียงและคอนโทรลเลอร์ การไม่รองรับ --device=input และความจริงที่ว่าไม่สามารถตั้งสิทธิ์แบบละเอียด เช่น เปิดเฉพาะลำโพงแต่ปิดไมโครโฟนได้
  • มีการยกกรณีที่ Red Hat เดิมตั้งใจจะแจก Firefox และ Thunderbird บน RHEL 10 แบบ Flatpak เท่านั้น แต่สุดท้ายหลังออก GA แล้วก็ยังมีแพ็กเกจ rpm ให้ด้วย โดยมีหลายเหตุผลประกอบกัน เช่น ไม่รองรับ Native Messaging, ไม่สามารถกระจายนโยบายจากศูนย์กลางได้ และปัญหาด้านการผสานกับเดสก์ท็อป
• มีการเล่าประสบการณ์ว่าเมื่อ Flatpak เริ่มต้นใหม่ ๆ เคยพบกับนักพัฒนาต้นฉบับโดยตรงและถกเรื่องปรัชญาการออกแบบ โดยพยายามอธิบายว่าปัญหาของ Flatpak คือสิทธิ์ถูกผูกกับชื่อแพ็กเกจ และไม่มีการแยกตามอินสแตนซ์ กล่าวคือไม่สามารถเปิดแอป Flatpak เดียวกันหลายอินสแตนซ์แล้วแยกสิทธิ์กันได้ เช่น อนุญาตเฉพาะบางไดเรกทอรีย่อยใต้ Documents ให้แต่ละอินสแตนซ์ต่างกัน มองว่าโครงสร้างแบบนี้ไม่ต่างจาก MS, Apple App Store และ macOS ซึ่งล้วนออกแบบผิดเหมือนกัน ตัวอย่างเช่น ต่อให้เกิด RCE (การรันโค้ดจากระยะไกล) ในเอกสาร LibreOffice ก็ยังควรต้องกันไม่ให้เข้าถึงเอกสารอื่นของตนได้ และต่อให้ผู้ขายซอฟต์แวร์ไม่ได้ใส่ใจเรื่องความปลอดภัย ตัว sandbox ของ Flatpak ก็ควรเป็นฝ่ายให้ความปลอดภัยแทน
  • มีมุมมองวิจารณ์ว่าความซับซ้อนที่เพิ่มขึ้นเพื่อจุดประสงค์ด้านความปลอดภัยแบบนี้เกินจำเป็น เพราะพีซีเป็นของผู้ใช้เอง จึงไม่ต้องการสิทธิ์แยกตามอินสแตนซ์, sandbox, หรือข้อจำกัดการแชร์ไฟล์ และอยากรักษาแนวคิดดั้งเดิมแบบ “ทุกสิ่งคือไฟล์” เอาไว้ ยกตัวอย่างว่า Thunderbird และ Firefox เข้าไม่ถึงไดเรกทอรี /tmp ทำให้การบันทึกไฟล์แนบหรือเปิดในแอปอื่นลำบากมากในสภาพแวดล้อม sandbox มองว่าเจ้าของคอมพิวเตอร์ควรเป็นผู้ใช้ ไม่ใช่นักพัฒนา และคิดว่าความปลอดภัยที่มากเกินไปแบบนี้ทำให้ประสิทธิภาพการทำงานลดลง เปรียบเหมือน Useless Machine
  • มีการตั้งข้อสังเกตว่าทีมพัฒนา Flatpak เองก็น่าจะเข้าใจปัญหานี้ และหาก Flatpak เลือกโมเดลที่สมบูรณ์แบบในเชิงเทคนิคเกินไป ก็อาจกลายเป็นกำแพงเริ่มต้นที่สูงเกินสำหรับนักพัฒนาแอป โดยเฉพาะนักพัฒนาแบบหลายแพลตฟอร์ม จนทำให้ Flatpak เองไม่แพร่หลาย
  • มีข้อเสนอว่าโมเดลสิทธิ์แยกตามอินสแตนซ์นั้นน่าสนใจมาก แต่สำหรับค่าตั้งค่าอย่าง git config, โฟลเดอร์ฟอนต์ ฯลฯ ควรมีตัวเลือกแบบไฮบริดที่ให้อินสแตนซ์ทั้งหมดเข้าถึงเหมือนกันเพื่อให้ใช้งานได้จริง
  • มองว่าควรออกแบบระบบปฏิบัติการใหม่ทั้งระบบ เพื่อให้แต่ละอินสแตนซ์ที่กำลังรันมีสิทธิ์ (capabilities) แยกกัน พร้อมรองรับความสามารถอย่าง disk quota, logging, proxy, การแยกสิทธิ์อย่างละเอียด ฯลฯ และย้ำว่านี่ไม่ใช่ปัญหาเฉพาะของ Flatpak เท่านั้น
  • สำหรับ power user หรือผู้ใช้ที่อ่อนไหวด้านความปลอดภัยซึ่งต้องการการแยกอย่างเข้มงวด เช่น sandbox แบบอิง hypervisor อย่าง QubesOS การแยกตามอินสแตนซ์อาจเหมาะกว่า แต่สำหรับงานแยกส่วนใหญ่ การทำภายในตัวแอปเองน่าจะเป็นแนวทางที่เข้าใจง่ายกว่า เช่นเดียวกับ sandbox ของเว็บเบราว์เซอร์ Flatpak ก็ควรรองรับ nested sandbox ซึ่งตอนนี้ยังไม่รองรับ และยังมีปัญหาซับซ้อนอีกมาก เช่น การเชื่อม code signing เข้ากับ sandbox, UID namespace เป็นต้น
• ผู้แสดงความเห็นบอกว่าตนเป็นผู้ใช้ Flatpak ตัวยงมานาน และแม้มันเคยเป็นสิ่งที่นวัตกรรมมาก ทำให้ใช้แอปล่าสุดบนทุกลินุกซ์ดิสโทรได้ง่าย แต่เพราะหลายปีมานี้แทบไม่มีอะไรเปลี่ยน ความสนใจจึงค่อย ๆ ลดลง ปัจจุบัน AUR ตอบโจทย์ได้เกือบทั้งหมด จึงเสียดายที่ Flatpak อยู่ในภาวะชะงักงัน
  • ในฐานะผู้ใช้ นอกจากความง่ายแล้วแทบไม่ได้รู้สึกว่า Flatpak มอบประสบการณ์ที่ดี มีปัญหาการผสานหลายด้าน เช่น ธีม, เคอร์เซอร์, file picker, permissions, Drag&Drop และยังต้องมีเครื่องมือเสริมเพื่อใช้บางฟีเจอร์ มองว่าเมื่อ UX แย่ ประโยชน์ด้านความปลอดภัยอย่าง sandboxing ก็แทบไม่มีความหมาย และถ้าลินุกซ์ไม่มีปัญหาเรื่อง binary portability ตั้งแต่แรก ก็คงไม่จำเป็นต้องมี Flatpak
  • เคยมองว่าชุด Fedora+GNOME+Flatpak มีความล้ำมากในช่วงหนึ่ง แต่ล่าสุดได้กลับไปใช้ Arch อีกครั้ง เพราะคลังแพ็กเกจ Arch สมบูรณ์ขึ้นมากจนแทบไม่ต้องใช้ AUR แล้ว
  • มีการถามผู้ที่เคยดูแลหลายแพ็กเกจถึงประสบการณ์ใช้งาน makedeb โดยระบุว่า makedeb ใช้ฐาน PKGBUILD จึงพกพาได้ดี และแปลกใจว่าทำไมถึงไม่เป็นที่รู้จักมากกว่านี้
• แม้จะไม่เห็นด้วย 100% กับข้อโต้แย้งของ Drew DeVault ที่ว่า “ดิสโทรควรเป็นผู้จัดการแพ็กเกจแอป” แต่ก็มีการแนะนำบทความอภิปรายยาวและลิงก์อ้างอิง พร้อมมุมมองว่าโมเดลที่ชุมชน (ดิสโทร) เป็นตัวแทนผู้ใช้ในการดูแลแพ็กเกจนั้นถูกต้องกว่า และการแพ็กเกจนอกดิสโทรแบบ Flatpak/Snap/AppImage นั้นไม่ดีโดยพื้นฐาน
  • มีการโต้แย้งกลับว่าผู้พัฒนาแอปโดยตรงต่างหากที่เหมาะกับการจัดการแพ็กเกจที่สุด โดยเฉพาะซอฟต์แวร์ปิดซอร์สซึ่งในทางกฎหมายมีสิทธิ์เผยแพร่และแพ็กเกจแต่เพียงผู้เดียว และแม้จะเป็นโอเพนซอร์ส การที่คนที่ไม่ใช่ทีมหลักเข้ามาแพ็กเกจเองโดยพลการก็มักก่อให้เกิดบั๊กที่ไม่จำเป็น ความล่าช้าในการออกรีลีส และปัญหาใหม่ ๆ จึงต้องการซอฟต์แวร์ต้นฉบับที่อัปเดตเร็ว ทันสมัย และไม่ถูกดัดแปลงในการแพ็กเกจ มองว่าปัญหาคือ Flatpak พยายามทำหลายหน้าที่เกินไป และยังตั้งคำถามกับโมเดล app store โดยรวม เพราะบน Windows และ macOS ก็สามารถแจกไบนารีได้อย่างอิสระโดยไม่ต้องมี app store และระบบปฏิบัติการก็ให้ความปลอดภัยขั้นต่ำผ่านสิ่งอย่าง code signing อยู่แล้ว จึงไม่จำเป็นต้องให้ระบบแพ็กเกจของบุคคลที่สามมานำทาง
  • มองว่านักพัฒนาแอปควรสามารถเผยแพร่เองได้ และยกประสบการณ์ติดตั้งที่เรียบง่ายของ Windows เป็นตัวอย่าง เห็นว่าผู้ดูแลซอฟต์แวร์ไม่มีทางมีขนาดทีมพอจะรองรับทุกดิสโทรได้ และนี่เป็นอุปสรรคต่อการพัฒนา Linux desktop
  • มีการชี้ว่าการต้องแพ็กเกจแยกทีละดิสโทรกลับยิ่งทำให้ความพยายามนั้นด้อยความหมาย
  • มีความเห็นว่าการให้ดิสโทรเป็นผู้แพ็กเกจซอฟต์แวร์ทั้งหมดบนโลกเป็นเรื่องไม่สมจริง
  • จากมุมมองที่ว่าดิสโทรทำแพ็กเกจแอปได้ไม่ดี จึงยินดีที่ Flatpak ถูกนำไปใช้มากขึ้น และคิดว่านักพัฒนาควรเผยแพร่แอปของตนได้ง่ายโดยไม่ต้องมีคนกลาง
• มีการเห็นด้วยกับคำวิจารณ์ว่า Flatpak ยังใช้ PulseAudio ต่อเนื่องจนตามการนำ PipeWire มาใช้ไม่ทัน และ PulseAudio รวมสิทธิ์ลำโพงกับไมโครโฟนเข้าด้วยกันจนแยกไม่ได้ กล่าวคือถ้าให้สิทธิ์แอปเล่นเสียง ก็เท่ากับเปิดทางให้เข้าถึงไมโครโฟนได้โดยอัตโนมัติ ซึ่งเป็นช่องโหว่ด้านความปลอดภัยขนาดใหญ่
  • มีความเห็นว่าผู้ใช้ลินุกซ์จำนวนมากชอบล้อความผิดพลาดด้านการออกแบบหรือข้อจำกัดเสรีภาพของ Windows/Mac แต่ก็ควรยอมรับปัญหาการออกแบบพื้นฐานแบบนี้ด้วย และมองว่าระบบนิเวศลินุกซ์มักปล่อยปัญหาคาไว้เพราะไม่สามารถระบุผู้รับผิดชอบได้ชัดเจน
• มีประสบการณ์ติดตั้ง VSCode/Codium แบบ Flatpak เพื่อใช้ดีบัก Python แต่กลับเสียเวลานานกับการตั้งค่าดีบักเกอร์เพราะปัญหาสิทธิ์และการตั้งค่า ก่อนจะพบว่าพอติดตั้งเวอร์ชัน Snap แล้วทุกปัญหาหายไป
  • มองว่า Flatpak เหมาะกับแอปขนาดใหญ่บนเดสก์ท็อป เช่น Chrome, Chromium แต่ไม่เหมาะกับเครื่องมือระบบ
  • มีประสบการณ์ว่า Emacs เวอร์ชัน Flatpak ให้แต่ความไร้ประสิทธิภาพและความหงุดหงิด
• ตอนเปลี่ยนไปใช้ immutable distro ที่อิง Flatpak ก็พบว่าเวลามันเข้ากันได้ก็ถือว่าดี แต่ในความจริงมีหลายอย่างที่ไม่ทำงานเกินคาดจนไม่เป็นไปตามหวัง เช่น การรัน external tool สำหรับ Godot, การต้องปรับ permissions หลายจุด, ปัญหาการทำงานร่วมกันระหว่าง Flatpak ด้วยกันเอง เช่น Firefox กับ KeepassDX, การแครชของ Godot และ Krita เวอร์ชัน Flatpak รวมถึงสภาพแวดล้อมปะปนกับ non-Flatpak อย่าง AppImage/.rpm ฯลฯ จึงหวังว่า Flatpak จะมีนวัตกรรมเพิ่มขึ้นอีก
• โครงสร้างของ Flatpak ไม่สามารถใช้แพ็กเกจแอปอย่าง Tailscale ที่ต้องสร้าง virtual network interface ได้ ขณะที่ macOS มี API สำหรับแยกสิทธิ์ด้านเครือข่ายอย่างละเอียด ทำให้ Tailscale สามารถแจกผ่าน Mac App Store ในรูป sandbox app ได้
  • ด้วย API นั้น การแจกแอป macOS แบบ sandbox ของ Tailscale จึงเป็นไปได้ ตรงกันข้ามกับดิสโทร Linux แบบ “atomic” ที่พึ่งพา Flatpak เช่น Silverblue และ Bluefin ซึ่งใช้งานซอฟต์แวร์ประเภทนี้ได้ยาก
  • มองว่า Flatpak มีประโยชน์กับแอปเดสก์ท็อปขนาดใหญ่อย่าง OBS Studio แต่สำหรับ Tailscale ที่ทำงานคล้าย system service นั้น แพ็กเกจพื้นฐานของดิสโทรเหมาะกว่า และบน Arch Linux ก็มีแพ็กเกจทางการอยู่แล้ว
  • แม้จะมีทางอ้อมอย่าง flatpak-spawn, polkit-exec ให้ใช้ใน Flatpak แต่ก็แทบเท่ากับยอมทิ้งการป้องกันจาก sandbox ไปเกือบหมด
  • มีข้อสงสัยว่าการพยายามแก้ทั้งระบบ permissions แบบละเอียดและ packaging ในชั้นบนสุดของ Linux พร้อมกันนั้นซับซ้อนเกินไป และนี่อาจเป็นเหตุผลหนึ่งของภาวะชะงักงันหรือความเหนื่อยล้าของนักพัฒนา Flatpak เมื่อ Linux สมัยใหม่ยังไม่มีระบบสิทธิ์พื้นฐานที่แท้จริง ดังนั้นภารกิจเร่งด่วนกว่าการตั้งค่าสิทธิ์ให้สมบูรณ์แบบ คือการจัดการเรื่องการเผยแพร่ซอฟต์แวร์ การแพ็กเกจ และระบบอัปเดต
  • มีความเห็นว่าสิ่งอย่าง Tailscale ควรไปอยู่ในรูป sysext มากกว่า และ Flatpak ไม่เหมาะกับกรณีนี้
• เกี่ยวกับข้อเสนอให้แจกผ่าน Flatpak มีการเล่าว่าขณะพัฒนาแอป KmCaster ที่พัฒนาด้วย Java เคยถูกขอให้พอร์ตเป็น Flatpak แต่สิ่งที่รู้สึกได้มีเพียงภาระเพิ่ม เช่น วิธีติดตั้งสองแบบ, การจัดการสถิติดาวน์โหลด, ความน่าเชื่อถือของคลัง third-party, การมี package manager ใหม่เพิ่ม และความซ้ำซ้อนของคลัง โดยแทบไม่มีข้อดีในทางปฏิบัติ
  • ถึงอย่างนั้นก็ยังยอมรับข้อดีของ Flatpak เช่น ความสะดวกในการใช้บน immutable distro, ไม่ต้องกังวลเรื่องการจัดการเวอร์ชัน Java, การถูกค้นพบบน Flathub และการอัปเดตอัตโนมัติ
• แม้จะไม่ใช่ผู้ดูแลโอเพนซอร์สหรือนักพัฒนา แต่ก็ไม่เข้าใจว่าทำไมดิสโทร Linux จำนวนมากที่ต่างก็มีปัญหาการจัดการแพ็กเกจแบบเดียวกัน ถึงไม่ร่วมมือกันเพื่อปรับปรุงและผลักดัน Flatpak ให้เป็นมาตรฐานมากขึ้น
  • มีการตอบว่าด้วยวิธีการทำ Distribution ของแต่ละดิสโทรที่แตกต่างกันมาก จึงยากจะรวมเป็นหนึ่งเดียว และความหลากหลายของตัวเลือกก็เป็นข้อดีของระบบนิเวศโอเพนซอร์ส โดยส่วนตัวชอบ system package manager แบบดั้งเดิมมากกว่า
  • ถ้าใช้ตรรกะนั้น ก็เท่ากับควรมีแค่ GNOME อย่างเดียว ซึ่งอีกฝ่ายมองว่าความหลากหลายของชุมชนและความหลากหลายในการตัดสินใจเป็นสิ่งสำคัญ
  • Flatpak ไม่มีประโยชน์อะไรกับตนเลย และไม่อยากถูกกดดันให้ต้องช่วยเหลือซอฟต์แวร์ที่ตัวเองไม่ได้ใช้