Going In-Depth With Flatpak For Sandboxed Application Packaging

[Candy]

This is called an Ad Hominem attack.

I have to agree here. Feeling a bit dirty about that. But I wanted to bring that fact up here.

Look on assembly language forums? My favorite assembler, which is Flat Assembler, can compile itself (yes, it's written in assembler),

A little note: Assemblers assemble. They don't compile. That's why they are called assembler in first place.

[starshipeleven]

I already told you, that I am aware of that situation. What I tried to explain was this: The licensing issue could have been solved by reimplementing a free Qt Toolkit.

The licensing issue could have been solved also by implementing a different toolkit too. I don't see why you see competition as wrong.

Also given how Google vs Oracle case went, it's entirely possible that Harmony could have got nuked by lawyers.

Flatpaks are not the solution - but yet adds another level of insanity to the overal problems we have.

This is what happens when you don't control the full stack from development to deployment of applications. Welcome to the real world where VMWare is a thing because shitty applications must be kept isolated in its own Windows VM because it craps out on newer Windows or can't live in a OS where there are other applications it does not like, or it requires some ancient java runtime bullshit.

Android was designed around that from the start, so it can avoid the trickery, but that's how the modern world is.

We dislike the others that do the same. So lets implement the same idea differently, so we can stay in control if it. Nothing else are Flatpaks. Red Hat trying to be in competition to Snap and Co.

Afaik flatpacks (as xdg-app) predate Snap by years.

[Hugh]

These comments are fascinating and depressing.

I've had only modest problems writing portable code that is long-lived in the UNIX/Linux world. Virtualization/containerization/flatpack/snap don't solve my problems, they just add more complexity.

That's surely because I don't depend on GUI libraries. And I use an ancient language, C.

All GUI support appalls me. The libraries are complex, ever-changing, and seem to get in the way of solutions. The only solution seems to be even more layers of library.

The problems with the Python 2 to Python 3 transition would seem show how languages can cause migration problems.

[starshipeleven]

Look on assembly language forums?
My favorite assembler, which is Flat Assembler, can compile itself (yes, it's written in assembler), and guess what the Linux version uses? Not a single library.
And on those forums see what programs people come up with.

I'm not doing your homework for you.

Btw my favourite compiler is gcc, as I can actually compile stuff I use at work or my Arduino for sensors or home automation or OpenWrt firmwares for my network devices. And I don't give a shit about the amount of libraries or other build dependencies involved.

What do you compile on Flat Assembler?

Windows has its own SSL API. Just because you want to use the openssl library doesn't mean anything. That's like saying you want to use Qt on Windows for the GUI instead of its myriad of GUI libraries, and complain that it doesn't bundle it, wtf kind of argument is that?

Dunno, I've seen way too much software bundling (outdated versions of) that library on Windows, I assumed that people disliked Windows SSL API.

If the Windows API was so small Wine would have been a finished product long ago.

Hehe, it's not that, it's all the legacy that must be carried over, and corner cases and all the profiling for specific applications to make sure that they get the exact same interface (with the original bugs and whatnot) they got back then when they were released.

Really, not even the developers making C# businness applications I then have to run in VMs on servers (because none gives a crap about having to troubleshoot it 4 years later when some update crashes the software) believe all the kool-aid about windows API being so stable and all.

Especially .net frameworks, that's one massive clusterfuck same as java.

Wasn't chroot made so you can change root during the initrd?

No it was invented as a simple form of sandbox/isolation for issues similar to the ones you mentioned https://en.wikipedia.org/wiki/Chroot

And clearly it's not sufficient since otherwise flatpak wouldn't exist in the first place.

Chroot was never meant to protect against malicious attacks, in 1980 that wasn't even a concern.

I don't see how that is any different than using a library. Using a library is in its own way, "writing code for you". Especially if you static link it (because then it's really part of your code).

If you don't see the madness and the horrible bullshit because someone has implemented rails for you does not mean that all is good. It only means that you are not aware of the abstraction layer.

Flatpack still aims at solving the same problem, with a different approach because on Linux there isn't even a "theoretical single source for all OS libraries" like you believe is the case for Windows, so none can enforce the "rigorous and holy stability and retrocompatibility" you believe happens on Windows.

[ZeroPointEnergy]

I want a sandboxed PDF viewer so a bug in the parser/interpreter/renderer won't lead to malware infection.
I want a sandboxed media player so a bug in the decoder won't lead to malware infection.
I want a sandboxed web browser so a bug won't lead to malware infection.

Ok, I think I see the pattern here. You want the malware directly from the flatpack "appstore" and not because of a bug in the software.

[theghost]

Don't know about that, I've gone entirely Flatpak for Steam myself and the only issues I've run into that could be linked to being a Flatpak is with Northgard having really strange libs as dependencies, and with the Steam Controller over BLE not working until Flatpak 0.11.8
On the other hand, what switching to a Flatpak package has done for me is solve several issues I've had due to running a rolling release distro, the client has only crashed twice since the switch last year instead of the three to four times a week it used to crash when running natively.

I guess I could argue that the sandboxing causes Discord to not be able to track my currently active applications, but I honestly am happy about that.

On my last test of Flatpak for Steam, on a clean Fedora 28 I ran into several issues.
I had to manually update flatpak repositories via terminal to get Steam running at all.
After trying Streets of Rogue, I realized that the controller did not work and sound was missing.
Then I saw the issue tracker with several game issues.

I really like the idea of a Flatpaked Steam and Flatpak in general but I just wanted to point out that there are currently several issues with it and things may not work.
We could really need Valve putting some resources into making Steam first class.

Until that time I will use the package of my rolling distro, which works without any issues.

[-MacNuke-]

Nope. Dependencies to other flatpak packages (like the runtimes) is what most applications do.

Yeah, and those dependencies are pretty much complete distributions (the freedesktop.Platform Runtime is >500MB, just installing Steam adds >1GB of runtime stuff). I know that there is some sharing but "as it is now" you end up having multiple version of the same library installed. Like when some apps depend on GNOME 3.24, 3.26 or 2.38, or KDE in different versions. Every app for itself has to be brought up to the newsest runtime + its own depencies. Meanwhile your systems gets cluttered with runtimes additional to your normal Linux installation that you are using.

The linked bug report is about slow updates in the Mesa flatpack package, while points out that NVIDIA's driver flatpack (which is independent from it) is kept updated more regularly.

And? Does not change the problem. Flatpak apps come with their own version of Mesa. There is pretty much no simple way to upgrade to a newer version except for upgrading everything yourself. Why do we have distributions again?

with flatpack when you integrate a library you don't give a shit about any other application and causing breakage

Yeah and you probably don't care for updates. So one has to go through all packages and search for every additional library that is packaged with it. Or you hope that this one flatpak maintainer does a good job. Or you have a problem like I had. The download link inside that flatpak was not available anymore.

Typically you choose a distribution based on your needs or taste. If you want more LTS maybe you choose a Debian release, if you want more bleeding edge you could choose ArchLinux. flatpak just fucks up all of this by putting just another arbitrary release-schedule on top of your distribution.

Like I said, it may be nice for some closed source stuff because they typically don't care for upgrading their dependencies (just like they do (not) on Windows) or don't want to handle different library versions if there is a break (like OpenSSL)... Additional to that it can reduce the risk of additional spyware that sometimes comes with it (like the newest "Red Shell" in games). So I am not against flatpak in general.

But I don't see any point putting typical Open Source apps inside flatpaks.

[Weasel]

I'm not doing your homework for you.

Btw my favourite compiler is gcc, as I can actually compile stuff I use at work or my Arduino for sensors or home automation or OpenWrt firmwares for my network devices. And I don't give a shit about the amount of libraries or other build dependencies involved.

Lol man, GCC is not even an assembler. It's not even part of the same toolchain, the assembler is part of binutils (GAS). I don't know what homework you speak of, but I clearly don't have an assignment to give you. If you're too lazy to simply go to the asm forums, like the flat asm, and see their sections dedicated to projects.

Not to mention that, well, you've conveniently ignored that the assembler itself is written in pure assembler using only syscalls. So yes, I've already answered your question, why is it my problem that you're not satisfied with it.

And btw GNU GAS is absolute shit compared to FASM or NASM or YASM or any proper assembler. It doesn't even do multi passes, lol. It's the dumbest assembler to code stuff in, because it's meant to be used as a back-end to compilers mainly, so mostly compiler-generated code. FASM's macro capabilities are insanely powerful, you can even use it as a scripting language (literally, process data files with the macros...). With GAS, you can't even forward reference a label for data usage or do complex conditionals in code (e.g. if alignment is 2, insert X data here, if alignment is 4, insert Y data here -- to keep the caches as hot as possible and close together, but that's not possible with GAS!). FASM can even solve simple linear equations with its multi-pass design (internal variables ofc).

