
Flatpak – Standalone Apps for Linux - macco
http://flatpak.org
======
SwellJoe
Previous discussion of Flatpak, including some technical discussion and useful
links:

[https://news.ycombinator.com/item?id=11697678](https://news.ycombinator.com/item?id=11697678)

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

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

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

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

~~~
wmf
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. :-/

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

------
jkeler
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?

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

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

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

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

~~~
lbenes
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...](https://github.com/alexlarsson/xdg-
app/commits/master?page=38)

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

~~~
aroman
You're right, thanks for fact checking.

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

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

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

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

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

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

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

~~~
EmanueleAina
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](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=813308)

------
aidenn0
Does Flatpak do anything that nix doesn't do?

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

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

~~~
mtgx
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](https://mjg59.dreamwidth.org/42320.html)

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

~~~
alexlarsson
flatpak works with X, it will just be less secure

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

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

------
declanqian
What does "[dupe]" mean?

