Tương lai của Flatpak

• Flatpak hiện đang được các nhà phát triển và người dùng ưa chuộng, nhưng vấn đề đình trệ phát triển của chính dự án đang nổi lên
• Do sự rời đi của các nhà phát triển chủ chốt và nút thắt cổ chai, việc đưa tính năng mới vào và review mã đang bị trì hoãn
• Nhiều tính năng tăng cường như hỗ trợ image OCI, phân quyền chi tiết và kiểm soát truy cập âm thanh đã được đề xuất, nhưng tiến độ đưa vào thực tế diễn ra chậm
• Để dự án phát triển lâu dài, các phương án áp dụng tiêu chuẩn công nghệ container (OCI) và tái hiện thực bằng Rust đang được thảo luận
• Việc giải quyết các bài toán lớn như cải thiện portal, hỗ trợ driver, sandbox mạng là chìa khóa cho sự tăng trưởng của Flatpak

---

Tổng quan và tình hình hiện tại của dự án Flatpak

• Flatpak bắt đầu từ các dự án tương tự từ năm 2007, ra mắt lần đầu với tên XDG-App vào năm 2015, rồi đổi tên thành Flatpak vào năm 2016
• Dự án cung cấp công cụ dòng lệnh, công cụ build, các thành phần runtime, và có đặc điểm xây dựng cô lập ứng dụng (sandboxing) bằng cgroups, namespaces, bind mount, seccomp, Bubblewrap
• OSTree là phương thức phân phối mặc định, và gần đây hỗ trợ image OCI cũng đã được bổ sung để sử dụng trong Fedora và các nơi khác
• Dù thành công với sự tăng trưởng của kho ứng dụng Flathub và việc được các bản phân phối chấp nhận, nội bộ dự án lại đang trải qua hiện tượng chững lại trong phát triển tích cực

Tình trạng giậm chân tại chỗ trong phát triển và các nguyên nhân chính

• Vẫn có các hoạt động ở mức bảo trì và vá bảo mật, nhưng việc phát triển tính năng mới quy mô lớn và review mã đã đình trệ trong thời gian dài
• Sự rời đi của các nhà phát triển chủ chốt (như Larsson) khiến thiếu người review, tạo ra môi trường khó thu hút người đóng góp mới hoặc thực hiện các thay đổi lớn
• Ngay cả tính năng cài sẵn Flatpak (Preinstall) do Red Hat và các bên khác đóng góp cũng nhiều lần mất hàng tháng để tích hợp xong vì review chậm và người phụ trách rời đi

OSTree và hỗ trợ image OCI

• OSTree đã được áp dụng thành công cho Flatpak, nhưng do vấn đề công cụ không chuẩn/hạn chế, ngoài bảo trì ra thì không còn nhiều phát triển chủ động
• OCI có hệ sinh thái công cụ rất rộng cho container image, nên từ góc nhìn của nhóm phát triển Flatpak, việc áp dụng OCI có thể giúp giảm gánh nặng bảo trì và tránh lặp lại công sức
• Việc hỗ trợ các định dạng nén hiệu quả như zstd:chunked cũng đã được đề xuất qua PR mới, nhưng vẫn ở trạng thái trì hoãn/chưa được hợp nhất

Quản lý quyền hạn và phân tách sandbox chi tiết hơn

• Flatpak tập trung vào việc hạn chế truy cập hệ thống thông qua sandboxing, và ở các phiên bản Flatpak mới hơn đã hỗ trợ phân quyền chi tiết (ví dụ: --device=input)
• Do phiên bản Flatpak khác nhau giữa các bản phân phối Linux, đã phát sinh vấn đề các tính năng quyền hạn mới không thể được áp dụng rộng rãi cùng với vấn đề tương thích phiên bản
• Với quyền âm thanh, do giới hạn trong hỗ trợ PulseAudio, rất khó tách riêng phát và ghi âm; vì vậy nhu cầu cải thiện bằng PipeWire và các công nghệ tương tự đã được nêu ra
• Việc hỗ trợ sandbox lồng nhau còn thiếu, nên các ứng dụng như trình duyệt web không thể sử dụng thêm sandbox nội bộ bên trong

D-Bus và sandbox mạng