And guess what? It's written fully in assembly language, like I said before, only using syscalls. Because nobody would write it for an unstable shitty userland, especially not in asm.

Dunno, I've seen way too much software bundling (outdated versions of) that library on Windows, I assumed that people disliked Windows SSL API.

People are free to use what they want, not to mention maybe the guy even wanted an easier way to port it to Unix or whatever etc.

Keep in mind that the reason you can bundle DLLs on Windows with the application itself is due to Windows' superior design. You can't do that on Linux, as explained in the other flatpak thread. The reason is the ELF shared object's design being fragile: only symbol names are looked up, without the module. That's why LD_PRELOAD hacks even work.

So it is impossible on Linux, without manually using dlopen/dlsym (analogous to LoadLibrary/GetProcAddress on Windows), to import a symbol from a given module. It's impossible to import two libraries that have a common symbol. This often happens when two libraries are the "same" library but different (incompatible) versions.

In Windows? Not a single problem, because DLLs import symbols from a specific module only. (or just import specific indices/ordinals from a module)

See: https://stackoverflow.com/questions/...erent-versions

You know the Linux userland is shit when you're literally told to "static link" to solve your issues. Period. See the link above.

Hehe, it's not that, it's all the legacy that must be carried over, and corner cases and all the profiling for specific applications to make sure that they get the exact same interface (with the original bugs and whatnot) they got back then when they were released.

