5 ms·

A Quick Introduction to Flatpak

45 points by sjellis 10y ago

alex_duf 10y ago
I hope flatpack becomes the de facto standard. It seems to solve problems the right way. Between that and wayland being ready for showtime, I think the future of linux looks pretty good!
- davexunit 10y ago
  Flatpak is yet another dependency bundling tool, and dependency bundling always leads to unpatched security vulnerabilities for users.
  - curt15 10y ago
    Flatpak puts most of the common dependencies into cross-distro "runtimes". The runtime maintainers would bear the responsibility for keeping the base system patched.
    - davexunit 10y ago
      Trying to classify dependencies as "common" or "non-common" is a big design mistake. It's an insufficient solution done because flatpak can't actually capture the full dependency graph of an application. If it could, then common dependencies would be implicit (shared nodes on the graph) and no bundling of supposedly non-common components would be necessary. Examples of this problem solved correctly are Nix and GNU Guix.
      - hexxington 10y ago
        The thing about dependency bundling is it's the only way to guarantee that the app end users are running is the one your QA team tested against. Minor point releases of seemingly innocent libraries can cripple an application with no visible recourse. As an ISV, you want tight control over the end user experience, and the only way you can achieve that is vigorous QA of the exact thing your users are running, top to bottom. Banshee was badly hit by this, around the time it was under discussion as the default music player in Ubuntu - an innocent SQLite point release completely crippled the random button (30 second delays on next track, on a small library). Bundling would have avoided it, the distro model is why end users hit it. And anyone who's ever managed a Jenkins install knows minor point release updates can completely fuck the world (since so few Jenkins addins are subject to adequate CI) I'm not new to the problem at hand, I've been packaging .NET apps on Linux for a decade. But this is the reality of where we are, especially when distro maintainers (quite reasonably) only want to ship one major version of any given library at once, and you just can't make any assumptions about your base system. Bundling means you can actually ship a _product_, and train your support staff on a single configuration that everyone will experience.
        davexunit 10y ago
        >The thing about dependency bundling is it's the only way to guarantee that the app end users are running is the one your QA team tested against. No, it isn't. See how Nix and GNU Guix solve this problem without resorting to bundling. Shipping a single binary to all systems is the use-case of proprietary software. Free software just needs distros that are more capable, that can handle multiple versions of the same dependencies, like Nix and Guix do. Bundling may be convenient, but it's harmful to the users.
        hexxington 10y ago
        Guix solves literally zero of the issues I have, including anything I mentioned in my blog post. And you conveniently ignored the real world problems with trusting someone else's dependencies I gave concrete examples of in my parent comment. C'mon, I _know_ bundling has issues, but it's like writing about the comparative merits of two cars, and someone saying hippos are cool. It's a non-sequitur. Wrapping up "configure && make && make install" in some Guile doesn't make it a useful answer.
        davexunit 10y ago
        >And you conveniently ignored the real world problems with trusting someone else's dependencies I gave concrete examples of in my parent comment. You can use whatever dependencies you'd like with Nix and Guix, that's a big reason for them to exist in the first place. To attempt to translate into Flatpak terms, the "common" runtime would be whatever part of the dependency graph you share with the upstream package collection. Share as little or as much as you'd like, you know the trade-offs. >Wrapping up "configure && make && make install" in some Guile doesn't make it a useful answer. Now you're just being demeaning and dishonest. You could insult any package manager by saying it's just a wrapper around make.
        hexxington 10y ago
        > You can use whatever dependencies you'd like with Nix and Guix, that's a big reason for them to exist in the first place. To attempt to translate into Flatpak terms, the "common" runtime would be whatever part of the dependency graph you share with the upstream package collection. Share as little or as much as you'd like, you know the trade-offs. If I can't rely on _specific versions_, I have gained nothing at all vs. using .deb. API changes are a real issue. Shit really does just suddenly break. Automake 1.11.2 arbitrarily removed something relied on mostly by GUI .NET apps (and also GRUB) - how would I have been able to anticipate that if I have no control over the build system being used during app installation? Changes to default GCC flags have broken Mono's garbage collector in the past. How can I be sure changes to the underlying libraries and toolchain _not provided by me_ won't break my app's installation or use by my users? I can't. So now I'm on a distro churn wheel, but where the target distro has almost no users, no traction, no user acceptance, no institutional knowledge, and a crap first-run UX that involves mangling bashrc. Sorry, but it's just not up to scratch, and I would have scrubbed a project to use Guix within a week.
      - curt15 10y ago
        Something like the Windows API or OS X API would seem to provide a reasonable approximation of what functionality ought to belong in the runtime. These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries. The base systems in those cases are comprehensive enough that app developers generally need to worry only about functionality unique to their applications. For example, when the "gotofail" bug was discovered in the OS X crypto libraries, Apple issued an OS update that ended the story right there.
        davexunit 10y ago
        >These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries. If you run Windows, OS X, Android, or iOS it's 100% likely that you have several different versions of some C library that have known vulnerabilities in them. Think about things like proprietary games that aren't updated often, if ever, where things like libpng and stuff get bundled in. When the upstream libpng developers release a security fix, do the game developers release a new version of the game with that fix included? Almost certainly not. This is the problem with bundling. You are dependent on N upstreams for security updates to any given non-core library. It's a rampant problem, and it's a problem that GNU/Linux distributions address for the safety of their users. >For example, when the "gotofail" bug was discovered in the OS X system crypto frameworks, Apple issued an OS update that ended the story right there. Right, that is good. All of the applications were dynamically linked against the system's openssl, so the security update was easy. But only a few things are like that on these proprietary operating systems. GNU/Linux distributions, on the other hand, have this property for all software. It's absolutely crucial for user security. Asking users to install these new Flatpak/Snappy/Docker things is asking them to accept a bunch of software known to be insecure. Running vulnerable software in a container doesn't make it much better. We need to develop systems that make it easier to run software that has all of the latest security patches. Tools like Flatpak are a bold step backwards.
        cmurf 10y ago
        Users routinely do not do updates at all, let alone every other day which some distros make available. It's tedious. There's all kinds of peripheral breakage that really happens in contrast to security vulnerabilities that rarely become exploits let alone active ones. Also Flatpak does contain the extent of damage by putting the application in a sandbox - different in implementation detail but hardly different conceptually than how Apple "app store" apps likewise run sandboxed with minimal interaction between apps allowed.
    - hexxington 10y ago
      And the worst damage of the non-runtime components is mitigated via sandboxing.
  - cmurf 10y ago
    How do developers for Windows, macOS, iOS and Android build apps that support 3-4 major releases of the OS? Aren't they bundling libraries with their app? Or are they just a lot more consistent with API/ABI stability, or backward compatibility?
    - curt15 10y ago
      For one thing, the APIs of those platforms are defined by specifications and failure of an implementation to adhere to the specified behavior is a bug.
