28 ms·

Flatpak 1.0 Released, Ready for Prime Time

254 points by alexlarsson 8y ago

sandGorgon 8y ago
I dont know but if i just compare https://snapcraft.io/store https://snapcraft.io/store and https://flathub.org https://flathub.org ... I see that snap packages have a lot more adoption by big name vendors.
- curt15 8y ago
  One advantage of snaps for developers is that if one is already developing on Ubuntu or Debian, the build and runtime dependencies of a snap can be expressed directly in terms of the packages in the distribution's repositories. To build a flatpak requires one to hunt down the original sources and figure out how to build them like what people did before the era of package managers.
- TingPing 8y ago
  Canonical has a marketing team and outreach. Flatpak doesn't. Also the Snap store allows a larger range of software (WINE repackages, server apps, duplicates, etc) that Flathub does not. Flathub is also hand reviewed so it takes a bit longer for new apps to get in.
  - sandGorgon 8y ago
    im not talking about niche ones - im talking about REALLY big names. firefox, vscode, etc. there is also this - 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...
    - takluyver 8y ago
      vscode at least is there on Flathub: https://flathub.org/apps/details/com.visualstudio.code https://flathub.org/apps/details/com.visualstudio.code
      - gurkendoktor 8y ago
        I found the flatpak version too sandboxed to be useful: https://github.com/flathub/com.visualstudio.code/issues/25 https://github.com/flathub/com.visualstudio.code/issues/25 Snap "solves" this issue by not sandboxing some apps. I'm not sure if there is a good solution to sandboxing developer tools.
        TingPing 8y ago
        The solution is developer tools to conceptually split the target environment and their running environment. GNOME-Builder is an example of this.
        gurkendoktor 8y ago
        I was wondering how Builder handles this when I wrote my reply, but I assumed it'd do the same thing. Thanks, I'll take a look.
ddevault 8y ago
Ready to ruin the security of Linux, you mean. The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. Getting maintainers out of the loop for auditing packages, ensuring security updates go out, etc - is an awful idea. Sandboxing applications is great, but it can be done without subverting the package manager.
- matharmin 8y ago
  Package managers work well for the large proportion of software on Linux that is open-source, and has enough users to warrant the effort of packaging it separately for each distro, and doesn't require you to have the latest version (or specific older version) all the time. However, there is still a large amount of software out there for which the above does not hold. That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, as well as a whole bunch of other more manual methods of downloading and installing. It is this software that solutions like flatpack and snap are for, and it is improving both the security and usability in these cases.
  - v_lisivka 8y ago
    It improves usability only. It also creates false perception of security. Malware already found in NPM packages, AUR packages, and other packaging systems without maintainers.
    - detaro 8y ago
      Is the sandboxing in Flatpack completely useless then? Any details on this?
      - deadbunny 8y ago
        Not the person you're replying to by you're intentionally being obtuse to try and prove a point he never argued. v_lisivka never mentioned sandboxing as an issue. They were clearly talking about the fact it's a free for all user submitted repo which have a provable history of people adding malware.
mahesh_rm 8y ago
What is the position of Linus and Linux Kernel Development crew regarding this?
- dullgiulio 8y ago
  Why would they have a position that is "official"? Linux is the kernel: it provides userspace with a very stable API (which includes the sandboxing primitives used by snaps and flatpacks) but it does not mandate much in userspace.
- AnIdiotOnTheNet 8y ago
  Linus himself distributes Subsurface using AppImage.
  - feborges 8y ago
    Also available in flathub.org
blattimwind 8y ago
Interestingly flatpak doesn't really support drag-and-drop.
- alexlarsson 8y ago
  It should support it as well as deb or rpm does. I.e. it is completely uninvolved in drag-and-drop.
  - alexlarsson 8y ago
    Well, if you drag-and-drop a file things might be somewhat problematic due to the sandboxing. An app with no access to the file can't read the dropped filename.
    - takluyver 8y ago
      From a technical perspective, I understand what you mean. But from a user perspective, 'except for files' is a pretty big caveat. Files are the main thing I drag and drop!
  - deadbunny 8y ago
    They mean the apps running in flatpak, not the flatpak installer...
  - blattimwind 8y ago
    No, it really isn't. When you drag-and-drop a file from e.g. a file manager into some application, then the DnD events do not contain the file. Instead, they contain something like `text/uri-list` enumerating the file paths. If you sandbox some app, then you need a bit of software to map and translate these paths. If you do not provide such software, then your sandbox does not support DnD.
