I'm not at all sold on this idea of "platform" vs "application" that seems to have become so common. I'd much rather have a Nix-like system, where you still get the isolation benefits (each package specifies an exact dependency hierarchy), while also opportunistically sharing stuff that is identical between packages.
You can put a single file on a system otherwise not configured with nix (however nice it is). So it's much more universal, and much easier to make inroads into already established infrastructure without having to disrupt it, or even care much about it.
Agreed. GNU Guix makes it easy for anyone to publish a bunch of package recipes for their own software that users just need to add to their GUIX_PACKAGE_PATH.
The benefit is that it integrates with the rest of the system and thus shares software updates, storage space, and gets overall features such as isolated builds and transactional upgrades and rollback.
* Is Flatpak the same as xdg-app?
Yes, while xdg-app was a fine name to use during development we wanted something with wider appeal and more sparkle to it than xdg-app could provide. So as part of formally launching Flatpak as ready for use we decided to pick a more accessible and fun name.*
Interesting - I wonder how it compares with Click packages.
Update: never mind. I was mistaken about the timeline, click definitely predates xdg-app.
If you're implying that Canonical shouldn't be blamed for creating Click as an NIH solution because they released it first, I'd disagree. xdg-app has been a thing for way longer than click.
xdg-app was open, the architecture were documented, and Canonical probably could have worked with it if they cared to. Same with Wayland and Mir.
Do you have a source for that? From my investigation, this does not seem to be true. xdg-app's initial release was Dec 17, 2014. [1] While click seems to go back to 2013[2]
If they have Gnome 3.20+, it should work on them. Unlike Snappy, flatpaks require Wayland, which means they won't have the security issues that snappy apps will (with X11):
So if you're using Wayland, they're equally secure, and if you're using X, you can use snappy but not flatpak? That doesn't seem like a great point for adoption of flatpak.
Embedded libraries that never get updated. That may expose security vulnerabilities. Different apps including those different versions of libraries. No. That's not progress. That's ridiculous.
I believe you're massively overstating the problem.
Not all of the libraries you use are embedded. Only the ones you need that aren't part of the platform you're targeting are.
For example, if you're building an app on the GNOME 3.28 platform, it would presumably include (for example) an SSL library like OpenSSL. Now, whenever the platform is updated (3.28.x), all of the apps that target that platform (presumably all of them) will get the updated OpenSSL for free.
And if an application really needs a specific version of OpenSSL, then at least you know it's sandboxed, which is much more than you'd get on almost any desktop Linux distro today.
From the website:
"Dependencies that aren't in a runtime can be bundled as part of the app. This makes it possible to use dependencies that aren't in a distribution, and to use a different version of a dependency than the one that's in a distribution."
It seems easier to use AppImage applications (as Flatpak requires its binary to be installed and works like a sort of package manager) and it looks easier to create FlatPak apps (create file, point to specific runtime dependencies, create package) than to create AppImage apps (https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm...).
This inclines me towards AppImage, as the whole point is to have the easiest experience for the user.
The whole point of flatpak is to standardize better security cross-platforms. Allowing "some other tool" to do that for you, just means most apps and most users will not take advantage of that security.
Why do we need to standardize sandboxing if that means having to install an application to install applications that are supposed to not need external dependency handling?
If Flatpak's main selling point is security, then it would be better served as as a sandboxing tool for AppImage rather than falling for NIH syndroming as is unfortunately too common in Red Hat's world.
Because as the old name indicated, xdg-app is/was a Freedesktop project (though much of the docs are at Gnome, making one ponder porous project boundaries). And Freedesktop is all about defining that one canonical (heh) distro (making "free" something of a misnomer at best).
Observe flatpak becoming part of Fedora shortly, and then Poettering style "nudging" implemented to get Debian and the rest to adopt it.
While I like idea I don't completely understand it. What 'runtime' is actually supposed to be? What if I need two runtimes? I will probably need to bundle one of them with the app. E.g. if I write a C++ Qt application I will use Qt runtime, if I write command line Python application I will use Python runtime, but if I write Qt application in Python I will need to bundle either Python or Qt with my app, correct?
Also, is there support for applications without any runtime?
It looks like there would be shared "runtime" packages, in specific versions, installed as part of the flatpak system (that is, not included in the app bundles themselves). Different runtimes could be installed, specific versions would be supported, etc.
The app itself would include any libraries/prerequisites outside of whatever flatpak defines as a "runtime library".
At least, that's my reading of how Flatpak works. I could be wrong on some of those points.
Runtimes are not package dependencies. They are not separated from the app to allow dependency resolution. They are separated out in order to allow a different entity to maintain and update them. The idea is that they are pretty minimal (to some degree) and come with a well defined ABI and stability/lifetime guarantee.
If, above this, you need more dependencies, in the flatpak model you need to bundle them yourself. Such bundling can be done however you want. For instance you can reuse existing packages from some distro, you can build the yourselves, or whatever.
Technically you have to specify a runtime, or things will not run. But if you want you can create your own runtime that is empty and use that. This means you have to supply everything though, as you won't even have an ld.so.
I prefer doing things the way we're already doing them. Linux package management is already better than pretty much every other main stream OS. But that's the good thing about Linux is there is so much choice. I can choose to use state of the art package management or really shitty package management. On some systems you only get to use shitty package management.
45 comments
[ 3.1 ms ] story [ 94.3 ms ] threadThe benefit is that it integrates with the rest of the system and thus shares software updates, storage space, and gets overall features such as isolated builds and transactional upgrades and rollback.
Interesting - I wonder how it compares with Click packages.
If you're implying that Canonical shouldn't be blamed for creating Click as an NIH solution because they released it first, I'd disagree. xdg-app has been a thing for way longer than click.
xdg-app was open, the architecture were documented, and Canonical probably could have worked with it if they cared to. Same with Wayland and Mir.
[1] https://github.com/alexlarsson/xdg-app/commits/master?page=3...
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/0370...
I was conflating snappy and click. I've updated my original post.
Where can I find who wrote Click in the first place? The only reference to wikipedia seems to be about klik, not Click: https://en.wikipedia.org/wiki/AppImage_%28packaging_method%2...
https://mjg59.dreamwidth.org/42320.html
Not all of the libraries you use are embedded. Only the ones you need that aren't part of the platform you're targeting are.
For example, if you're building an app on the GNOME 3.28 platform, it would presumably include (for example) an SSL library like OpenSSL. Now, whenever the platform is updated (3.28.x), all of the apps that target that platform (presumably all of them) will get the updated OpenSSL for free.
And if an application really needs a specific version of OpenSSL, then at least you know it's sandboxed, which is much more than you'd get on almost any desktop Linux distro today.
From the website:
"Dependencies that aren't in a runtime can be bundled as part of the app. This makes it possible to use dependencies that aren't in a distribution, and to use a different version of a dependency than the one that's in a distribution."
This inclines me towards AppImage, as the whole point is to have the easiest experience for the user.
And it would be up to downstream to handle AppImage files with it for sandboxing, or not.
As in yes, i see nothing that prevents you from applying existing sandboxing techniques around Appimage distributed software.
https://github.com/probonopd/AppImageKit/issues/152
If Flatpak's main selling point is security, then it would be better served as as a sandboxing tool for AppImage rather than falling for NIH syndroming as is unfortunately too common in Red Hat's world.
Observe flatpak becoming part of Fedora shortly, and then Poettering style "nudging" implemented to get Debian and the rest to adopt it.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813308
https://github.com/probonopd/AppImageKit/issues/152
https://www.reddit.com/r/linux/comments/4l20yt/ive_been_play...
Also, is there support for applications without any runtime?
The app itself would include any libraries/prerequisites outside of whatever flatpak defines as a "runtime library".
At least, that's my reading of how Flatpak works. I could be wrong on some of those points.
If, above this, you need more dependencies, in the flatpak model you need to bundle them yourself. Such bundling can be done however you want. For instance you can reuse existing packages from some distro, you can build the yourselves, or whatever.
Technically you have to specify a runtime, or things will not run. But if you want you can create your own runtime that is empty and use that. This means you have to supply everything though, as you won't even have an ld.so.
https://news.ycombinator.com/item?id=11697678