• Flatpak không truy cập trực tiếp vào D-Bus mà dùng xdg-dbus-proxy để giao tiếp đã được lọc
• Wick bày tỏ ý định chuyển chính sách lọc sang D-Bus broker để áp dụng chính sách động và thực hiện kiểm soát truy cập dựa trên cgroup
• Do việc triển khai network namespace còn thiếu sót, khi localhost port bị lộ có thể tồn tại khả năng giao tiếp ngoài ý muốn giữa các ứng dụng Flatpak (trường hợp thực tế: AusweisApp)
• Driver NVIDIA được cung cấp riêng cho từng runtime, gây ra lưu lượng mạng quá mức và khó cập nhật. Các phương án như chia sẻ từ host, biên dịch tĩnh đang được xem xét với tham chiếu tới mô hình của Valve

Việc sử dụng Portal và nhu cầu cải thiện

• Portal là API truy cập tài nguyên bên ngoài dựa trên D-Bus, đảm nhiệm nhiều vai trò như file, in ấn, URL
• Documents portal và các portal tương tự hiệu quả ở mức từng file, nhưng với các ứng dụng có tính sử dụng cao như GIMP hay Blender, mô hình quyền quá chi tiết lại trở thành giới hạn
• Cùng với các đề xuất về API mới cho tự động điền mật khẩu, khóa FIDO, tổng hợp giọng nói, các ý tưởng giảm độ khó phát triển và tái hiện thực bằng Rust cũng đang được bàn luận

Tương lai của Flatpak (Flatpak-next)

• Với giả định trong tương lai Flatpak có thể không còn được phát triển nữa, một sự chuyển đổi lớn sang hệ sinh thái OCI (image, registry, công cụ, chính sách và hơn thế nữa) đang được thảo luận ở góc nhìn dài hạn
• Các hướng như tái hiện thực bằng Rust và hợp nhất vào hệ sinh thái container được kỳ vọng có ưu điểm về gánh nặng quản lý, bảo trì và khả năng mở rộng

Tóm tắt phần hỏi đáp

• Trước câu hỏi về cách xử lý các ứng dụng Flatpak hiện có khi chuyển sang OCI, câu trả lời là sẽ không có vấn đề lớn nhờ tự động hóa build của Flathub và các cơ chế tương tự
• Về vấn đề thiếu metadata trong OCI registry, hiện đã có các tiêu chuẩn cho dữ liệu không phải image, nhưng để phản ánh thực tế vẫn cần phát triển và tích hợp thêm
• Về kế hoạch hỗ trợ trực tiếp PipeWire, các thảo luận kỹ thuật đang diễn ra và hướng đi là tích hợp dựa trên chính sách của PipeWire

Kết luận

• Flatpak đã định vị được mình là nền tảng tiêu chuẩn cho phân phối và sandboxing, nhưng vẫn còn nhiều bài toán cần cải thiện như đình trệ review và phát triển mới, vấn đề quyền hạn/mạng/driver, cũng như chuyển đổi sang tiêu chuẩn tương lai
• Công nghệ container dựa trên OCI và việc sử dụng Rust có khả năng trở thành động lực mới cho sự phát triển của Flatpak
• Các điểm chính có thể tóm gọn là bổ sung reviewer, chuẩn hóa, mở rộng hệ sinh thái, cải thiện trải nghiệm người dùng

[ndrgrd]

Có lẽ cách tốt hơn là thay vì chặn hẳn quyền truy cập thì hiển thị rõ đang truy cập vào thư mục nào.

Android khá ổn ở điểm đó, nhưng bên này lại gộp quyền quá lớn nên cả những mức quyền không cần thiết cũng phải cho phép cùng luôn...

[GN⁺]

Ý kiến trên Hacker News

• Chia sẻ nội dung từ bài trình bày của Wick nhấn mạnh rằng dự án Flatpak nhìn bề ngoài có vẻ vẫn vận hành ổn, nhưng thực tế lại không còn được phát triển tích cực; việc duy trì bảo mật và bảo trì đơn giản vẫn tiếp tục, nhưng hầu như không có tính năng mới nào được bổ sung; nhiều đề xuất tính năng (Merge Request) được gửi lên nhưng không có người xem xét nên bị đình trệ, và đây là điều đáng lo ngại; đặc biệt, khi RHEL 10 ngừng cung cấp các gói desktop và khuyến nghị cài gói từ Flathub, vai trò của Red Hat càng trở nên quan trọng hơn; nếu Red Hat thực sự muốn biến Flatpak thành một giải pháp thay thế đúng nghĩa thì cần đầu tư thêm nhiều nguồn lực; cũng đồng tình với nhận xét của Wick rằng việc hỗ trợ quyền mới khác nhau tùy theo từng phiên bản Flatpak khiến khả năng tương thích ngược trở nên cần thiết; bản thân người viết từng phát hành game lên Flathub và trực tiếp gặp các vấn đề về quyền âm thanh và tay cầm, việc không hỗ trợ --device=input, cũng như thực tế không thể thiết lập quyền chi tiết kiểu chỉ mở loa mà chặn micro
  • Có nhắc đến trường hợp Red Hat ban đầu định phân phối Firefox và Thunderbird trên RHEL 10 chỉ dưới dạng Flatpak, nhưng thực tế sau khi GA phát hành vẫn cung cấp cả gói rpm; nhiều lý do cùng tác động như không hỗ trợ Native Messaging, không thể triển khai chính sách tập trung, và các vấn đề tích hợp desktop
