Going In-Depth With Flatpak For Sandboxed Application Packaging

[phoronix]

Phoronix: Going In-Depth With Flatpak For Sandboxed Application Packaging

Red Hat / GNOME developer veteran Matthias Clasen has recently begun a series of blog posts going in-depth with Flatpaks for those wondering how this application deployment technology is taking over the Linux desktop...

http://www.phoronix.com/scan.php?page=news_item&px=In-Depth-Flatpak

[-MacNuke-]

Well... the general idea of flatpak is that every application becomes its own Linux distribution without the Kernel. Its pretty sad when now your application does not run anymore or runs slow because it comes with its own version of Mesa that is too old to support your GPU.(see https://github.com/flatpak/freedeskt...ages/issues/71 )

And if the flatpak runtime does not have a library you need, you need to compile this stuff yourself in your build script. So the app developer also becomes a package maintainer...

While it is nice for some closed source bullshit that always breaks I don't see any reason to use it for Open Source software. Just putting multiple distributions on top of each other just for arbitrary sandboxing is a little too much for me.

[starshipeleven]

Well... the general idea of flatpak is that every application becomes its own Linux distribution without the Kernel.

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

Its pretty sad when now your application does not run anymore or runs slow because it comes with its own version of Mesa that is too old to support your GPU.(see https://github.com/flatpak/freedeskt...ages/issues/71 )

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 if the flatpak runtime does not have a library you need, you need to compile this stuff yourself in your build script. So the app developer also becomes a package maintainer...

Compiling a library and shoving it in a flatpack package isn't anywhere near the main role of package maintainers.

For example, with flatpack when you integrate a library you don't give a shit about any other application and causing breakage in it nor about someone else updating it in the distro causing breakage in your program (as it's used only by your program, and kept at the version you want it to), while package maintainers have to deal with that on a regular basis.

[Weasel]

While it is nice for some closed source bullshit that always breaks I don't see any reason to use it for Open Source software. Just putting multiple distributions on top of each other just for arbitrary sandboxing is a little too much for me.

Closed source bullshit? Ever wondered why Windows has vastly more applications? Because it's much more friendly to developers, open source or not.

No sane developer wants to be reliant on a package maintainer's mood for a given distro. He wants to distribute his application once and have it work, just like on Windows. Most of them who deal with Linux are sick of users requesting that they build a package for distro X, Y and Z because the "official" packages don't contain it.

Centralized bullshit just stinks to begin with.

Not only that, but even if people were to support just one distro flavor (because there are some people who think each distro is a "totally separate operating system", just lol), you'd still have to provide packages for every fucking distro version. Do you see people compile for Windows XP, 7, 8, 10, separately on Windows land? No, they set a minimum target (e.g. Windows 7) and compile/distribute one version that works on 8 and 10 as well. Only in Linux would you need to compile for every fucking distro version, Ubuntu 14.04, 15.04, 16.04, 17.04, 18.04, and god knows what else. And that's just Ubuntu!!!

I mean even Linus Torvalds, the kernel man himself, said he dislikes distributing binaries for Linux precisely for this reason. Anyone who disagrees obviously doesn't understand developer viewpoints. This is why some devs even prefer to just "support Wine" instead of port to Linux, because Wine has a stable ABI and you distribute once and it works on all distros that have Wine installed (well, because Wine uses Windows' API obviously).

If we never had this package maintaner centralized bullshit in the first place, we'd have a proper stable ABI by now across all distros, because it would have been a requirement for Linux to survive, just like Windows.

That said, I do dislike the sandbox approach, however I can't really find a universal solution for literally all apps right now (as from the other thread). If it's just simple library dependencies then it's easily solved without a sandbox, but unfortunately there's more than that (e.g. dependencies on sockets, services, dbus, etc). So for now I guess sandbox is the only way that works on "everything".

Of course this wouldn't have been a problem in the first place if the FIRST PRIORITY of userland dependency developers was stable ABI and backwards compatibility. But I digress, package managers made people a little dumb here, which is why Linux is in the poor shape is in right now in regards to desktop usage.

[uid313]

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.

[theghost]

