Going In-Depth With Flatpak For Sandboxed Application Packaging

[andreano]

If all developers become their own packagers, I bet most of them will forget to package for aarch64. Just like docker images.

[Weasel]

If all developers become their own packagers, I bet most of them will forget to package for aarch64. Just like docker images.

If the application is open source, you can always package it yourself. I mean, you only do it once, right? Oh wait no you don't, because "lib X broke API"

...It's not like it requires "maintaining" effort and compiling it for every fucking distro version, at least if the Linux world was sane (and it isn't, the existence of flatpak proves it -- and it's not flatpak which is bad, but rather that it's even needed in the first place).

[Weasel]

Ok, last one on the API compatibility subject and Torvalds, fairly recent: https://lkml.org/lkml/2018/4/16/800

That man knows his stuff. Fully approve it.

[gens]

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.

Wow, good you bolded what I should read otherwise i couldn't even think for myself...

"Ever wondered why Windows has vastly more applications? Because it's much more friendly to developers, open source or not."
No, it's because it has more users. Especially users willing to pay money. Unix was historically much better for developers (maybe i should bold the "much"). The only advantage windows has for developers is visual studio being nice (according to Casey Muratori they are working on fucking that over as well).

"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."
The grand majority of "them" don't know how linux (or any unix, other then maybe OSX) works, because that's not where the money is.
As for the OSS "them", they should just make their program be compiled easily instead of complicating things for no good reason (hello firefox), as then anybody can package it and have a glorious title of "package maintainer".

Money makes the world go around. Give me enough money and i'l code C++ for windows, even though i dislike bout strongly (writing C++ and learning how win works, that is).

"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."
I don't, because i know how to make something portable. Steam has a decent idea, but that's not it. GOG is doing it right. Well... GOG, some things on GOG are not done right, but most are.
The super secret secret to making something you plan to sell work on all the penguins ? Don't tell anyone but you can either compile things in statically or ship your program with the libraries it needs. Why does this work ? A miracle ? No, it's because the main interfaces are stable. C library, X11 and OpenGL on it (and now vulkan, but vulkan is even better at this), and ALSA will always work. But you can go even one step above with a nice abstraction called "SDL2" (or GLFW+openal or something). And bam your program works on every linux, and even bsd-s.
For example i have an opengl program (t'was even sound in it before) and it only depends on libc, libz (it's pretty stable) and X libraries. And it does so much.. and it's not much code.. and it makes me coffe every morning...
Libraries that i noticed do make problems with portability are: C++, all of C++ ones as C++ doesn't have a stable ABI.. or at all really, and some random semi-useless things, and libpng for older programs as it changed its API a while ago (1.4 vs 1.6 i think). Libpngs new API will stick, i think as it is similar now to most other similar libraries.
So ship them with your program, problem solved. Solution to the problem is not what you say, it is just that more people should use linux/bsd and the developers will get out of the windows API/system mindset.

PS What little i seen from the windows API (thx.. Casey Muratori, thx...), it's pretty horrible. I'm guessing people use layers extensively when programming for windows.

[Weasel]

No, it's because it has more users. Especially users willing to pay money. Unix was historically much better for developers (maybe i should bold the "much"). The only advantage windows has for developers is visual studio being nice (according to Casey Muratori they are working on fucking that over as well).

It has more users because it has more applications that users want and they won't switch over to Linux because "ABC is holding me back to Windows, I promise it's the only software I'll ever need" which is different for every user.

Unix is *not* friendly to developers who want to release binaries. It's only for those who release only the source code and have people figure it out how to compile it.

Guess what? The majority of users, even on Linux, want binaries.

The grand majority of "them" don't know how linux (or any unix, other then maybe OSX) works, because that's not where the money is.
As for the OSS "them", they should just make their program be compiled easily instead of complicating things for no good reason (hello firefox), as then anybody can package it and have a glorious title of "package maintainer".