• Chia sẻ trải nghiệm từng trực tiếp gặp nhà phát triển ban đầu khi Flatpak mới khởi đầu để tranh luận về triết lý thiết kế; người viết từng cố thuyết phục rằng Flatpak có vấn đề ở chỗ quyền bị gắn với tên gói và không tách biệt theo từng instance; tức là không thể chạy nhiều instance của cùng một ứng dụng Flatpak với các quyền khác nhau, ví dụ chỉ cho phép từng instance truy cập một thư mục con cụ thể trong Documents; cho rằng MS, Apple App Store và macOS cũng mắc cùng vấn đề, nghĩa là cả thế giới đều đang thiết kế sai; ví dụ, ngay cả khi một tài liệu LibreOffice bị RCE (thực thi mã từ xa), nó vẫn phải bị chặn truy cập các tài liệu khác của người dùng, và sandbox của Flatpak phải tự cung cấp bảo mật ngay cả khi nhà cung cấp phần mềm không quan tâm đến bảo mật
  • Có góc nhìn phê phán việc gia tăng độ phức tạp vì mục tiêu bảo mật này; PC là của người dùng nên các quyền theo từng instance, sandbox hay hạn chế chia sẻ file là không cần thiết, và muốn giữ khái niệm truyền thống “mọi thứ đều là file”; lấy ví dụ Thunderbird và Firefox không thể truy cập thư mục /tmp, khiến việc lưu file đính kèm hoặc mở bằng ứng dụng khác trở nên cực kỳ bất tiện trong môi trường sandbox; cho rằng chủ nhân của máy tính phải là người dùng chứ không phải nhà phát triển; kiểu bảo mật quá mức này chỉ làm giảm năng suất, và ví nó với Useless Machine
  • Nêu khả năng đội ngũ Flatpak cũng hiểu vấn đề này; nếu Flatpak chọn một mô hình hoàn hảo về mặt kỹ thuật thì ngược lại có thể đã tạo ra rào cản gia nhập quá lớn cho các nhà phát triển ứng dụng, đặc biệt là nhà phát triển đa nền tảng, khiến chính Flatpak khó được phổ biến
  • Cho rằng mô hình quyền theo từng instance rất hấp dẫn, nhưng với phần cấu hình môi trường như git config, thư mục font v.v. thì một phương án lai, cho phép tùy chọn để mọi instance có cùng quyền truy cập, sẽ thực tế hơn
  • Cho rằng cách làm đúng là thiết kế lại toàn bộ hệ điều hành để cấp riêng quyền hạn (capabilities) cho từng instance đang chạy, hỗ trợ quota đĩa, logging, proxy, phân tách quyền tinh vi và nhiều chức năng khác; đây không chỉ là vấn đề riêng của Flatpak
  • Với power user hoặc người dùng nhạy cảm về bảo mật cần mức cô lập triệt để như QubesOS hay sandbox dựa trên hypervisor thì tách biệt theo từng instance là tốt; nhưng với đa số tác vụ cô lập, cách tiếp cận trực quan hơn là thực hiện bên trong chính ứng dụng; giống như sandbox của trình duyệt web, Flatpak lý tưởng nhất là nên hỗ trợ nested sandbox, nhưng hiện vẫn chưa hỗ trợ; còn tồn tại nhiều vấn đề khá phức tạp như liên kết giữa code signing và sandbox, hay UID namespace
