Announcement

Collapse
No announcement yet.

Canonical To Work On Improving Snap Support Across Linux Distributions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by ssokolow View Post

    What does Google's magic built-in-trackers browser have to do with anything? The Snap, Flatpak, and tarball releases are all official Mozilla builds.
    Snap firefox which is default in ubuntu is slow as hell.

    evidently none of y’all have used a browser that isn’t firefox since you don’t notice how painfully slow it is.

    Comment


    • #62
      Originally posted by sarmad View Post
      I use both Snap and Flatpak on Ubuntu (flatpaks work perfectly on Ubuntu), but I generally prefer snap over flatpak for these reasons:
      There's a lot to say about the points you mentioned:

      Originally posted by sarmad View Post
      * Snaps let you install command line apps as well.
      So does Flatpak. Try
      Code:
      flatpak install org.vim.Vim
      or
      Code:
      flatpak install org.winehq.Wine
      Flathub is more of a desktop oriented store, but there are still cli apps there. Flatpak even uses a cli app as example in their docs.

      Originally posted by sarmad View Post
      * Snaps let you install unconfined apps (necessary in some cases).
      That's a security risk, or a workaround at best, not a feature. But if necessary, Flatpak allows modifying app permissions to be more permissive, or access everything on the host.

      Originally posted by sarmad View Post
      * Snaps are more user friendly. For example, to run a snap app you just type the app's name and pass any args you want to it, just like running any regular native app, whereas with flatpak you have to use `flatpak run ...`. Another example is that it's easier to find the data for installed snap apps whereas with flatpak the data is hidden in some convoluted directory structure.
      For Flatpak you use app id, for example `org.vim.Vim`, the `flatpak run` part is redundant. granted it is less convenient than `vim` but the rationale is to avoid a random app installing itself as, say `firefox`.
      For data location, it's always under `~/.var/app`. Easily accessible, but hidden by default, like any app data in your home directory. Unlike ~/snap.

      Originally posted by sarmad View Post
      * Installing updates is much faster with snaps. Everytime you run `flatpak update` you are presented with a screen-full of updates and it takes longer to install them.
      That's objectively not true. Flatpak uses ostree for atomic updates and file deduplication, to keep update size and disk usage minimal. Snap simply downloads squashfs​ images.

      Originally posted by sarmad View Post
      * Snaps gives you more granular control over app permissions compared to flatpak (not sure if this is just a limitation of the UI in Ubuntu).
      That's again objectively not true. Flatpak permissions are manageable through cli (with `flatpak override​`) or gui with Flatseal.
      Last edited by Vermilion; 06 January 2024, 06:38 AM.

      Comment


      • #63
        Originally posted by openminded View Post
        I am kinda OK with snaps. And I'm not an Ubuntu user. My only gripe with snaps is that some vendors provide snaps exclusively, no flatpaks, and it makes me install snapd on systems where I could be better off with just flatpaks only for such stuff not present in repos. But that's a complaint that should be addressed to such apps vendors, not Canonical.
        Vice versa is not an option too, since lots of snapd apps are provided by some random person (whom I don't trust) instead of a real vendor, or such apps are outdated
        the same happens with flatpaks and images, the good thing is we can have all of them in any system

        Comment


        • #64
          so much hate, people install firefox snap and make some benchmarks comparing with deb version to see who runs faster

          Comment


          • #65
            Originally posted by andre30correia View Post
            so much hate, people install firefox snap and make some benchmarks comparing with deb version to see who runs faster
            Any app running in a sandbox is going to be slower. Several people have already done benchmarks and debs outperform every single “container” out there (including flatpaks) by a mile. It’s not even remotely close. I’m talking double digit seconds in the worst case scenarios.

            I like “sandboxing” an app into a single install location, but beyond that we’re running desktop systems. I don’t know why we need 700 layers of user space security nonsense interfering with the apps we use, slowing them down and making them way buggier.

            Comment


            • #66
              Originally posted by sarmad View Post
              I use both Snap and Flatpak on Ubuntu (flatpaks work perfectly on Ubuntu), but I generally prefer snap over flatpak for these reasons:
              * Snaps let you install command line apps as well.
              * Snaps let you install unconfined apps (necessary in some cases).
              * Snaps are more user friendly. For example, to run a snap app you just type the app's name and pass any args you want to it, just like running any regular native app, whereas with flatpak you have to use `flatpak run ...`. Another example is that it's easier to find the data for installed snap apps whereas with flatpak the data is hidden in some convoluted directory structure.
              * Installing updates is much faster with snaps. Everytime you run `flatpak update` you are presented with a screen-full of updates and it takes longer to install them.
              * Snaps gives you more granular control over app permissions compared to flatpak (not sure if this is just a limitation of the UI in Ubuntu).
              * Snaps & Flatpaks are not (or in the case of Snaps, should not be) meant to be used for command line apps. They are (or should be) meant for GUI apps. Still, nothing prevents you from installing and using CLI apps through Flatpak.
              * Flatpaks can do this too if you give an app every permission under the sun. It kind of defeats the main purpose of using Flatpak, but it's easily doable if you want to (which IMO is the perfect way to design software).
              * You don't need to use 'flatpak run', you just type the app's name like any other normal app. The only difference is that you need to use the Java/Android-style namespacing of 'org.X.Y.Z.appname' instead of simply 'appname'; which, though I understand the need for it, makes running stuff this way a minor pain in the a$$ when it comes to autocomplete. Also, what's so convoluted about /var/lib/flatpak/app and $HOME/.var/app, which both mirror the typical Linux folder hierarchy?
              * Updating Flatpaks is as fast as it needs to be (as in, fast, and usually faster than e.g. dnf or apt). Maybe you're confusing updating apps with updating runtimes, which would indeed take longer due to having to download and update a bunch more stuff, but that isn't the same with updating a single app and it isn't "everytime".
              * Flatpaks also have pretty granular control over app permissions, and you can configure an app from total lockdown to rootkit level to everything in between. I don't know exactly how granular Snaps are these days, though, so I don't know how they'd compare. What Flatpaks still miss is the ability to ask for each permission on a need-to-use basis, like Android does it, rather than requiring to set all the permissions beforehand.​

              My main problem with snaps is that it's locked to a single store which is snapcraft, rather than letting you add repos as you wish like is the case with flatpak. Canonical claims that locking it to a single store is necessary for providing better user experience or something like that, which obviously is just PR BS. Personally, I would stick with snapcraft even if they open it up to other stores, and I guess most people will do the same, but it's just the spirit of open source to keep things, well, open. Locking a package format to a single store is an anti pattern in the open source ecosystem.

              Exactly. For me and for many people using Linux, and even for many enterprises (for different reasons), as long as Snaps are tied to Canonical in a technical/physical way (as in, not only political like with Flatpaks and Red Hat) and one needs to use a closed source backend hosted on Canonical's servers to install stuff locally on their machines, Snaps are a total no go unless it's going to the trash bin. It's not only PR BS, it's blatant manhandling.

              That's why many people hate on Canonical: all they had to do was provide a way to host snaps in a local repo, and have the backend server component released and developed as open source, and nobody would be complaining (much) - in fact, they could even have had a chance at winning the race against Flatpak and Red Hat, and regaining/retaining the name they'd made for themselves as the corporate face of the Linux community back in the late '00s. But no; they chose (as they've always chosen) the way of the self-assigned "benevolent dictator", with their notorious CLA clauses and NIH mentality, their constant introducing of in-house developed competing solutions instead of contributing to community efforts and/or already established standards, their deals with Microsoft to save themselves from self-induced bankruptcy, and now the purposefully closed-source nature of the Snap Store. So, off to history's trash bin they go.

              If you ask me, both Snap and Flatpaks shouldn't have been developed. Instead, everyone should've adopted AppImages, which was invented way before both formats. So, it's funny when Flatpak fans accuse Canonical of fragmenting the ecosystem with snaps.
              AppImages and Flatpaks/Snaps are very different in nature and solve different problems, so Flatpak didn't really encroach in AppImage's territory. AppImage isn't suited for desktop app management (as in replacing package managers) but it's a very convenient format to have in order to support portable apps. Now, if only we could convince its developer to sit his a$$ down and write some code for proper Wayland support... Oh wait, unlike Snaps, AppImage is open source, so we could always add that support ourselves zz0.wp4moz24nazz

              Comment


              • #67
                I was a long time Ubuntu user. I've no interest in the politics but I had to move as browsers in snap format can't use smart card readers, which are used for government e-services in a number of countries.

                They've known about this bug for years but just can't be bothered to fix it.

                NEW (nobody) in Firefox Build System - Third Party Packaging. Last updated 2024-05-08.

                Comment


                • #68
                  Originally posted by qarium View Post

                  right now i use fedora 39... but thats realative new and only because in 2017-2018 i was not able to run any other distro on my new notebook and threadripper hardware Debian and other distros for the notebook i had at hat time added support years later.
                  before that i did use debian,kubuntu,kanotix mostly .deb based distros. so i run .rpm based distros for like 5 years and .deb based distros for like 20 years.
                  my argument is not agaist .deb based distros but why not use debian or kanotix or linux mint debian edition ?

                  just avoid anything what run snaps by default and stick with the options that run flatpak by default.

                  you should abadoning ubuntu because if you check how they make money 99% of the money they make is by microsoft payment.

                  if Pop OS use flatpak by default it should be fine to but as i know it uses ubuntu as a base instead of debian i would prever debian as a base to be honest
                  It sounds like you stick to KDE DEs too, right? The problem with using Debian - is that the software is usually older - so, for e.g., if I need Nvidia ver. 545.*, chances are, it won't even be in the sid or experimental repo? I have read some info that supposedly you can install it - but, I'd rather stick to the distro's provided packages. This situation for me, might change if I ultimately buy an amd gpu but for now, I am using Nvidia gpus - I need proprietary drivers for gaming etc.
                  Ubuntu/Kubuntu usually has decent options for newer/more recent graphics drivers so I kind of stick to the -*buntus - if I want to avoid snap - I can use Pop OS or something like that?

                  However, I am thinking of trying Fedora and Tumbleweed out - perhaps, a multi-boot of all three - Fedora/Tumbleweed/*buntu flavor (or Debian but I think it's just more work to maintain newer software) - I prefer debian as a base, actually so I agree with you - but, I'll have to see about how easy it is to use newer software - mostly the graphics stack (Nvidia) - although, I might not want the newest version (all the time) as it's common to have bugs or issues with the newest release.

                  The other problem (obviously) is I'm not familiar with the other distros as much but I guess one has to start somewhere and it's about time I tried the others?

                  Comment


                  • #69
                    Ubuntu - go away

                    Comment


                    • #70
                      Originally posted by AKoskovich View Post

                      Being centralized is a *good* thing. Most normal people do not want a billion different stores to choose their apps from. Proprietary also does not matter to the average desktop user. We have to stop caring so much about "decentralized" and "open source" if we want to actually welcome desktop users to the Linux platform. These do not mean anything to normal people.
                      No thanks, keep your walled garden.

                      Comment

                      Working...
                      X