Flatpak – Standalone Apps for Linux | Hacker News Reader

Flatpak – Standalone Apps for Linux

flatpak.org

57 pointsmacco45 comments

Previous discussion of Flatpak, including some technical discussion and useful links:

https://news.ycombinator.com/item?id=11697678

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.

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.

Flatpak uses ostree, which is content-addressed, so any identical files are automatically shared.

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.

Doesn't it still require flatpak to be installed? I don't see how much different would it be compared to having Nix installed ontop of a distro.

You can install Nix on any Linux system without making it control everything else.

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

Fortunately it also sandboxes apps so that most of those vulnerabilities will be moot. But yeah, there's now a market for Flatpak image scanning. :-/

Just means whoever targets those exploits also have to account for breaking out of the sandbox.

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?

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.

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.

The runtimes will be GNOME and KDE.

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

Same idea, different implementation. And guess who gets yelled at for NIH-ing...

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]

[1] https://github.com/alexlarsson/xdg-app/commits/master?page=3...

[2] https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/0370...

You're right, thanks for fact checking.

I was conflating snappy and click. I've updated my original post.

I guess Click was only for phones while Snappy for desktops was released long after xdg-app, but that's splitting hairs.

Click from Canonical? I think you're confusing it with Snappy: https://en.wikipedia.org/wiki/Snappy_%28package_manager%29

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

Does anyone know how it stack against AppImage? I know some applications(i.e. Krita) is already using AppImage.

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.

AppImage seems to not be very focused on security and has no sandboxing:

https://www.reddit.com/r/linux/comments/4l20yt/ive_been_play...

appimage seems to be less elaborate in the security department, but appimage do not require anything preinstalled on a distro to function.

As far as security goes, couldn't this be solved by a separate tool, in the good ol' Unix style?

And it would be up to downstream to handle AppImage files with it for sandboxing, or not.

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.

No need to nudge, `xdg-app` for Debian has already been in the works for quite some time[1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813308

Actually the sandbox used for Flatpak can also be used to run AppImages already now:

https://github.com/probonopd/AppImageKit/issues/152

Now i wonder if the likes of Firejail works with Appimage.

As in yes, i see nothing that prevents you from applying existing sandboxing techniques around Appimage distributed software.

bubblewrap works for sandboxing AppImages:

https://github.com/probonopd/AppImageKit/issues/152

Does Flatpak do anything that nix doesn't do?

It means one package for all Linux systems, which is a huge benefit from the developer perspective.

Assuming that all Linux systems adopt it, which is far from a given. Ubuntu 16.04 already has 'snappy' packages, which seem to have similar goals.

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

https://mjg59.dreamwidth.org/42320.html

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.

flatpak works with X, it will just be less secure

You could say this about any package manager with sufficient mindshare across distros.

That applies to Nix as well.

This looks like OSX distribution app. I prefer nix ...

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.

What does "[dupe]" mean?

Reply on news.ycombinator.com