• Là người dùng Flatpak nhiệt thành trong thời gian dài, người viết cho rằng nó từng rất đột phá và giúp dễ dàng dùng ứng dụng mới nhất trên mọi bản phân phối Linux, nhưng vì vài năm qua không có thay đổi nên dần mất hứng thú; hiện nay hầu hết nhu cầu đều được đáp ứng bằng AUR và cảm thấy tiếc vì Flatpak đang chững lại
  • Với tư cách người dùng, ngoài điểm dễ dùng thì gần như không có trải nghiệm tốt nào với Flatpak; có nhiều vấn đề tích hợp về theme, con trỏ, file picker, quyền, Drag&Drop, lại cần thêm công cụ để dùng một số tính năng; nếu UX kém thì lợi ích bảo mật như sandbox cũng trở nên vô nghĩa; cho rằng nếu Linux không có vấn đề về tính di động của binary thì đã không cần Flatpak
  • Từng cảm thấy bộ Fedora + GNOME + Flatpak rất đột phá, nhưng gần đây lại quay về Arch; kho Arch giờ phong phú hơn nhiều và gần như không còn phải dùng AUR nữa
  • Hỏi người từng quản lý nhiều gói về trải nghiệm với makedeb, đồng thời nhắc rằng makedeb dựa trên PKGBUILD nên có tính di động cao, và thắc mắc vì sao nó không được biết đến nhiều hơn
• Không hoàn toàn đồng ý 100% với quan điểm của Drew DeVault rằng “bản phân phối phải chịu trách nhiệm đóng gói ứng dụng”, nhưng có giới thiệu bài viết tranh luận lâu năm cùng liên kết tham khảo; đây là góc nhìn cho rằng mô hình cộng đồng (bản phân phối) đại diện người dùng để quản lý gói là đúng đắn, còn mô hình đóng gói ngoài bản phân phối như Flatpak/Snap/AppImage thì về bản chất là không tốt
  • Có người phản bác rằng chính nhà phát triển trực tiếp tạo ra ứng dụng mới là bên phù hợp nhất để quản lý việc đóng gói; nhất là với phần mềm nguồn đóng, quyền phân phối và đóng gói thường bị độc quyền về mặt pháp lý; ngay cả với mã nguồn mở, việc người ngoài nhóm nòng cốt tùy ý can thiệp vào đóng gói chỉ tạo thêm bug, trì hoãn phát hành và phát sinh vấn đề mới; họ muốn cập nhật nhanh, mới nhất và phần mềm nguyên bản không bị chỉnh sửa trong quá trình đóng gói; cho rằng vấn đề là Flatpak đang cố làm quá nhiều thứ, đồng thời cũng hoài nghi mô hình app store nói chung; trên Windows và macOS vẫn có thể tự do phân phối binary mà không cần app store, và tối thiểu hệ điều hành đã cung cấp bảo mật ở cấp OS như code signing; không cần một hệ thống đóng gói do bên thứ ba dẫn dắt
  • Cho rằng nhà phát triển ứng dụng phải có quyền tự phân phối, lấy trải nghiệm cài đặt đơn giản trên Windows làm ví dụ; không thể kỳ vọng maintainer đủ quy mô để hỗ trợ mọi bản phân phối, và đây là một lực cản đối với sự phát triển của desktop Linux
  • Chỉ ra rằng việc phải đóng gói thủ công cho từng bản phân phối khác nhau lại càng làm giảm ý nghĩa của toàn bộ việc này
  • Nêu ý kiến rằng để bản phân phối đóng gói toàn bộ phần mềm trên thế giới là điều phi thực tế
  • Từ lập trường cho rằng bản phân phối đóng gói ứng dụng không tốt, người viết vui vì Flatpak ngày càng được chấp nhận; nhà phát triển phải có thể dễ dàng phân phối ứng dụng của mình mà không cần trung gian
• Đồng tình với chỉ trích rằng Flatpak vẫn tiếp tục dùng PulseAudio nên bị chậm chân trong việc tiếp nhận PipeWire; PulseAudio gộp quyền loa và micro nên không thể tách riêng, nghĩa là chỉ cần cấp quyền phát âm thanh cho ứng dụng thì về mặt thực tế nó cũng có thể truy cập micro, tạo ra một lỗ hổng bảo mật lớn
  • Có người nói rằng người dùng Linux thường chế giễu lỗi thiết kế hay sự thiếu tự do trên Windows/macOS, nhưng cũng phải thừa nhận những lỗi thiết kế mang tính bản chất như thế này; họ cho rằng hệ sinh thái Linux có xu hướng bỏ mặc vấn đề mà không làm rõ ai chịu trách nhiệm