jhack 8y ago
Flatpak and Snaps are a great step forward for Linux packaging and usability. I think there's a vocal segment of the Linux community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications. Don't worry, no one's taking away your apt-get, pacman, rpm, eopkg, makefiles, etc.
- AnIdiotOnTheNet 8y ago
  Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward.
  - dec0dedab0de 8y ago
    Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward. I go back and forth on this one. On one hand I think it would make things much simpler for users who have enough storage and bandwidth. On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained. The thing is that package managers have mostly abstracted away the headaches of dependency hell, but have also raised the barrier to entry, so any software not participating seems suspect.
    - AnIdiotOnTheNet 8y ago
      > On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained. Yes, that's a drawback, but how often is there a major library that shouldn't be part of the set of libraries included as part of the base OS install? And for the ones that aren't, if the vendor chooses not to update at least you have the option of continuing to use, or not, the older version on your own terms instead of having it broken by the package manager when a dependant library is swapped out from under it. We live with this sort of thing every day in real world business and it honestly hasn't been a big deal.
v_lisivka 8y ago
In Linux, you need to download, compile, and install viruses and trojans by yourself. With Flatpack, trojans can be installed in one click.
- v_lisivka 8y ago
  OMG. I got 2 downvotes before my page with response loaded after submitting. Never saw that. :-[ ] Instant karma.
  - DoofusOfDeath 8y ago
    Jokes on HN always run a risk of downvoting, even if really funny.
    - ynniv 8y ago
      People seem particularly downvote happy this morning, or this story. Is this project close to YC?
      - nickik 8y ago
        Anything related to RedHead developers doing anything that is 'disrupting' or 'different' can unleash a shitstrom and lots of trolling.
        deleted 8y ago
        [deleted]
