6 ms·

Flatpak – Standalone Apps for Linux

57 points by macco 10y ago

Nullabillity 10y ago
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 10y ago
  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 10y ago
    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.
  - Nullabillity 10y ago
    You can install Nix on any Linux system without making it control everything else.
- civodul 10y ago
  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.
- alexlarsson 10y ago
  Flatpak uses ostree, which is content-addressed, so any identical files are automatically shared.
sandGorgon 10y ago
* 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 10y ago
  Same idea, different implementation. And guess who gets yelled at for NIH-ing...
  - aroman 10y ago
    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 10y ago
      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=38 https://github.com/alexlarsson/xdg-app/commits/master?page=3... [2] https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037074.html https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/0370...
      - wmf 10y ago
        I guess Click was only for phones while Snappy for desktops was released long after xdg-app, but that's splitting hairs.
      - aroman 10y ago
aidenn0 10y ago
Does Flatpak do anything that nix doesn't do?
- macco 10y ago
  It means one package for all Linux systems, which is a huge benefit from the developer perspective.
  - takluyver 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        flatpak works with X, it will just be less secure
  - ramblenode 10y ago
    You could say this about any package manager with sufficient mindshare across distros.
  - 10y ago
jwildeboer 10y ago
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 10y ago
  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 10y ago
    Just means whoever targets those exploits also have to account for breaking out of the sandbox.
- aroman 10y ago
  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."
iamcreasy 10y ago
Does anyone know how it stack against AppImage? I know some applications(i.e. Krita) is already using AppImage.
- mixedCase 10y ago
  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-AppImages 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.
- digi_owl 10y ago
  appimage seems to be less elaborate in the security department, but appimage do not require anything preinstalled on a distro to function.
  - mixedCase 10y ago
    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.
    - digi_owl 10y ago
      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.
      - probonopd 10y ago
        bubblewrap works for sandboxing AppImages: https://github.com/probonopd/AppImageKit/issues/152 https://github.com/probonopd/AppImageKit/issues/152
jkeler 10y ago
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?
- wmf 10y ago
  The runtimes will be GNOME and KDE.
- khedoros 10y ago
  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.
- alexlarsson 10y ago
  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.
defiancedigital 10y ago
This looks like OSX distribution app. I prefer nix ...
- zxcvcxz 10y ago
  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.
SwellJoe 10y ago
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
declanqian 10y ago
What does "[dupe]" mean?

57 points by macco 10y ago

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 10y ago
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 10y ago
  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.
- Nullabillity 10y ago
  You can install Nix on any Linux system without making it control everything else.
civodul 10y ago
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.
alexlarsson 10y ago
Flatpak uses ostree, which is content-addressed, so any identical files are automatically shared.

sandGorgon 10y ago

* 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 10y ago
Same idea, different implementation. And guess who gets yelled at for NIH-ing...
- aroman 10y ago
  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 10y ago
    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=38 https://github.com/alexlarsson/xdg-app/commits/master?page=3... [2] https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037074.html https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/0370...
    - wmf 10y ago
      I guess Click was only for phones while Snappy for desktops was released long after xdg-app, but that's splitting hairs.
    - aroman 10y ago

aidenn0 10y ago

Does Flatpak do anything that nix doesn't do?

macco 10y ago
It means one package for all Linux systems, which is a huge benefit from the developer perspective.
- takluyver 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        flatpak works with X, it will just be less secure
- ramblenode 10y ago
  You could say this about any package manager with sufficient mindshare across distros.
- 10y ago

jwildeboer 10y ago

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 10y ago
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 10y ago
  Just means whoever targets those exploits also have to account for breaking out of the sandbox.
aroman 10y ago
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."

iamcreasy 10y ago

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

mixedCase 10y ago
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-AppImages 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.
digi_owl 10y ago
appimage seems to be less elaborate in the security department, but appimage do not require anything preinstalled on a distro to function.
- mixedCase 10y ago
  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.
  - digi_owl 10y ago
    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.
    - probonopd 10y ago
      bubblewrap works for sandboxing AppImages: https://github.com/probonopd/AppImageKit/issues/152 https://github.com/probonopd/AppImageKit/issues/152

jkeler 10y ago

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?

wmf 10y ago
The runtimes will be GNOME and KDE.
khedoros 10y ago
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.
alexlarsson 10y ago
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.

defiancedigital 10y ago

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

zxcvcxz 10y ago
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.

SwellJoe 10y ago

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

declanqian 10y ago

What does "[dupe]" mean?