• Từng cài VSCode/Codium dạng Flatpak để debug Python, nhưng vì vấn đề quyền và cấu hình nên mất rất nhiều thời gian để thiết lập debugger; cuối cùng cài bản Snap thì mọi vấn đề đều được giải quyết
  • Cho rằng Flatpak phù hợp với các ứng dụng desktop cỡ lớn như Chrome hay Chromium, nhưng không phù hợp với công cụ hệ thống
  • Chia sẻ rằng bản Flatpak của Emacs chỉ mang lại sự kém hiệu quả và thất vọng
• Khi chuyển sang dùng bản phân phối immutable theo hướng Flatpak, lúc hợp thì rất tốt, nhưng có nhiều thứ không hoạt động hơn dự kiến nên không đạt kỳ vọng; ví dụ chạy công cụ bên ngoài cho Godot, chỉnh nhiều quyền, vấn đề tương tác giữa các Flatpak với nhau như Firefox và KeepassDX, crash của Godot và Krita dạng Flatpak, hay môi trường lai với AppImage/.rpm không phải Flatpak; từ đó bày tỏ mong muốn Flatpak có thêm nhiều đổi mới hơn
• Flatpak có cấu trúc không thể dùng để đóng gói các ứng dụng cần tạo giao diện mạng ảo như Tailscale; trong khi đó macOS có API cho phép phân tách chi tiết quyền mạng, nên Tailscale vẫn có thể được phân phối trên Mac App Store dưới dạng ứng dụng sandbox
  • Chính nhờ API đó mà ứng dụng sandbox của Tailscale trên macOS có thể được phát hành; ngược lại, trên các bản phân phối Linux “atomic” phụ thuộc vào Flatpak như Silverblue hay Bluefin thì việc dùng kiểu phần mềm này lại rất khó
  • Cho rằng Flatpak có ý nghĩa với các ứng dụng desktop lớn như OBS Studio, còn Tailscale hoạt động như dịch vụ hệ thống thì gói mặc định của bản phân phối phù hợp hơn; trên Arch Linux nó tồn tại dưới dạng gói chính thức
  • Dù trong Flatpak có thể đi đường vòng bằng flatpak-spawn, polkit-exec v.v., nhưng như vậy gần như phải từ bỏ luôn lớp bảo vệ sandbox
  • Nghi ngờ rằng việc cố giải quyết đồng thời hệ thống quyền tinh vi ở tầng trên cùng của Linux và cả bài toán đóng gói đã trở nên quá phức tạp; đây cũng có thể là lý do khiến Flatpak trì trệ hoặc khiến nhà phát triển bị kiệt sức; vì Linux hiện đại không có hệ thống quyền hạn nền tảng đúng nghĩa, nên trước khi nói đến thiết lập quyền hoàn hảo, ưu tiên thực tế trước mắt vẫn là phân phối phần mềm, đóng gói và cập nhật
  • Cho rằng những thứ như Tailscale nên đi theo hướng sysext (system extension), còn Flatpak thì không phù hợp
• Liên quan đến đề xuất phát hành qua Flatpak, người viết phát triển ứng dụng KmCaster dựa trên Java và từng được yêu cầu port sang Flatpak, nhưng chỉ cảm nhận thêm gánh nặng như phải có hai cách cài đặt, quản lý thống kê tải xuống, tin cậy kho bên thứ ba, tăng thêm package manager mới và trùng lặp kho; trên thực tế không thấy lợi ích rõ rệt
  • Dù vậy, vẫn nêu một số mặt tích cực của Flatpak như sự tiện lợi trên bản phân phối immutable, không còn phải lo quản lý phiên bản Java, được hiển thị trên tìm kiếm của Flathub và cập nhật tự động
• Dù không phải maintainer hay nhà phát triển mã nguồn mở, người viết không hiểu vì sao vô số bản phân phối Linux đều cùng gặp một bài toán quản lý gói mà lại không thể hợp sức để tập trung cải thiện và phổ cập Flatpak
  • Có ý kiến cho rằng mỗi bản phân phối có cách làm “distribution” khác nhau nên khó thống nhất thành một; sự đa dạng lựa chọn chính là ưu điểm của hệ sinh thái mã nguồn mở, và cá nhân họ vẫn thích package manager hệ thống truyền thống hơn
  • Theo logic đó thì chẳng khác nào chỉ nên tồn tại GNOME, trong khi sự đa dạng của cộng đồng và đa dạng trong cách ra quyết định mới là điều quan trọng
  • Flatpak hoàn toàn không có ích gì với bản thân người viết, và họ không muốn bị ép phải đóng góp cho một phần mềm mình không dùng đến