deadbunny 8y ago
Packaging was a solved issue in Linux, congrats on the 3 steps back. The rush towards containers because they're "easy" strikes yet again. My fear is that the handful of companies that build packages for their desktop apps with abandon them and move to Flatpak/Snap. From the Flatpak docs it looks like anyone and everyone can just get access, even if you don't own the thing you're packaging. So if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push. It's like they looked at everything bad about Chocolatey/NPM/pip/AUR and just ran with it.
- alkonaut 8y ago
  > if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push. How does this compare to the traditional package managers?
  - cpburns2009 8y ago
    Well, looking at the procedure for Snap [1] there's no review at all. Flatpak [2] defers to Flathub [3] which has some sort of review: a pull request on Github but I'm not sure how thorough that is. Traditional package repositories have a review phase before you can get your package into the system (that's how it is with Debian at least). [1]: https://docs.snapcraft.io/build-snaps/upload https://docs.snapcraft.io/build-snaps/upload [2]: http://docs.flatpak.org/en/latest/publishing.html http://docs.flatpak.org/en/latest/publishing.html [3]: https://github.com/flathub/flathub/wiki/App-Submission https://github.com/flathub/flathub/wiki/App-Submission
    - alkonaut 8y ago
      How does that review work in the case of binary/proprietary packages?
      - cpburns2009 8y ago
        I'm assuming you're talking about traditional package managers. Proprietary packages aren't uploaded to the main package repositories from what I've seen. The company will typically provide the packages themselves (e.g., a deb or rpm file), and sometimes they'll provide their own repositories for easier delivery. This has been my experience with Dropbox, SpiderOak, and Sublime Text.
privateSFacct 8y ago
They might want to take a look at snaps - it does something similar and has a good software mix.
- AnIdiotOnTheNet 8y ago
  Snaps are Canonical's NIH take on Flatpak (previously known as xdg-app). Fragmentation for fragmentations sake.
  - thibran 8y ago
    Sure it's Canonical's NIH and not Red Hat NIH, since both got released in December 2014?
    - AnIdiotOnTheNet 8y ago
      Fair enough. On the otherhand, does it really matter? The result is the same. GNUStep had Application Bundles and was developed in the 90s. ROX Filer had AppDirs and was developed in the late 90s and early aughties. Klik (now AppImage) was developed in the early aughties. There's plenty of NIH to go around on this one.
    - jhasse 8y ago
      Yes, because Snap doesn't support different repositories easily and everything atm is based on Ubuntu base-images. Also the license is GPL+CLA allowing Canonical to relicense it under a proprietary license. Furthermore they require AppArmore for some features which some distros can't use (it isn't part of the mainline kernel AFAIK).
      - jhasse 8y ago
        Okay I was wrong: AppArmor is part of the mainline Linux kernel. I think it were some Ubuntu-specific patches then which were required for some of the sandbox features. I will try to find where I read it again.
      - privateSFacct 8y ago
Aelius 8y ago
I like to run a pretty lean system, and flatpak gives me the ability to install some of the bloatier packages without the deep system dependencies they bring with them in a package manager. Installing a PDF reader should not forcibly install Udisks2 and upower. A lot of commenters are upset that maintainers are being removed from the equation. Can't each distro just set up their own maintained repository? If I understand correctly, there's nothing about flatpak that actually prevents traditional maintaining. The only thing distros have to do is integrate flatpak, set up their own repository as default, and note that user should use other repositories at their own risk. Which is basically how things already work. Is there a valid reason to hate flatpak itself, or are you all just too caught up in hating change to actually evaluate it?
- TingPing 8y ago
  > Can't each distro just set up their own maintained repository? Yes Fedora is working on doing so.
- nickik 8y ago
  A lot of criticism smells like 'RedHead systemd conspiracy' vibe.
DCKing 8y ago
The tone of the comments on news like this never fails to disappoint me. Sigh. The Snap store so vastly improves my user experience of using common apps I switched from Arch Linux (where 50% of the programs I had installed came from the AUR) to Ubuntu, where everything I needed was just there. No longer do I need to run weird scripts from the internet to get simple stuff to run on my non-standard distro (which could be Arch, Fedora, or whatever I am running at the time). You can hold the position that these things are a big security risk. Distributing monolithic packages with likely old/vulnerable dependencies is not a great idea. But on the other hand, it prevents asking the user to run random scripts (which in many cases are not vendor provided) as root to get their software, and it gives the user integrated automatic updates and other software center integration (as opposed to downloading random stuff from the internet). In terms of increased security through sheer usability and requiring less manual maintenance, the advantages of Snaps and Flatpak add up, I think. Many things in security are a tradeoff, and I feel that getting the user to do the right thing is often extremely undervalued. I think it is also undervalued in these comments. Flatpak and Snaps still have a lot of problems. Why do we have two competing standards? Why can't I properly get all Snaps running on Fedora or other platforms that use SELinux [rhetorical question - I know the technical reasons]? Why do so many apps not use their sandboxing effectively? Why is it so hard for these things to respect my computer's theme? The list goes on. The list of problems is long and valid. But I think it's worthy of some celebration that advancements are being made in making desktop Linux usable for users and popular for developers. And I don't think it's clear at all that this is a regression in terms of security.
- baybal2 8y ago
  We also have the not-so-dead autopackage (listaller)
  - DCKing 8y ago
    Yeah, but it's not just about solving the problem "how do I install package X on a random Linux distribution". I agree there have been solutions for that for a long time. In fact, Snap at least does not even fully solve this problem because its sandboxing depends on AppArmor, which clashes with SELinux on distros that use this - (e.g. anything from Red Hat). The real key to Flatpak and Snap is the entire app "experience" - integration in the software center as a trusted source, automatic updates, clean installs and removals without messing up other parts of the system. Before Flatpak and Snap, this did not exist on Linux, especially not in something that was compatible with all distros.
AdmiralAsshat 8y ago
My first impressions of Flatpak have been positive, with a few caveats. As an end-user, I want my apps to be getting regular, automatic updates, which means it's vital to get them from some kind of official repo. I sympathize with the one-man developer who just wrote some cool little Electron app that he designed to be cross-platform and promptly gets bombarded by requests from his 10% Linux userbase that wants the app to be packaged for Debian/Ubuntu/Fedora/SuSE/Arch repos. I get it, I've been that annoying guy[0]. So to that end, packaging once as a Flatpak and working everywhere has been great. A handful of those pesky apps I used to have to regularly check for new RPM releases are now on flathub and I can update them automatically. With that said, flatpak support is still spotty. DNF doesn't support flatpak yet, so I had to install GNOME Software on my Cinnamon DE just to be able to easily support and update them. There's also the issue of the greatly inflated installation sizes. I'm hopeful that support will get better soon now that it's finally at 1.0. [0]https://github.com/MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-/issues/2567 https://github.com/MarshallOfSound/Google-Play-Music-Desktop...
- deadbunny 8y ago
  > With that said, flatpak support is still spotty. DNF doesn't support flatpak yet, so I had to install GNOME Software on my Cinnamon DE just to be able to easily support and update them. There's also the issue of the greatly inflated installation sizes. I'm hopeful that support will get better soon now that it's finally at 1.0. Could you not just use the cli? (Not trying to start a holy war, just a question)
  - AdmiralAsshat 8y ago
    The CLI wasn't terribly intuitive for app discovery, and to be honest until I googled around I couldn't even find the flatpak command to update already-installed apps.
    - vetinari 8y ago
      update installed apps: "flatpak update" list whatever is available in repository: "flatpak remote-ls repo-name", i.e. "flatpak remote-ls flathub". list installed packages: "flatpak list"
dajonker 8y ago
Flatpak works much better for me on Ubuntu 18.04 with vanilla Gnome on Wayland: the Snap packages don't appear in the Gnome menu (until you launch an X session) and some Snap packages don't work at all on Wayland. Also, Spotify is updated much more often on Flatpak hub than on Snap.
sam0x17 8y ago
I would be curious to know what the differences between snap and flatpak are? Is this just a "flatpak is for RHEL, snap is for debian" situation, or is there something more to it? Just curious.
- russdpale 8y ago
  You can use them side by side. They are just different options :). If its not on snap, it could be on flathub or the other way around.
deleted 8y ago
[deleted]
cmurf 8y ago
I've been using the Slack, GIMP, and Darktable flatpaks on Fedora Workstation (which is GNOME based), available on flathub.org, for quite a while, maybe a year - without problems. I also sometimes use Okular which is a KDE app, and by installing it, the necessary kde.Platform runtime libraries were also installed and kept up to date by flatpak - works flawlessly. There's also a LibreOffice flatpak I have installed, and it seems like the flatpak update "deltas" are smaller than RPM updates, by quite a bit. I haven't used the feature yet, but supposedly there's a means of easily rolling back to a previous version in case an update has a bug the user can't work around. Rolling back RPM's can be non-trivial when there are many dependencies - it's way easier for me to do rollbacks of an RPM only based system by Btrfs snapshots which of course not everyone can depend on just for undoing an application update. So I'd say this is definitely an improvement from a user perspective; and it seems no more painful and perhaps a little less painful for packagers.
lousken 8y ago
I know snap makes it hard if I want to modify something inside the package even as root (so it's close to the UWP nightmare). Is flatpack any different?
safgasCVS 8y ago
I dont understand the point of this - why is this any better than apt? Based off the top comment here this is meant to be much more user-friendly, but already installing on Ubuntu didnt work properly despite following Flatpak's own guide. And the install process for apps is then basically the same as apt. I dont get it
- digi_owl 8y ago
  User friendliness is a smokescreen, it is about being upstream friendly. This in that now you get the kitchen sink of dependencies on each install rather than them actually having to care about API stability (not that they did much in the past). This because they do not want to admit that distros being slow with rolling out new releases of their software, is because of the dependency tangles that they have created for distro maintainers.

254 points by alexlarsson 8y ago

I dont know but if i just compare https://snapcraft.io/store https://snapcraft.io/store and https://flathub.org https://flathub.org ... I see that snap packages have a lot more adoption by big name vendors.

curt15 8y ago
One advantage of snaps for developers is that if one is already developing on Ubuntu or Debian, the build and runtime dependencies of a snap can be expressed directly in terms of the packages in the distribution's repositories. To build a flatpak requires one to hunt down the original sources and figure out how to build them like what people did before the era of package managers.
TingPing 8y ago
Canonical has a marketing team and outreach. Flatpak doesn't. Also the Snap store allows a larger range of software (WINE repackages, server apps, duplicates, etc) that Flathub does not. Flathub is also hand reviewed so it takes a bit longer for new apps to get in.
- sandGorgon 8y ago
  im not talking about niche ones - im talking about REALLY big names. firefox, vscode, etc. there is also this - 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...
  - takluyver 8y ago
    vscode at least is there on Flathub: https://flathub.org/apps/details/com.visualstudio.code https://flathub.org/apps/details/com.visualstudio.code
    - gurkendoktor 8y ago
      I found the flatpak version too sandboxed to be useful: https://github.com/flathub/com.visualstudio.code/issues/25 https://github.com/flathub/com.visualstudio.code/issues/25 Snap "solves" this issue by not sandboxing some apps. I'm not sure if there is a good solution to sandboxing developer tools.
      - TingPing 8y ago
        The solution is developer tools to conceptually split the target environment and their running environment. GNOME-Builder is an example of this.
        gurkendoktor 8y ago
        I was wondering how Builder handles this when I wrote my reply, but I assumed it'd do the same thing. Thanks, I'll take a look.

ddevault 8y ago

Ready to ruin the security of Linux, you mean. The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. Getting maintainers out of the loop for auditing packages, ensuring security updates go out, etc - is an awful idea. Sandboxing applications is great, but it can be done without subverting the package manager.

matharmin 8y ago
Package managers work well for the large proportion of software on Linux that is open-source, and has enough users to warrant the effort of packaging it separately for each distro, and doesn't require you to have the latest version (or specific older version) all the time. However, there is still a large amount of software out there for which the above does not hold. That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, as well as a whole bunch of other more manual methods of downloading and installing. It is this software that solutions like flatpack and snap are for, and it is improving both the security and usability in these cases.
- v_lisivka 8y ago
  It improves usability only. It also creates false perception of security. Malware already found in NPM packages, AUR packages, and other packaging systems without maintainers.
  - detaro 8y ago
    Is the sandboxing in Flatpack completely useless then? Any details on this?
    - deadbunny 8y ago
      Not the person you're replying to by you're intentionally being obtuse to try and prove a point he never argued. v_lisivka never mentioned sandboxing as an issue. They were clearly talking about the fact it's a free for all user submitted repo which have a provable history of people adding malware.

mahesh_rm 8y ago

What is the position of Linus and Linux Kernel Development crew regarding this?

dullgiulio 8y ago
Why would they have a position that is "official"? Linux is the kernel: it provides userspace with a very stable API (which includes the sandboxing primitives used by snaps and flatpacks) but it does not mandate much in userspace.
AnIdiotOnTheNet 8y ago
Linus himself distributes Subsurface using AppImage.
- feborges 8y ago
  Also available in flathub.org

blattimwind 8y ago

Interestingly flatpak doesn't really support drag-and-drop.

alexlarsson 8y ago
It should support it as well as deb or rpm does. I.e. it is completely uninvolved in drag-and-drop.
- alexlarsson 8y ago
  Well, if you drag-and-drop a file things might be somewhat problematic due to the sandboxing. An app with no access to the file can't read the dropped filename.
  - takluyver 8y ago
    From a technical perspective, I understand what you mean. But from a user perspective, 'except for files' is a pretty big caveat. Files are the main thing I drag and drop!
- deadbunny 8y ago
  They mean the apps running in flatpak, not the flatpak installer...
- blattimwind 8y ago
  No, it really isn't. When you drag-and-drop a file from e.g. a file manager into some application, then the DnD events do not contain the file. Instead, they contain something like `text/uri-list` enumerating the file paths. If you sandbox some app, then you need a bit of software to map and translate these paths. If you do not provide such software, then your sandbox does not support DnD.

jhack 8y ago

Flatpak and Snaps are a great step forward for Linux packaging and usability. I think there's a vocal segment of the Linux community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications. Don't worry, no one's taking away your apt-get, pacman, rpm, eopkg, makefiles, etc.

AnIdiotOnTheNet 8y ago
Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward.
- dec0dedab0de 8y ago
  Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward. I go back and forth on this one. On one hand I think it would make things much simpler for users who have enough storage and bandwidth. On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained. The thing is that package managers have mostly abstracted away the headaches of dependency hell, but have also raised the barrier to entry, so any software not participating seems suspect.
  - AnIdiotOnTheNet 8y ago
    > On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained. Yes, that's a drawback, but how often is there a major library that shouldn't be part of the set of libraries included as part of the base OS install? And for the ones that aren't, if the vendor chooses not to update at least you have the option of continuing to use, or not, the older version on your own terms instead of having it broken by the package manager when a dependant library is swapped out from under it. We live with this sort of thing every day in real world business and it honestly hasn't been a big deal.

v_lisivka 8y ago

In Linux, you need to download, compile, and install viruses and trojans by yourself. With Flatpack, trojans can be installed in one click.

v_lisivka 8y ago
OMG. I got 2 downvotes before my page with response loaded after submitting. Never saw that. :-[ ] Instant karma.
- DoofusOfDeath 8y ago
  Jokes on HN always run a risk of downvoting, even if really funny.
  - ynniv 8y ago
    People seem particularly downvote happy this morning, or this story. Is this project close to YC?
    - nickik 8y ago
      Anything related to RedHead developers doing anything that is 'disrupting' or 'different' can unleash a shitstrom and lots of trolling.
      - deleted 8y ago
        [deleted]

deadbunny 8y ago

Packaging was a solved issue in Linux, congrats on the 3 steps back. The rush towards containers because they're "easy" strikes yet again. My fear is that the handful of companies that build packages for their desktop apps with abandon them and move to Flatpak/Snap. From the Flatpak docs it looks like anyone and everyone can just get access, even if you don't own the thing you're packaging. So if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push. It's like they looked at everything bad about Chocolatey/NPM/pip/AUR and just ran with it.

alkonaut 8y ago
> if you pack $newpopularsoftware first you can now install malware on everyone's computers with a single push. How does this compare to the traditional package managers?
- cpburns2009 8y ago
  Well, looking at the procedure for Snap [1] there's no review at all. Flatpak [2] defers to Flathub [3] which has some sort of review: a pull request on Github but I'm not sure how thorough that is. Traditional package repositories have a review phase before you can get your package into the system (that's how it is with Debian at least). [1]: https://docs.snapcraft.io/build-snaps/upload https://docs.snapcraft.io/build-snaps/upload [2]: http://docs.flatpak.org/en/latest/publishing.html http://docs.flatpak.org/en/latest/publishing.html [3]: https://github.com/flathub/flathub/wiki/App-Submission https://github.com/flathub/flathub/wiki/App-Submission
  - alkonaut 8y ago
    How does that review work in the case of binary/proprietary packages?
    - cpburns2009 8y ago
      I'm assuming you're talking about traditional package managers. Proprietary packages aren't uploaded to the main package repositories from what I've seen. The company will typically provide the packages themselves (e.g., a deb or rpm file), and sometimes they'll provide their own repositories for easier delivery. This has been my experience with Dropbox, SpiderOak, and Sublime Text.

privateSFacct 8y ago

They might want to take a look at snaps - it does something similar and has a good software mix.

AnIdiotOnTheNet 8y ago
Snaps are Canonical's NIH take on Flatpak (previously known as xdg-app). Fragmentation for fragmentations sake.
- thibran 8y ago
  Sure it's Canonical's NIH and not Red Hat NIH, since both got released in December 2014?
  - AnIdiotOnTheNet 8y ago
    Fair enough. On the otherhand, does it really matter? The result is the same. GNUStep had Application Bundles and was developed in the 90s. ROX Filer had AppDirs and was developed in the late 90s and early aughties. Klik (now AppImage) was developed in the early aughties. There's plenty of NIH to go around on this one.
  - jhasse 8y ago
    Yes, because Snap doesn't support different repositories easily and everything atm is based on Ubuntu base-images. Also the license is GPL+CLA allowing Canonical to relicense it under a proprietary license. Furthermore they require AppArmore for some features which some distros can't use (it isn't part of the mainline kernel AFAIK).
    - jhasse 8y ago
      Okay I was wrong: AppArmor is part of the mainline Linux kernel. I think it were some Ubuntu-specific patches then which were required for some of the sandbox features. I will try to find where I read it again.
    - privateSFacct 8y ago

Aelius 8y ago

I like to run a pretty lean system, and flatpak gives me the ability to install some of the bloatier packages without the deep system dependencies they bring with them in a package manager. Installing a PDF reader should not forcibly install Udisks2 and upower. A lot of commenters are upset that maintainers are being removed from the equation. Can't each distro just set up their own maintained repository? If I understand correctly, there's nothing about flatpak that actually prevents traditional maintaining. The only thing distros have to do is integrate flatpak, set up their own repository as default, and note that user should use other repositories at their own risk. Which is basically how things already work. Is there a valid reason to hate flatpak itself, or are you all just too caught up in hating change to actually evaluate it?

TingPing 8y ago
> Can't each distro just set up their own maintained repository? Yes Fedora is working on doing so.
nickik 8y ago
A lot of criticism smells like 'RedHead systemd conspiracy' vibe.

DCKing 8y ago

The tone of the comments on news like this never fails to disappoint me. Sigh. The Snap store so vastly improves my user experience of using common apps I switched from Arch Linux (where 50% of the programs I had installed came from the AUR) to Ubuntu, where everything I needed was just there. No longer do I need to run weird scripts from the internet to get simple stuff to run on my non-standard distro (which could be Arch, Fedora, or whatever I am running at the time). You can hold the position that these things are a big security risk. Distributing monolithic packages with likely old/vulnerable dependencies is not a great idea. But on the other hand, it prevents asking the user to run random scripts (which in many cases are not vendor provided) as root to get their software, and it gives the user integrated automatic updates and other software center integration (as opposed to downloading random stuff from the internet). In terms of increased security through sheer usability and requiring less manual maintenance, the advantages of Snaps and Flatpak add up, I think. Many things in security are a tradeoff, and I feel that getting the user to do the right thing is often extremely undervalued. I think it is also undervalued in these comments. Flatpak and Snaps still have a lot of problems. Why do we have two competing standards? Why can't I properly get all Snaps running on Fedora or other platforms that use SELinux [rhetorical question - I know the technical reasons]? Why do so many apps not use their sandboxing effectively? Why is it so hard for these things to respect my computer's theme? The list goes on. The list of problems is long and valid. But I think it's worthy of some celebration that advancements are being made in making desktop Linux usable for users and popular for developers. And I don't think it's clear at all that this is a regression in terms of security.

baybal2 8y ago
We also have the not-so-dead autopackage (listaller)
- DCKing 8y ago
  Yeah, but it's not just about solving the problem "how do I install package X on a random Linux distribution". I agree there have been solutions for that for a long time. In fact, Snap at least does not even fully solve this problem because its sandboxing depends on AppArmor, which clashes with SELinux on distros that use this - (e.g. anything from Red Hat). The real key to Flatpak and Snap is the entire app "experience" - integration in the software center as a trusted source, automatic updates, clean installs and removals without messing up other parts of the system. Before Flatpak and Snap, this did not exist on Linux, especially not in something that was compatible with all distros.

AdmiralAsshat 8y ago

My first impressions of Flatpak have been positive, with a few caveats. As an end-user, I want my apps to be getting regular, automatic updates, which means it's vital to get them from some kind of official repo. I sympathize with the one-man developer who just wrote some cool little Electron app that he designed to be cross-platform and promptly gets bombarded by requests from his 10% Linux userbase that wants the app to be packaged for Debian/Ubuntu/Fedora/SuSE/Arch repos. I get it, I've been that annoying guy[0]. So to that end, packaging once as a Flatpak and working everywhere has been great. A handful of those pesky apps I used to have to regularly check for new RPM releases are now on flathub and I can update them automatically. With that said, flatpak support is still spotty. DNF doesn't support flatpak yet, so I had to install GNOME Software on my Cinnamon DE just to be able to easily support and update them. There's also the issue of the greatly inflated installation sizes. I'm hopeful that support will get better soon now that it's finally at 1.0. [0]https://github.com/MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-/issues/2567 https://github.com/MarshallOfSound/Google-Play-Music-Desktop...

deadbunny 8y ago
> With that said, flatpak support is still spotty. DNF doesn't support flatpak yet, so I had to install GNOME Software on my Cinnamon DE just to be able to easily support and update them. There's also the issue of the greatly inflated installation sizes. I'm hopeful that support will get better soon now that it's finally at 1.0. Could you not just use the cli? (Not trying to start a holy war, just a question)
- AdmiralAsshat 8y ago
  The CLI wasn't terribly intuitive for app discovery, and to be honest until I googled around I couldn't even find the flatpak command to update already-installed apps.
  - vetinari 8y ago
    update installed apps: "flatpak update" list whatever is available in repository: "flatpak remote-ls repo-name", i.e. "flatpak remote-ls flathub". list installed packages: "flatpak list"

dajonker 8y ago

Flatpak works much better for me on Ubuntu 18.04 with vanilla Gnome on Wayland: the Snap packages don't appear in the Gnome menu (until you launch an X session) and some Snap packages don't work at all on Wayland. Also, Spotify is updated much more often on Flatpak hub than on Snap.

sam0x17 8y ago

I would be curious to know what the differences between snap and flatpak are? Is this just a "flatpak is for RHEL, snap is for debian" situation, or is there something more to it? Just curious.

russdpale 8y ago
You can use them side by side. They are just different options :). If its not on snap, it could be on flathub or the other way around.

deleted 8y ago

[deleted]

cmurf 8y ago

I've been using the Slack, GIMP, and Darktable flatpaks on Fedora Workstation (which is GNOME based), available on flathub.org, for quite a while, maybe a year - without problems. I also sometimes use Okular which is a KDE app, and by installing it, the necessary kde.Platform runtime libraries were also installed and kept up to date by flatpak - works flawlessly. There's also a LibreOffice flatpak I have installed, and it seems like the flatpak update "deltas" are smaller than RPM updates, by quite a bit. I haven't used the feature yet, but supposedly there's a means of easily rolling back to a previous version in case an update has a bug the user can't work around. Rolling back RPM's can be non-trivial when there are many dependencies - it's way easier for me to do rollbacks of an RPM only based system by Btrfs snapshots which of course not everyone can depend on just for undoing an application update. So I'd say this is definitely an improvement from a user perspective; and it seems no more painful and perhaps a little less painful for packagers.

lousken 8y ago

I know snap makes it hard if I want to modify something inside the package even as root (so it's close to the UWP nightmare). Is flatpack any different?

safgasCVS 8y ago

I dont understand the point of this - why is this any better than apt? Based off the top comment here this is meant to be much more user-friendly, but already installing on Ubuntu didnt work properly despite following Flatpak's own guide. And the install process for apps is then basically the same as apt. I dont get it

digi_owl 8y ago
User friendliness is a smokescreen, it is about being upstream friendly. This in that now you get the kitchen sink of dependencies on each install rather than them actually having to care about API stability (not that they did much in the past). This because they do not want to admit that distros being slow with rolling out new releases of their software, is because of the dependency tangles that they have created for distro maintainers.