But Firefox is not at all hard to compile? (yes, I've done it many times)

Besides, the only reason it's so "convoluted" to compile stuff on Linux is because of this: the absolute dipshit unstability of the userland.

Do you know people on Windows tend to compile programs sometimes fully in assembly language? Talk about "easy" if you can even do that in asm.

They actually do it on Linux too, but they use only kernel APIs, which are stable

I don't, because i know how to make something portable. Steam has a decent idea, but that's not it. GOG is doing it right. Well... GOG, some things on GOG are not done right, but most are.
The super secret secret to making something you plan to sell work on all the penguins ? Don't tell anyone but you can either compile things in statically or ship your program with the libraries it needs. Why does this work ? A miracle ? No, it's because the main interfaces are stable. C library, X11 and OpenGL on it (and now vulkan, but vulkan is even better at this) and ALSA will always work. But you can go even one step above with a nice abstraction called "SDL2" (or GLFW+openal or something). And bam your program works on every linux, and even bsd-s.
For example i have an opengl program (t'was even sound in it before) and it only depends on libc, libz (it's pretty stable) and X libraries. And it does so much.. and it's not much code.. and it makes me coffe every morning...
Libraries that i noticed do make problems with portability are: C++, all of C++ ones as C++ doesn't have a stable ABI.. or at all really, and some random semi-useless things, and libpng for older programs as it changed its API a while ago (1.4 vs 1.6 i think). Libpngs new API will stick, i think as it is similar now to most other similar libraries.
So ship them with your program, problem solved. Solution to the problem is not what you say, it is just that more people should use linux/bsd and the developers will get out of the windows API/system mindset.

You can't make something truly portable for Linux unless you only depend on sane libraries like glibc and link everything else statically. This is not a good thing, this just shows how poor shit the libraries actually are, if you have to resort to statically linking them. I used to think like you that simply bundling libraries and dependencies was all it took for something to be portable. But it's not enough, that's why flatpak exists.

For example if an app uses libfoobar version 1, which depends on libblah version 2, while libblah version 2 itself depends on libfoobar version 2, you will get a mess of symbol conflicts, since the lib dev retards in their supreme idiocy decide to use the same function names for libfoobar version 2. (and yes, Linux shared objects are much worse than Windows DLLs, symbols are not imported by module, but only by name, that's why LD_PRELOAD hacks work). Same with sockets and other services (systemd?) that apps might require. You simply can't do it without a sandbox.

"SDL2" is not a "nice abstraction" because it's already incompatible with SDL1. How is this not obvious? A "nice abstraction" will work forever as long as Linux exists and even more than that (if someone writes a Linux compatibility layer, like Microsoft with WSL, then even if Linux dies, you can *still* run apps on Linux on Windows). A "nice abstraction layer" must never break API or ABI.

C++ doesn't have a stable ABI, but Microsoft solved that ages ago, because they care about stable ABIs and compatibility. COM is designed around C++ "interfaces". The idea is to use pure virtual classes that only hold virtual member functions (so, only a vtable with function pointers). A lot of Windows APIs rely on COM, so it's extremely stable. Heck, even the dreaded DirectX uses COM interfaces.

PS What little i seen from the windows API (thx.. Casey Muratori, thx...), it's pretty horrible. I'm guessing people use layers extensively when programming for windows.

It's mostly horrible, yes, but it doesn't matter because it's like the Linux kernel. Almost nobody codes directly for the syscalls. However, all the "layers" are usually statically linked, so there will never be a dependency hell problem with "API break". And those layers are really thin in most cases (or do boilerplate you'd do anyway).

[Ananace]

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.

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.

[euler271]

But Firefox is not at all hard to compile? (yes, I've done it many times)

Really? we're talking about the latest firefox versions right? the ones with the rust/cargo installation crap. 'not at all hard' wouldnt be the first description coming to mind.

[Flaburgan]

Weasel suuuure! Let's just all embed every libs we need to never break old compatibility. But oh wait! There is a flaw in openssl! And one in libxml! That's fine, we just have to wait that every single devs update every apps we use! And this is how you have an OS as breakable as Windows.

Oh btw, you also as to count all the disk space wasted. All libraries duplicated for every. Single.app. Installed.

[starshipeleven]

Obviously it is. Numbers speak for themselves.

Exactly, and linux is only following suit on what is done hackishly on windows (just dumping all libraries ytou need in the application folder), and MacOS (making the same thing but with some more bling). Also Android, or iOS.

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.

ahahahahahahahahahahahahahahahahahahahahahaha yeah right and I'm out of a job.
The thing you are missing here is that Linux distros bundle a ton of libraries as part of the distro. Windows does not. You don't have libffmpeg by default in windows.

One of the main reasons VLC player got so much userbase on Windows even if it's user interface is crap is that it also carried all its libraries and codecs and everything, for example.

That's why 3rd party developers love coding for Windows and not Linux.

It's just marketshare. Even MacOS at like 3% marketshare has more third party software developers than Linux desktop (which isn't a single thing but many distros joined together in that statistic), and that is a fact.

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.

I'm wondering what makes you think that all breakage comes from library authors breaking retrocompatibility by choice.

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

There are also angry kids calling userspace developers dipshits, because they have no fucking idea of how software development works and how linux distros work.

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.

Lol we have a badass over here. Guess what? that's not the main issue.
Sometimes you do have to break retrocompatibility for safety reasons (maybe a function call would allow someone to exploit your library and you cannot sanitize it, and have to just drop the old one, this is more common than you think in libs used by ssh, vpns and so on).
Sometimes it's the compilers that wreak havoc, sometimes it's just bugs introduced in functions you work on that trigger only in some programs but not in your in-house testing, sometimes the language itself changes and some features are deprecated and you can't use the old function calls anymore.
Sometimes you just deprecate functions because they are old code you can't face-lift that more than you already did, and you don't want to spend any more of your precious time debugging them or fixing them again and again. Note that all time spent on old legacy crap is time NOT spent on what is actually used, or bugs, or the future developments of the library.

Then you may have also stupidity, but seriously, even thinking that everyone else is so much more stupid only shows you have no idea of what you're talking about. Which isn't really surprising to me.

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.

Yeah, there aren't many software companies and independent developers selling licenses to use their library.

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.

glibc (like also the kernel) is doing pretty low-level stuff. It's not dealing with the complexity that software running in userspace is dealing with.

I mean, if a software needs some specialised function calls a library, which for the dumb blocks of its function makes calls to the libc, that then makes calls to the kernel. Complexity of the function calls decrease by going in this direction ---->

Meanwhile, the kernel itself has an unstable ABI towards drivers, why? because of the same reasons libraries in userspace can't be 100% static and retrocompatible forever.

It's a highly complex interface, and while they don't break ABI on a whim, they don't want to be bogged down with useless legacy, nor keep unsafe stuff.

For libraries in userspace there is more push towards stability than in the kernel (where being so dynamic is one of the selling points), but that's still the same general concept.

[Candy]

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

The person you are referencing to, is one of the cause of the fragmentation we have now. He couldn't get along with the KDE people and started off creating GNOME.