- petre 10y ago
  My problem with flatpack is that it relies on systemd.
sandGorgon 10y ago
is flatpak going to stick to its focus around desktop software only? because that was one ofnits original goals. Snap on the other hand is actually shipping docker into production.
- ealexhudson 10y ago
  Are you confusing Snaps/snappy (http://snapcraft.io/docs/core/ http://snapcraft.io/docs/core/) with https://snap-ci.com/ https://snap-ci.com/ ? Ubuntu's snappy is the obviously snap-named flatpak competitor, and it doesn't appear to me to do an awful lot with Docker?
  - tomaac 10y ago
    And to make it even more confusing there is also http://snapper.io/ http://snapper.io/
  - evand 10y ago
    Docker is available as a snap: https://www.docker.com/docker-news-and-press/docker-and-canonical-partner-cs-docker-engine-millions-ubuntu-users https://www.docker.com/docker-news-and-press/docker-and-cano...
Overtonwindow 10y ago
Did anyone else click on this thinking it had something to do with Ikea?
- jaclaz 10y ago
  Count me in. To further the shame, the apebox evoked something like sending primates from one zoo to the other ...

45 points by sjellis 10y ago

I hope flatpack becomes the de facto standard. It seems to solve problems the right way. Between that and wayland being ready for showtime, I think the future of linux looks pretty good!

davexunit 10y ago
Flatpak is yet another dependency bundling tool, and dependency bundling always leads to unpatched security vulnerabilities for users.
- curt15 10y ago
  Flatpak puts most of the common dependencies into cross-distro "runtimes". The runtime maintainers would bear the responsibility for keeping the base system patched.
  - davexunit 10y ago
    Trying to classify dependencies as "common" or "non-common" is a big design mistake. It's an insufficient solution done because flatpak can't actually capture the full dependency graph of an application. If it could, then common dependencies would be implicit (shared nodes on the graph) and no bundling of supposedly non-common components would be necessary. Examples of this problem solved correctly are Nix and GNU Guix.
    - hexxington 10y ago
      The thing about dependency bundling is it's the only way to guarantee that the app end users are running is the one your QA team tested against. Minor point releases of seemingly innocent libraries can cripple an application with no visible recourse. As an ISV, you want tight control over the end user experience, and the only way you can achieve that is vigorous QA of the exact thing your users are running, top to bottom. Banshee was badly hit by this, around the time it was under discussion as the default music player in Ubuntu - an innocent SQLite point release completely crippled the random button (30 second delays on next track, on a small library). Bundling would have avoided it, the distro model is why end users hit it. And anyone who's ever managed a Jenkins install knows minor point release updates can completely fuck the world (since so few Jenkins addins are subject to adequate CI) I'm not new to the problem at hand, I've been packaging .NET apps on Linux for a decade. But this is the reality of where we are, especially when distro maintainers (quite reasonably) only want to ship one major version of any given library at once, and you just can't make any assumptions about your base system. Bundling means you can actually ship a _product_, and train your support staff on a single configuration that everyone will experience.
      - davexunit 10y ago
        >The thing about dependency bundling is it's the only way to guarantee that the app end users are running is the one your QA team tested against. No, it isn't. See how Nix and GNU Guix solve this problem without resorting to bundling. Shipping a single binary to all systems is the use-case of proprietary software. Free software just needs distros that are more capable, that can handle multiple versions of the same dependencies, like Nix and Guix do. Bundling may be convenient, but it's harmful to the users.
        hexxington 10y ago
        Guix solves literally zero of the issues I have, including anything I mentioned in my blog post. And you conveniently ignored the real world problems with trusting someone else's dependencies I gave concrete examples of in my parent comment. C'mon, I _know_ bundling has issues, but it's like writing about the comparative merits of two cars, and someone saying hippos are cool. It's a non-sequitur. Wrapping up "configure && make && make install" in some Guile doesn't make it a useful answer.
        davexunit 10y ago
        >And you conveniently ignored the real world problems with trusting someone else's dependencies I gave concrete examples of in my parent comment. You can use whatever dependencies you'd like with Nix and Guix, that's a big reason for them to exist in the first place. To attempt to translate into Flatpak terms, the "common" runtime would be whatever part of the dependency graph you share with the upstream package collection. Share as little or as much as you'd like, you know the trade-offs. >Wrapping up "configure && make && make install" in some Guile doesn't make it a useful answer. Now you're just being demeaning and dishonest. You could insult any package manager by saying it's just a wrapper around make.
        hexxington 10y ago
        > You can use whatever dependencies you'd like with Nix and Guix, that's a big reason for them to exist in the first place. To attempt to translate into Flatpak terms, the "common" runtime would be whatever part of the dependency graph you share with the upstream package collection. Share as little or as much as you'd like, you know the trade-offs. If I can't rely on _specific versions_, I have gained nothing at all vs. using .deb. API changes are a real issue. Shit really does just suddenly break. Automake 1.11.2 arbitrarily removed something relied on mostly by GUI .NET apps (and also GRUB) - how would I have been able to anticipate that if I have no control over the build system being used during app installation? Changes to default GCC flags have broken Mono's garbage collector in the past. How can I be sure changes to the underlying libraries and toolchain _not provided by me_ won't break my app's installation or use by my users? I can't. So now I'm on a distro churn wheel, but where the target distro has almost no users, no traction, no user acceptance, no institutional knowledge, and a crap first-run UX that involves mangling bashrc. Sorry, but it's just not up to scratch, and I would have scrubbed a project to use Guix within a week.
    - curt15 10y ago
      Something like the Windows API or OS X API would seem to provide a reasonable approximation of what functionality ought to belong in the runtime. These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries. The base systems in those cases are comprehensive enough that app developers generally need to worry only about functionality unique to their applications. For example, when the "gotofail" bug was discovered in the OS X crypto libraries, Apple issued an OS update that ended the story right there.
      - davexunit 10y ago
        >These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries. If you run Windows, OS X, Android, or iOS it's 100% likely that you have several different versions of some C library that have known vulnerabilities in them. Think about things like proprietary games that aren't updated often, if ever, where things like libpng and stuff get bundled in. When the upstream libpng developers release a security fix, do the game developers release a new version of the game with that fix included? Almost certainly not. This is the problem with bundling. You are dependent on N upstreams for security updates to any given non-core library. It's a rampant problem, and it's a problem that GNU/Linux distributions address for the safety of their users. >For example, when the "gotofail" bug was discovered in the OS X system crypto frameworks, Apple issued an OS update that ended the story right there. Right, that is good. All of the applications were dynamically linked against the system's openssl, so the security update was easy. But only a few things are like that on these proprietary operating systems. GNU/Linux distributions, on the other hand, have this property for all software. It's absolutely crucial for user security. Asking users to install these new Flatpak/Snappy/Docker things is asking them to accept a bunch of software known to be insecure. Running vulnerable software in a container doesn't make it much better. We need to develop systems that make it easier to run software that has all of the latest security patches. Tools like Flatpak are a bold step backwards.
        cmurf 10y ago
        Users routinely do not do updates at all, let alone every other day which some distros make available. It's tedious. There's all kinds of peripheral breakage that really happens in contrast to security vulnerabilities that rarely become exploits let alone active ones. Also Flatpak does contain the extent of damage by putting the application in a sandbox - different in implementation detail but hardly different conceptually than how Apple "app store" apps likewise run sandboxed with minimal interaction between apps allowed.
  - hexxington 10y ago
    And the worst damage of the non-runtime components is mitigated via sandboxing.
- cmurf 10y ago
  How do developers for Windows, macOS, iOS and Android build apps that support 3-4 major releases of the OS? Aren't they bundling libraries with their app? Or are they just a lot more consistent with API/ABI stability, or backward compatibility?
  - curt15 10y ago
    For one thing, the APIs of those platforms are defined by specifications and failure of an implementation to adhere to the specified behavior is a bug.
petre 10y ago
My problem with flatpack is that it relies on systemd.

sandGorgon 10y ago

is flatpak going to stick to its focus around desktop software only? because that was one ofnits original goals. Snap on the other hand is actually shipping docker into production.

ealexhudson 10y ago
Are you confusing Snaps/snappy (http://snapcraft.io/docs/core/ http://snapcraft.io/docs/core/) with https://snap-ci.com/ https://snap-ci.com/ ? Ubuntu's snappy is the obviously snap-named flatpak competitor, and it doesn't appear to me to do an awful lot with Docker?
- tomaac 10y ago
  And to make it even more confusing there is also http://snapper.io/ http://snapper.io/
- evand 10y ago
  Docker is available as a snap: https://www.docker.com/docker-news-and-press/docker-and-canonical-partner-cs-docker-engine-millions-ubuntu-users https://www.docker.com/docker-news-and-press/docker-and-cano...

Overtonwindow 10y ago

Did anyone else click on this thinking it had something to do with Ikea?

jaclaz 10y ago
Count me in. To further the shame, the apebox evoked something like sending primates from one zoo to the other ...