Flatpak 1.2 Released For This Widely-Used Linux App Sandboxing & Distribution Tech

[nanonyme]

Michael any idea why posts from older users would end up unapproved too?

[tildearrow]

Michael any idea why posts from older users would end up unapproved too?

It's because of the word "love". The forums disapprove of it and are so sensitive when somebody loves.

[Weasel]

OK, look. Are you really sure ELF is the problem here?

The global namespace issue is NOT in ELF, but rather the dynamic loader (ld-linux.so).
I think it may be possible to write a new dynamic loader that is compatible with the standard one, which can implement some sort of namespaces. If libdl has done so, then why can't we?

Yeah it's a problem with ELF's design, although obviously also the loader. The problem is that ELF even allows "stray' global symbols to exist at all. Sure, the loader can error on them, but really they shouldn't even be possible by design.

For example, let's look at PE/COFF as an alternative that gets this right (other things are also bad, but ELF also suffers from those though). I'll use the -> notation to say "points to" (i.e. a RVA or offset in file or whatever, it's RVA in PE/COFF but it doesn't matter what it is as long as you know where it points to).

Header -> Import Address Table (IAT), an array

IAT entry has multiple fields, but here's the two important ones:

IAT entry -> Module name (e.g. libfoobar.dll)
IAT entry -> Symbol table

Symbol table is an array of RVA pointers to strings that specify the symbol to import.

As you can see it is simply not possible to load symbols in PE/COFF without an associated module. There is no concept of "global" symbols or symbols without a module to import from. This is not about the loader only, it's about the format. The format itself CANNOT store symbols without a module. The symbols get linked from a table that must specify which module they are from.

Sure, ELF does have symbol versioning and other tricks to do the same behavior, but that's besides the point. It just shouldn't be able to store symbols without a module, at all, because people will always use the laziest way (and that's what it is), which is why it is used almost in every god damn library (except few ones like libc or stdc++), so flatpak has no choice.

And yes, this happens a lot in practice, especially with libraries that bump their major version. Devs usually use the same symbol names on the "updated" library. Let's use example gtk2 and gtk3. But you might ask, what app uses both gtk2 and gtk3?

The answer is that the app may not directly use both but it may well do so indirectly. If it depends on gtk2 and a bunch of other stuff, and your system only misses gtk2, you can surely supply libgt2k with the app (like flatpak does) and have it work, right? No, it may not work, it depends what the other dependencies on your system pull. If they pull in gtk3, or any other library that conflicts with gtk2's symbols, you're fucked.

This is why flatpak has to supply the entire runtime, down to libc: to ensure that other dependencies don't indirectly pull in some library that fucks your other app's dependencies up. And this problem exists mainly because of ELF.

Then, the app could just as well load plugins at runtime. Sure, it uses dlopen/dlsym for that, so there are no conflicts, but the plugin itself might link to gtk3 without using dlopen, so then it gets pulled in by the loader and you get fucked, again. I'm not sure if flatpak even solves this issue, lol, that's just how bad ELF is.

How many people are going to accept a different dynamic loader? Everyone.

How many people are going to accept using a new executable format? Very few...

True that, I wasn't talking about a necessarily practical solution, just outlining that flatpak's design is not only because of some dev, but rather because he was forced to do it that way to ensure maximum compatibility.

[Weasel]

The main issue there is apps don't update to latest version of runtime. Gnome.Platform 3.30 is based on Freedesktop.SDK 18.08 so there's a lot of reduced space impact. But you also have Freedesktop.SDK 1.6, Gnome.Platform 3.26 installed resulting in a much larger footprint. You could try flatpak update && flatpak uninstall --unused to see if some of those runtimes have become unnecessary by newer versions of apps.

Or how about the fucking GNOME runtimes don't break ABI ever and thus you will only ever really need to have the latest runtime because it is guaranteed to work with older apps as well? Like you know, every sane OS does, or even the Linux kernel for userland interface.

If you need to "break ABI" then make a new fucking function, call it funcname2 (like the kernel), or funcnameEx (like Windows). Same for types. Holy shit what a simple concept and we're in this mess because of retards not adhering to it.