• rtxn@lemmy.worldM
        link
        fedilink
        English
        arrow-up
        26
        arrow-down
        1
        ·
        1 year ago

        Canonical is doing the same thing Microsoft is doing with Edge - using its dominant position to push its other products and force out competition, and to lock users (and potentially developers) into its own ecosystem.

          • rtxn@lemmy.worldM
            link
            fedilink
            English
            arrow-up
            7
            ·
            1 year ago

            Saying that Edge is Chromium is like saying that Manjaro is Arch or diamond is just coal. They’re related, but there’s significant material difference.

            When it was introduced in Windows 10, Edge had an immediate and massive surge in its adoption rate. That wasn’t natural growth based on the application’s merits – it was simply a result of Edge being present in new installs.

      • grue@lemmy.world
        link
        fedilink
        English
        arrow-up
        8
        ·
        1 year ago

        and avoid needing to install all of their dependencies locally

        Wait, but doesn’t it result in more copies of the dependencies being installed locally because they’re duplicated for each application?

          • JoeyJoeJoeJr@lemmy.ml
            link
            fedilink
            arrow-up
            7
            arrow-down
            2
            ·
            1 year ago

            It’s actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.

            For example, let’s say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you’re in a predicament. You can only have one copy of L, and the versions of L may not be compatible.

            Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.

        • jj4211@lemmy.world
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          I’ll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.

          With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want ‘gnome environment, version 43’ and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it’s not too bad.

          Now there is some duplication, some libraries that an app says “oh, no particular layer for this one, fine I’ll just bundle it”. But at least there’s a mechanism to not necessarily do that for everything.

      • jj4211@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        I’ll add that the ‘pseudo-sandbox’ is of some dubious value, as far as I can tell the app declares how much or little sandboxing it wants and the user doesn’t really get the opportunity to consent or even know that a snap has full access versus limited access.

        I’ll also say that some functionality is broken in snaps (and flatpak). For example I used KeepPassXC browser integration, and then when snap was used instead of native, it broke. A number of extensions broke and the development attitude was everyone pointing fingers everywhere else and ultimately saying “just find a ppa with a browser ok?”

        I’ll second the “screw it, I give up on packaging, my app is now a monolithic flatpak, snap, appimage, or docker container” mindset of a lot of developers.

    • Ooops@kbin.social
      link
      fedilink
      arrow-up
      38
      arrow-down
      3
      ·
      edit-2
      1 year ago

      It’s a bad, slow and inefficient solution for a problem that is already solved. And because nobody would use their proprietary shit over flatpack, they force the users to use it. Even for things that exist natively in the repositories and would need neither snap nor flatpack.

      • yaaaaayPancakes@lemmy.world
        link
        fedilink
        arrow-up
        7
        arrow-down
        3
        ·
        1 year ago

        Flatpack isn’t without its own quirks and flaws. There is no One True Way. Being open-source, there shouldn’t be one.

        It is definitely slow though, mostly on first run.

        • ChunkMcHorkle@lemmy.world
          link
          fedilink
          English
          arrow-up
          8
          arrow-down
          1
          ·
          1 year ago

          Being open-source

          Yeah, that. That’s exactly the problem. To quote @Puzzle_Sluts_4Ever above, who put it much better than I could:

          . . . the main issues boil down to concerns over some parts of the Snap ecosystem being closed source, Canonical’s ongoing efforts to try to get some of the Red Hat “premium linux” money, and arguments that other solutions (e.g. flatpaks and appimages) are “just as good, if not better”. And it doesn’t help that Canonical/Ubuntu is increasingly pushing snap as “the only solution” for some applications.

          When you speak of no single One True Way and things being completely open source, Canonical/Ubuntu have already left the chat.

        • iopq@lemmy.world
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          There should be one way for sandboxed shit, since the alternative of package managers already exists

          We don’t need snap, app image, flatpak all to compete. We need shit that just works

        • nick@campfyre.nickwebster.dev
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          Gotta be honest, as a dev I tried to make a Flatpack of my app and gave up. Making a snap was much easier. Of course, I also offer it as a .deb, .rpm, Pacman package, etc. too

      • shininghero@kbin.social
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        I still don’t even know what problem snap and flatpak were intended to solve. Just apt or dnf installing from the command line, or even using the distro provided store app, has always been sufficient for me.

        • doktorseven@lemmy.world
          link
          fedilink
          arrow-up
          6
          ·
          edit-2
          1 year ago

          Modern Linux distros tend to have configuration and dependency issues where certain packages if installed the “Linux Way” doesn’t completely work as desired at times depending on the distro or even a desktop spin (which might have different default libraries installed than the “main” one). Flatpak is a single configuration meant to work one single way across all distributions and has become more of a standard, usable way for Linux applications to just work.

          Use Flatpak. Easy to install and easy to tweak from flatseal or similar GUI Flatpak permission tweakers if you want more flexibility at the possible cost of security.

        • jj4211@lemmy.world
          link
          fedilink
          arrow-up
          6
          ·
          1 year ago

          The idea is that the application may want libraries asynchronously of the distribution cadence. Worse, multiple applications may have different cadence and you want to use both (some app breaks with gnome 45 and so it needs gnome 44, and another app requires gnome 46).

          Or some pick forks of projects that neglected to change the shared object name or version, so you have two multimedia applications depending on the same exact library name and version, but expecting totally different symbols, or different ‘configure’ options to have been specified when they built the shared library.

          So we have this nifty mount namespace to make believe the ‘filesystem’ is whatever a specific application needs, and for that to be scoped to just one.

          There’s also an argument about security isolation, but I find that one to be unfulfilled as the applications basically are on the honor system with regards to how much access it requests of the system compared to a ‘normal’ application. So an application can opt into some protection so it can’t accidentally be abused, but if the application wants to deliberately misbehave it’s perfectly allowed to do so.

      • 520@kbin.social
        link
        fedilink
        arrow-up
        16
        ·
        1 year ago

        The main reason is that it is completely controlled by Canonical, with no way to add alternative repos.

          • 520@kbin.social
            link
            fedilink
            arrow-up
            6
            ·
            edit-2
            1 year ago

            You can, but that completely negates the reasons why you’d want to have a repo system in the first place. You gotta do the legwork to get updates, for example.

            • jj4211@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              1 year ago

              And to be explicit about it, zypper, dnf, apt, flatpak all have a specific mechanism to declare repositories and one ‘update’ check will walk them all.

              snap does not, and manually doing a one off is useless. AppImage also has no ‘update’ concept, but it’s a more limited use case in general, it’s a worse habit than any repository based approach.

      • Avid Amoeba@lemmy.ca
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        1 year ago

        For computer idiots it’s not bad at all. It mostly just works if you don’t mess with it and Canonical relies on it to ship software for Ubuntu. It’s one of those you should know what you’re doing situations if you’re using standard Ubuntu and messing with it. If you remove it, you will have to figure out what’s shipped via snap and how to supplant it if you want it working, among other potential headaches.

        • EvacuateSoul@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          No, it does not just work. It removes the option to install updates manually through GUI. If Firefox was running, the only GUI solution is to close it and wait 6 hours or whatever.

          My wife was perfectly fine installing updates from the tray with Synaptic. The PC is always connected to the TV with Jellyfin left open in Firefox where she was watching.

          So I switched to Manjaro to have a pretty OS that isn’t getting rid of their package manager controlling the most used program.

          • Avid Amoeba@lemmy.ca
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            1 year ago

            Ever since the fix for the “Pending update” notification, updating Firefox has been as complicated as closing it and reopening it when you see the notification. The pending update is installed immediately after closing it. It just works for my wife. ☺️

            Also I wouldn’t leave her dead without automatic updates.

            I’m glad yours enjoying Manjaro. 👌

              • Avid Amoeba@lemmy.ca
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                Yup. Actually I should have said implemented instead of fixed. The implementation was sizeable. I saw some of the PRs. From a user point of view it was a defect fix but in reality it was a non-trivial implementation. I guess that’s why it wasn’t there from the get go.

        • ChunkMcHorkle@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          1 year ago

          Those are all valid points, but there’s one more. As a person who is just coming back to Linux after 25-30 years and relearning it all from scratch, I just don’t want the hassle.

          Sure, there’s overlap between distros, Linux is Linux, and any knowledge I might glean from Ubuntu would also largely apply to any other distro – but why should I bother with investing time into a product that is already heading toward future politics and regressive policies when I can just install [NotUbuntu] and swerve the entire mess?

          There are hundreds of distros from which to choose these days, literally. Why start with one that’s already obviously moving toward the dark side? For all that I could just stay on Windows. I’m trying to get away from triple-E and paywalls and gatekeeping, not just find different ones.

          Right now I’m testing out over a dozen distros on an old laptop in my spare time, and I think the only Ubuntu related one in my list is Pop!_OS, and it’s there only because Pop!_OS doesn’t rely on snap.

          It’s one of those you should know what you’re doing situations

          And I absolutely DO NOT, so that’s that, lol. These days every brain cell counts, so damned if I’ll waste any time wading into that mess.

      • aesthelete@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        I hate it for the refresh nag messages alone.

        The default Firefox in Ubuntu is a snap and I only knew that because due to nagging and having to restart constantly while I was using it and had to learn about snaps and how to install Firefox without them on Ubuntu.

      • Ooops@kbin.social
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 year ago

        If something exists in native form, use that. If it doesn’t or you want some sandboxing (and there is at least some argument for a containerized version that brings all its needed dependencies, for developers not having to test for every linux for example) there’s flatpack or appimage. Snap is just Canonical’s proprietary alternative to flatpack. And also worse in basically any aspect. So they shove it down their users throat instead. Even for stuff that would be available natively and should just be installed via the normal package manager. And to make really sure, nobody is avoiding their crap, they also redirect commands, so for example using apt to install your browser automatically redirects your command to snap install…