I still don't get the whole #flatpak thing (vs static + dynamic linking). It all seems so difficult and complex. Why not just...
- want a specific version of libfox? -> statically link libfox v6.9
- want per-interface permissions? -> make a new dynamic linker that prompts the user, "do you want to allow this app to access libfox? yes/no" OR have the linker read declarations at package time (allow/deny/ask).
- want a unified api? -> make a new shared library
(1/?)
- want per-file/resource permissions? -> have an interpreter or libc that implements open() et.al. to either ask the user, or reads the declarations made at package time (allow/deny/ask).
Also, #flatpak requires the OS to implement the flatpak runtime. Got a new OS (/distro/DE)? Well now it has to implement the flatpak and dbus apis before flatpaks work, instead of just relying on individual shared libraries.
(1/2?)
Flatpak is relatively easy to package because doesn't require many dependencies, its Bubblewrap sandbox interfaces with the kernel's namespaces and cgroups just like containers, and indeed all distros have it (as opposed to Snap). Flatpak doesn't require to implement anything, there is one "implementation" (it's not a protocol or spec). If the API you mean are Portals, those are implemented by the toolkits/desktop enviroments. In practice you pick the GTK or Qt one.
@alxlg A (hypothetical) OS/distro/DE, bestOS, isn't GTK or Qt but still has the concepts of "ask the user to select a file to open" and "increase music volume by 10%", which can easily be accessed by calling bestos_ask_user_to_select_file() and bestos_increase_music_volume_by_10p(). How would Flatpak/GTK/Qt handle that?
If something has to implement a DE without GTK or Qt, implementing those trivial Portals is the least of their problems.
Flatpak has nothing to do with that example, because we used DBUS for that kind of things for ages anyway.
@alxlg Isn't a library call (even if it's through an intermediate library which handles the ask user for permission prompt), faster than a DBUS interface call? Yes, I'm aware that DBUS has a very low overhead compared to other, previous solutions, but DBUS itself is still based on the idea of calling functions in code, which then the DBUS interfaces are built upon (and thus overhead which isn't compiled away).
I don't know what you mean nor what this has to do with Flatpak but I suspect you have a very wrong idea of what Flatpak is supposed to be...
@alxlg I'm saying that in the context of my last post, Flatpak + DBUS adds a overly complicated, useless, slow, and unnecessary overhead when doing IPC.
Again, IPC is at a lower level of abstraction, Flatpak is about applications, that are abstracted on top of all the concepts you mentioned, including processes.
Calling this overhead is like criticizing a chainsaw for not being as light as a bistoury, looking at the fact they both are meant to "cut" and missing the elephant in the room: they are different things meant for totally different use cases.
@alxlg I being being light and bistoury are somewhat related to use cases. If something takes additional steps to reach supposedly do the same function, then it doesn't really do the same function: it produced additional side effects that weren't expected, it probably skipped steps that the user normally expected, and it probably didn't produce the expected results.
@alxlg Alternatively, https://github.com/flatpak/xdg-desktop-portal/issues/655 can be discussed instead. How will this problem be resolved? Right now this is completely broken: if Flatpak is being marketed towards the GP (General Public), then the user should not be expected to know that an app runs in a sandbox called Flatpak, or know that they must configure flatseal to somehow permit Firefox to interact with PassApp, or worse: know to write a script file and put it in some obscure dot folder.
@alxlg If we were instead using dynamic linking, static linking, and libc; this would just work without the developers of Firefox OR PassApp making any changes. When a user tries to use a password manager in Firefox, Firefox would try to execute /usr/bin/PassApp-msg-srv. The system would pop up with a message similar to, "Firefox is trying to execute PassApp, is this okay? Yes/No, Remember choice?"
This workflow is exactly what Flatpak and Portals through dbus are meant to enable.
@alxlg But then implementing a new interface requires two steps: make the ABI so that normal software can use, and then make a portal so that Flatpaks can use it. When is udev going to function with Steam?
As always when someone is not able to argue against the idea or the design, they pick a use case not yet covered and try to imply the whole idea is bad.
Then modify your system to include all the software you need, give up running proprietary software securely and hope the distro of your choice maintain everything you need in a single tree of dependencies without conflicts.
@alxlg Look who can't argue against the idea of having things work correctly.
Proprietary software is mostly just malware, there, I said it. Software can still statically link dependencies which won't conflict which those installed in a similar fashion to Flatpak. Or it can dynamically link to versioned dependencies which coexist on the system (yes, I'm aware that this isn't well adopted with the popular Linux package managers yet). If a particular proprietary isn't a virus, (1/2)
@alxlg then it should eventually call open(), and open() will behave correctly while correctly handling permissions. With Flatpak, I'm assuming it'd rely on the Portal interface, which is still just an interface with a promise, but with extra steps.
I was beginning to believe Flatpak had some merits (static lib dedupe), but now I'm not so sure.
good luck with your idea
Thanks, enjoy your ban.
@alxlg Example: GTK is a toolkit. A user configures it to have all password text boxes do something: whenever the user enters a password text box, a mini game pops up and when completed the correct password is input into the field. I have never seen this work with Flatpak. How should a Flatpak app achieve this?