Just if you're curios about using flatpaked Steam: https://github.com/flathub/com.valve...e.Steam/issues
Seems like Flatpak still has a long way to go.

[starshipeleven]

Of course this wouldn't have been a problem in the first place if the FIRST PRIORITY of userland dependency developers was stable ABI and backwards compatibility.

Yeah, let's chain library developers to their chair and hit with a stick those that don't keep our holy applications working without us having to move a finger.

That's a great idea, wonder why it was never put to work in the real world, even on Windows, and MacOS has a flatpack-like "application image" system since ages back.

Guess what? Library developers have the same issues as everyone else, if you force too much stability and retrocompatibility then the codebase becomes an unmaintainable mess, or it isn't developed much at all.

Do you see people compile for Windows XP, 7, 8, 10, separately on Windows land? No, they set a minimum target (e.g. Windows 7) and compile/distribute one version that works on 8 and 10 as well.

You know why? Because on windows you don't usually rely much on system libraries, and most stuff you need is shipped by the application itself.

This is why some devs even prefer to just "support Wine" instead of port to Linux, because Wine has a stable ABI and you distribute once and it works on all distros that have Wine installed (well, because Wine uses Windows' API obviously).

Same as above, all libraries are shipped by the application itself.

But I digress, package managers made people a little dumb here, which is why Linux is in the poor shape is in right now in regards to desktop usage.

FYI: the "installer" applications that run on Windows to install an application are basically self-propelled package managers.

The applications on MacOS are also distributed and installed through what is basically a package manager

The main difference is that on both Windows and MacOS applications carry all libraries they need, and there is no sandboxing.

[Weasel]

Yeah, let's chain library developers to their chair and hit with a stick those that don't keep our holy applications working without us having to move a finger.

That's a great idea, wonder why it was never put to work in the real world, even on Windows, and MacOS has a flatpack-like "application image" system since ages back.

Guess what? Library developers have the same issues as everyone else, if you force too much stability and retrocompatibility then the codebase becomes an unmaintainable mess, or it isn't developed much at all.

Obviously it is. Numbers speak for themselves. And also nobody really cares about macOS that's why it's dead on the desktop *and* the server. Really way to shoot your own foot.

Windows never breaks its APIs or ABIs, they might drop some, but they never add a parameter or whatever. If they have to, they add a new function, with the Ex suffix, or an entirely new API. Because Microsoft are sane. That's why 3rd party developers love coding for Windows and not Linux.

Linux kernel never breaks its APIs or ABIs, which is why it's so popular (even e.g. on Android). This is one of the highest priorities of Torvalds because he knows what he's doing, unlike userland dipshits.

At the other end we have the "desktop GNU/Linux" with its pathetic market share and people begging for developers to port their apps to it (or cursing those that don't).

If anything this idiotic library developers are the reason desktop Linux never took off. It's not the kernel, so it's technically not "Linux" that is at fault. The kernel is supremely sane in its compatibility, it's the idiotic library userland that drags it down. Why the fuck is it so hard for them to do a proper design first and then later ADD NEW FUCKING FUNCTIONS and NEVER replacing (re-using same names) of existing functions? If a new function does what an old function does, only better, then just make the old function a stub that calls the new one, such as the ANSI version of Windows APIs. See? It's not hard at all.

I know you disagree, but sorry to burst your bubble, statistics aren't on your side.

You know why? Because on windows you don't usually rely much on system libraries, and most stuff you need is shipped by the application itself.

Same as above, all libraries are shipped by the application itself.

Yeah it's not like Wine is a huge codebase or anything and only implements a fraction of the Windows APIs. The Windows APIs are way more than most libraries people use on Linux.

Microsoft are just not morons like 99% of library developers who love changing their fucking ABIs when they could just, you know, add new functions, and keep the old ones around (even if deprecated). glibc, for example, is sane. So not all of them are idiots.

[Vistaus]

If setting a target on Windows is so easy, then how come some Win 7 apps only barely function on 10 (i.e. not all features work right)? So I guess it doesn't work that way for all apps.

[Weasel]

If setting a target on Windows is so easy, then how come some Win 7 apps only barely function on 10 (i.e. not all features work right)? So I guess it doesn't work that way for all apps.

Because the dev probably misused the API (or used hacky "protection schemes" which is basically the same thing), and the apps that fail to work on 10 compared to 7 are a tiny minority. No application that used the Windows API properly as documented will fail to work on 10, unless 10 has a bug, which is (going to be) fixed. On Linux, it's a "WON'T FIX".

My previous post was not approved yet, so here's some more food for thought: http://tirania.org/blog/archive/2012/Aug-29.html

Torvalds actually replied to this on Google Plus, but I don't know how to link the comment, so I'll link the whole post and you click on "load more comments" then CTRL+F search for Torvalds: https://plus.google.com/115250422803...ts/hMT5kW8LKJk

Here's quote for convenience:

The gnome people claiming that I set the "attitude" that causes them problems is laughable.

One of the core kernel rules has always been that we never ever break any external interfaces. That rule has been there since day one, although it's gotten much more explicit only in the last few years. The fact that we break internal interfaces that are not visible to userland is totally irrelevant, and a total red herring.

I wish the gnome people had understood the real rules inside the kernel. Like "you never break external interfaces" - and "we need to do that to improve things" is not an excuse.

Or "different users have different needs". The kernel was - and is - happy to support both the SGI style thousand-CPU machines and the embedded vendors with cellphones and routers. The fact that they have different needs is very obvious.

I personally think that one reason that the Linux kernel has been so successful was the fact that I didn't have a huge vision of where I wanted to force people to go. Sure, I wanted "unix", and there are some very high-level concepts that go with that (fork,exec,files etc), but I didn't want to enforce any particular world-view outside of that very generic pattern.

In fact, Linux pretty much did what I envisioned back in 1991 when I first released it. Pretty much all subsequent development was driven by outside ideas of what other people needed or wanted to do. Not by some internal vision of where things "should" go.

That's exactly the reverse of the gnome "we know better" mentality, and "We will force Corba/.NET down your throat whether you like it or not, and if you complain, you're against progress, and cannot handle the change".

Some gnome people seem to be in total denial about what their problem really is. They'll wildly blame everybody except themselves. This article seems to be a perfect example of that.

Really, what's the number ONE reason most people answer of why they still use Windows instead of Linux? "Because the app that I use, X, doesn't work on Linux, and I don't like your alternative Y". Whether you like it or not, these are the facts, and statistics back them up. They don't want your shitty alternative app, they want theirs, and those devs won't port it because the userland is hostile to them.

In other words, it's lack of applications. You guys are obviously not developers, so you don't understand, but even one of Microsoft's mantras is "developers, developers, developers!", can you really blame them why they're dominating the desktop?

A developer, whether he releases open source software or closed source, does not want to:

1) Recompile his finished application from 10 years ago (e.g. a game) that worked perfectly fine just because of morons who broke API or ABI.
2) If part of a company, the company's roster will keep increasing over time, and thus the amount of "re-maintaining" finished products to comply with latest API breaks is ridiculous.
3) Get nagged by customers asking for compilation for their fucking distro!!!
4) Rely on distro package maintainers to provide binaries for your app.

Just because YOU only ever envision yourself as working for one project your entire life doesn't mean others do. They finish projects and go to something else, another project, because the first one is finished.

So, even in a fully open source world, people won't want to compile everything, since the majority even amongst Linux users don't use Gentoo. Your dream of "a simple recompilation" is absolute bullshit, even if you really only had one project to compile. You'd have to recompile for every fucking distro for people who want binaries which is the majority of them.

So yes, the number one reason Linux has failed on the desktop is that it failed to attract 3rd party developers. And the number one reason it has failed to attract that, is because of the morons designing the userland libraries and their "design purity" bullshit.

If everyone followed Linus' mantra and principles, GNU/Linux would have easily become #1 OS a decade ago. Deal with it.

I will end with a paraphrased quote in respect to libraries instead of kernel APIs which is really the same thing in the end:

It is the job of the libraries to serve its users (a library's users are the applications that use it). It is not the job of an application to serve the library's moods when it decides to break API.