No announcement yet.

The State Of Flatpak vs. Snaps On Various Linux Distributions

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by ikey_solus View Post
    **grabs popcorn**
    Now don't go feeding the troll with that popcorn Ikey. I already fed it enough.
    Last edited by NihilMomentum; 02-10-2017, 03:11 PM.


    • #32
      Originally posted by cen1 View Post
      Does anybody really care about flatpak and snaps? To me it seems like yet another linux holy war that is reinventing the wheel and not contributing much to the ecosystem. Tell me ONE advatnage over rpm/apt.
      I can see the benefit for games on GNU/Linux as the developer can make sure to have the most up to date or specific library that the OS may not have.


      • #33
        Originally posted by jKicker View Post
        Have you ever wanted to make a release of your application for Linux in general and have it updated? Well that's where they come in. For OSX, Windows, iOS, Android etc you just build and distribute your app. For linux you need to create multiple packages for multiple distributions so you spend more time on building your app than developing. Unless you are popular enough so that distribution packagers do it themselves. And then you still can't update that.
        so it's all about updating? apart that, can you tell me the difference from a functioning shell installer? (see as an example)


        • #34
          Originally posted by bug77 View Post
          Another weird thins we do when our distro of choice doesn't package X or Y (brace for shock #2), we use tarballs!
          Actually, ever since I tried to make use of OBS, I have never used a tarball, not once. Because it's literally easier to create an RPM package on OBS than to install things compiled from source.


          • #35
            Originally posted by tegs View Post
            I can see the benefit for games on GNU/Linux as the developer can make sure to have the most up to date or specific library that the OS may not have.
            I can see the opposite. The problem is generally not a newer library that a game needs, but rather a newer library the OS provides that the old tech in the game isn't capable of dealing with.

            The solution, of course, is to drop a .so file of the older library or a drop-in replacement into the game's directory. That's how you can get games like Heroes of Might and Magic III and Unreal Tournament series working again.

            If they were statically compiled? Wouldn't run, period.


            • #36
              Originally posted by debianxfce View Post

              Why use such small distribution as Solus where are very few apps compared to Debian testing Xfce that is a rolling release os too and way more popular, stable, faster (according to distrowatch Solus uses 800MB ram after boot when Debian testing Xfce uses 200MB), easier to use and more compatible with other distributions.
              What? 800MB? I've been using Solus with Budgie for some time now and after boot it uses about 300-350 MB. I didn't even do any tweaking (except for bumping up the MTU, but that's network tweaking so that doesn't count). Also, the amount of apps is growing every day. You can check their Git page is to see for yourself.
              Last edited by Vistaus; 02-11-2017, 07:11 AM.


              • #37
                Ignoring all this political stuff and focusing on the technical approach to fix the issue, I still prefer the snaps packages. Im still not a fan of the runtime approach. At the end of the day, both will continue being used, and support on most of the distros will continue being improved, so its more choice for the developers than want to make a package for linux.


                • #38
                  Just tried Krita that comes with appimage. Works great like on mac.


                  • #39
                    Originally posted by ermo View Post

                    With rpm/apt, you approach the entire repo as one dependency graph. With e.g. flatpak, you confine your dependency tree to independent runtimes that can be updated asynchronously from the base OS rpm/apt dependency graphs.

                    What this means is that you might not need to update the user-facing flatpaks, but only the base OS rpm/apt dependency graphs and the flatpak runtime that links into the base OS (and you can update the flatpak runtime without affecting the base OS dependency graph).

                    This is a very big deal for ISVs, because it cuts down on their test and support surface, which will potentially lead to more ISVs offering their software for Linux. As an ISV, you could target the hypothetical XYS webdev stack v2.2x or later or the GNOME 3.2x stack or later for you app instead of having to distrubute eleventeen different .rpm/.deb/.ebuild/.tar.xz/.whatever versions for different distros and versions.

                    At least, that's my current understanding of the benefits of flatpaks.
                    I guess it depends on how good the sandbox is whther this is a good idea or not. If the sandbox is insecure it is actually a terrible idea. I highly suspect that flatpacks on desktop oriented distro's will be insecure and actually will help malware become a legitimate problem on linux for the first time ever.

                    EDIT: I guess the flip side to that is that flatpack based stores become possible, which would be awesome. In my opinion at least I think it could allow for greater distribution diversity, but in exactly the same way it could allow for more malware.
                    Last edited by duby229; 02-12-2017, 11:04 AM.


                    • #40
                      Originally posted by TheBlackCat View Post

                      Based on the summary quoted in the OP anyone who supports snap also supports flatkpack, so we really don't.
                      that was a joke and it doesn't work vice versa, ergo..