Really, not even the developers making C# businness applications I then have to run in VMs on servers (because none gives a crap about having to troubleshoot it 4 years later when some update crashes the software) believe all the kool-aid about windows API being so stable and all.

Especially .net frameworks, that's one massive clusterfuck same as java.

Huh? "Legacy" that must be carried over is already implemented in Wine (well not all of it since it's huge). That has nothing to do with it being small, on the contrary. It means that it only gets bigger with each day. Really, this is absolute hilarious way of thinking. Removing "legacy" APIs is not going to magically implement new APIs, wtf LOL.

I don't know about .NET, I don't care about it since it's not native code.

No it was invented as a simple form of sandbox/isolation for issues similar to the ones you mentioned https://en.wikipedia.org/wiki/Chroot

Chroot was never meant to protect against malicious attacks, in 1980 that wasn't even a concern.

Flatpak is not for security, it's for application distribution. Even the official site says it. If it does offer extra security, that's a side effect of sandboxing.

If you don't see the madness and the horrible bullshit because someone has implemented rails for you does not mean that all is good. It only means that you are not aware of the abstraction layer.

Flatpack still aims at solving the same problem, with a different approach because on Linux there isn't even a "theoretical single source for all OS libraries" like you believe is the case for Windows, so none can enforce the "rigorous and holy stability and retrocompatibility" you believe happens on Windows.

This has nothing to do with a single source for all OS libraries, don't kid yourself. Qt for example has a single source, so why the fuck does it break compatibility every few years? What a sorry way of thinking, don't shoot yourself in the foot like that.

Really the fact that you compile this "abstraction layer" into your app means that your app will always work and in the end only link to the "stable horrible API", just like on Linux if you were to statically link everything (your app would use syscalls directly).

But you forget the fact that 99% if not more of the Windows libraries are NOT just wrappers to syscalls. They actually perform userland work. And yet, they're still stable. Because Windows has a stable userland.

This means, unlike flatpak or statically linking in Linux, your app doesn't have to be 500MB due to a 500MB runtime bundled with it or statically linked bloat. You can easily use Windows APIs since they won't break.

Or you can bundle it with shit-tier libraries that break every 2 years and have your app be 50MB for a simple one that would be less than 1MB, which is the case with all Qt-based apps on Windows.

I think that says everything. Refuse to use Windows' stable APIs and you get a massive amount of bloat. That's not Windows' fault, it's YOU (the developer) for picking a shitty UNSTABLE Linux userland library to code with so that you have to "bundle" it with your app. In effect, you're ignoring Windows' power.


Now if only Linux learned from the good parts of Windows and what makes it so successful and why developers love it... well, Linux technically did (the kernel did), it's the userland GNU/Linux libs that didn't

[Weasel]

Typically you choose a distribution based on your needs or taste.

What if I want a distribution where all my applications will "just work" and where I can download apps not "built specifically for this distro" from the developer's site? Like, you know, on Windows (or mac maybe).

Where's this stable-userland distro for me and perhaps 90% of desktop users? (those that use Windows)

You know, kind of like flatpak does, except it's incredibly bloated. That's a Linux unstable userland problem tho, other OS (e.g. Windows) don't have this "problem" and don't need flatpak in the first place.

(also my other post is awaiting moderation atm)

[spstarr]

Keep in mind that the reason you can bundle DLLs on Windows with the application itself is due to Windows' superior design. You can't do that on Linux, as explained in the other flatpak thread. The reason is the ELF shared object's design being fragile: only symbol names are looked up, without the module. That's why LD_PRELOAD hacks even work.

So it is impossible on Linux, without manually using dlopen/dlsym (analogous to LoadLibrary/GetProcAddress on Windows), to import a symbol from a given module. It's impossible to import two libraries that have a common symbol. This often happens when two libraries are the "same" library but different (incompatible) versions.

In Windows? Not a single problem, because DLLs import symbols from a specific module only. (or just import specific indices/ordinals from a module)

You can actually load the same symbol from two libraries, or even just one "sorta" the trick is - and just about nobody uses except GNU libc/libstdc++ - is tagging versions to symbols ie, strlen@LIBNAME_2.3.3. I am told doing this is tricky since you need to keep track of versioning but for flatlak it would be useful for ALL library developers to tag symbols - one DSO - many versions in one, could get messy though, you'd use dlvsym()

http://web.archive.org/web/201601070...om/blog/?p=103