I'll always avoid #flatpak when possible.

(Flatpaks are infinity times better than Snaps, those are almost just malware (as of 2019, I haven't checked since...))

@foxxy I'm a big Linux enthusiast but aside from a handful of compsci courses more than a decade ago, I don't really know how the OS works "under the hood."

That having been said, its my intuitive understanding that designing something to be able to run everywhere means it is not optimised for anywhere. Most of the time this is not a problem because disk space and processor cycles are generally abundant, and are increasing faster than Linux's bloat.

However, my highly developed sense of aesthetics is turned on by the simplicity of something the computer runs "natively"

@PetrichorSquirrel Oh noes, I'm resisting the urge to go into detail about how OSes work "under the hood" x3

But also saddened that some are co-opting the terms to instead mean, "everything is Node.JS inside Chrome, running on AI". I reject those new definitions and co-opting.

@foxxy I honestly think the UNIX family of OSes are fascinating, and sometimes I will watch YouTube talks from people who are far more expert than me only to comprehend maybe 20% of it.

@foxxy

I think you are mixing two different levels of abstraction together i.e. libraries and packages. The former are for code only, the latter for anything software including config files, multimedia resources etc)
Flatpak just introduces an additional step to the deployment of software packaged in advance, with huge advantages, including being anti-hysteresis (it can update apps while you are using them without disk/RAM conflicts, 'cause the new version is used only the next time you run it)

@foxxy

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?

@foxxy

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).

@foxxy

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 specified that I'm discussing "Flatpak (vs static + dynamic linking)". I'm pretty sure I have the correct idea that Flatpak is meant to handle dependencies between different software libraries, while handling permissions between apps and resources. Static and dynamic linking (and an accompanying packager, which Flatpak also acts as) is also meant to handle relationships between these libraries.

@foxxy

Flatpak doesn't handle dependencies except installing the needed runtime for an app.

The dependencies are handled by the distro and languages package managers, Flatpak just care about the last step of the delivery, as I already said.

Static vs dynamic linking has nothing to do with this, that is about libraries used by compiled languages and we are always talking about dynamic here.

@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.

@alxlg DBUS (and similar, DCOP maybe?) is still super neat and useful.

@foxxy

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 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?

@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?"

@foxxy

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?

@foxxy

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.

@foxxy AFAIK it is just not that easy. You can likely ship assembler comiled binaries or whatever to read files with open() syscalls.
I mean in turing-complete languages unless you have a real sandbox you cannot limit what they do. Or other clever woerkarounds.

So if you want a permission model, you need a sandbox.

@foxxy I am not sure what https://wiki.archlinux.org/title/Bubblewrap #bubblewrap actually does, biut aparently the syscall filtering you propose is actually part of it #seccomp. Plus much more sandboxing technologies…

@foxxy other things you said:
* hard linking: yes, AFAIK this is what #AppImage's do. In Essense you get many big binaries, also not ideal and would waste space. #flatpak deduplicates such stuff.
* share libs are of course always made, The problem is that distros adapt it, have different versions and sometimes things break. Testing against one target is just way easier and more like devs are used to nowadays.
* flatpak runtime? Yeah, but 90% of distros have it. If not, it's 1 thing to install.

@rugk Somebody else who has now deleted their comment enlightened me to the fact that Flatpaks do a few things well:

• "Static lib" dedupes - implementing it as I propose is difficult and problem prone, Flatpak-style containers will always do it better
• Anti-hysteresis: for apps that have multiple executables, Flatpak-styles handles hysteresis gracefully.

Among other things, I'm still really upset that Flatpaks reversed certificate progress for me by years, for not enough benefit to offset.

@rugk For my concern about having to create a new Flatpak runtime for a new OS/distro/DE, I was assured that the Freedesktop runtime has few/no dependencies, so it should provide Flatpak support out of the box even if it doesn't integrate well - which is fine, since in this hypothetical a new OS/distro/DE is being made, so we can live with that, plus it could provide a foundation for the developer(s) to modify incrementally as they have time. I have no way to verify this though.

@rugk I had also argued that I'd prefer distros adapting and having different versions of shared libraries to provide distro/DE-specific features, because the Flatpak alternative requires going through the DBUS which I argued has a few disadvantages:

• Overhead, is slower
• Requires DBUS (yes, I know about the Freedesktop Flatpak runtime)
• Requires the library to have a "Portal", which is another tax, instead of just an ABI, which will probably be implemented underneath anyways

@rugk Oh but Flatpak Portals also enforce a single Response-style results. Normally I'm very much against forcing an API style, but I've many headaches working with different libraries that all returned their results in different manners, so from a practical standpoint I'm leaning towards Portal Responses.

@alxlg De-duplicating statically linked libraries in apps would be difficult without a Flatpak style package format, good point.