What use to be the PPA that allowed Ubuntu users to use native .deb packages for Firefox has recently changed to the same meta package that forces installation of Snap and the Firefox snap package.

I am having to remove the meta package, then re-uninstall the snap firefox, then re-uninstall Snap, then install pin the latest build I could get (firefox_116.0.3+build2-0ubuntu0.22.04.1~mt1_arm64.deb) to keep the native firefox build.

I’m so done with Ubuntu.

  • @Dagamant@lemmy.world
    25•2 years ago

    I stopped using Ubuntu because of snap a while ago. I tend to run Linux on older machines and flat packs tend to take much longer to load than native apps. I get that they have their purpose but I would prefer to choose to use rather than be forced. I’m currently trying out POP_OS! and it’s a welcome flavor of Ubuntu

    • @sounddrill@lemmy.antemeridiem.xyzEnglish
      9•2 years ago

      They forget this

      Most normies using linux distros use it because they don’t have 16gb of ram and a massive ssd

      Now the most mainstream linux distro does a lil trolling

  • hitagi
    6•2 years ago

    The last time I had to deal with Firefox-Snap on a fresh Ubuntu install, it kept crashing on launch. Grabbed a tarball and that justworks ™. That was around a year ago. Hopefully the situation has gotten better.

  • Lvxferre
    76•2 years ago

    You know what, enough is enough. Snaps run like shit in my system (IDK/DC why), I hate companies forcing their shit down my throat, and I was planning a clean reinstall anyway from Ubuntu 20.04 to 22.04. Might as well use the opportunity to go back to Debian. Or Mint. Or Mint Debian Edition. Who knows.

    Next on the news, Ubuntu (“humanity”) gets renamed to Amasimba (“shit”). /s

    • @cloudy1999@sh.itjust.works
      4•2 years ago

      After using it since Lucid Lynx 10.04, I switched from Ubuntu to Mint last weekend. I’m lazy about distros these days, and I really didn’t want to switch, but Firefox instability was driving me nuts. The web browser must be reliable, IMO. It’s a fundamental requirement for a desktop OS, and this problem didn’t exist before snaps.

      • RaivoKulli
        2•2 years ago

        Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.

        no

      • SALTEnglish
        14•2 years ago

        TempleOS and give it a try. The prophet Terry will be smilling from the Heaven TempleOS

      • Lvxferre
        3•2 years ago

        I toyed with the idea of gentoo. Not because I want a rolling distro, but because of that 4chan meme.

        • @msage@programming.dev
          2•2 years ago

          Gentoo is very good actually, specially if you have a modern CPU.

          I tried it on my desktop, and I never want anything else.

  • @Linuturk@lemmy.onitato.com
    27•2 years ago

    I like the approach Pop OS takes. Their software store lets you choose between deb or flatpak when you install software. I’ve had issues with flatpak versions of some software, and flipping to the deb package usually fixes it.

    • VoltaicGRiD
      9•2 years ago

      @Linuturk @PseudoSpock My problem here is that I don’t understand the purpose of flatpak when Deb seems to have everything from my experience, but I’d love to be proven wrong.

      • Solar BearEnglish
        27•2 years ago
        1. Flatpaks are usually fresher than point release distro packages
        2. Flatpaks are distro-agnostic
        3. Flatpaks are easily containerized for increased security and privacy
        4. Flatpaks can guarantee you have a known-good dependency chain directly tested by the developers/maintainers themselves
        5. Flatpaks can be installed and managed entirely in userspace
        • The Ramen Dutchman
          1•2 years ago
          1. Some software is on the Flathub instead of on Debian’s repos, so sometimes the choice is between Flatpak, AppImage and Snap.
        • SALTEnglish
          6•2 years ago

          and better than snaps in experience…

        • VoltaicGRiD
          5•2 years ago

          @bear
          Thank you for the very clean and clear explanation. I’ll have to give them another chance.

        • qyron
          5•2 years ago

          All of that is good but you are overlooking the small detail that installing flatpack implies using up a lot more disk space than just pulling a distro package.

          I can point one specific example with libre office: 3.9GB for the pack vs 785MB for the .deb.

          We can argue disk space nowadays is cheap but overloading a machine with duplicated packages also goes against the main goal of running a Linux.

          When I first started using it, one of the talking points was that Linux kept the system clean of clutter and that improved longevity for the hardware and delivered stability by not having unnecessary and unused or orphaned and redundant libraries and dependencies.

          With flatpacks we get the latest and greatest - I’m a debian fan and I hurt for not getting more up to date software - but we are carting in a ton of junk that should not be necessary.

          And the container/sandbox part is not that great, apparently. Debian wiki links to this to further educate/alert on the down sides of flatpacks. Debian is not the ultimate bearer of truth but they do move a lot of respect.

          • @TeryVeneno@lemmy.ml
            6•2 years ago

            The 3.9GB is not just libreoffice, that number also includes runtimes. At most you would only install maybe around half of your host systems’s packages in runtimes for all the apps you use. There shouldn’t be any more usage than that. And even less if you stick to apps that fit your DE. Like if I just stuck to apps that used the gnome runtimes, I would have a pretty minimal installation.

            Unfortunately, the dependency problem is really hard to solve, and at least they deduplicate what they can. Everything else works perfectly as well besides some minor issues with the sandbox connecting to the host system in certain edge cases.

            Also please don’t link flatkill, it’s woefully outdated and every point on there has been addressed for years; it should be taken down.

          • Solar BearEnglish
            3•2 years ago

            I can point one specific example with libre office: 3.9GB for the pack vs 785MB for the .deb.

            You already have most of the major dependencies installed natively as they are depended on for many other packages, and you’re not including the space they take up as part of installing the native package, but you are including them as part of the flatpak.

            When I first started using it, one of the talking points was that Linux kept the system clean of clutter and that improved longevity for the hardware and delivered stability by not having unnecessary and unused or orphaned and redundant libraries and dependencies.

            Flatpaks literally improve this. The core system itself remains extremely minimal and lean when you use containers, in both the server and desktop space. This greatly improves stability and longevity. We all know how much of a pain it is to do a point release upgrade on a system with tons of installed software. Flatpaks do not have this problem because they are independent of the system and each other.

            but we are carting in a ton of junk that should not be necessary

            It is necessary, and it’s not junk.

            Debian wiki links to this to further educate/alert on the down sides of flatpacks.

            Much like Debian packages, the Debian wiki is stale and outdated.

            • qyron
              1•2 years ago

              I’m learning as I go. Having imput on my talking points is always a good thing.

              I remember dipping my feet into the Linux pool, through Debian, searching online for a given tool/program, just to get disappointed as I wouldn’t have it or the version available from the repositories was extremely outdated or some library required to run it would be as well.

              And back then I remember thinking it would be great to have some way to get access to more recent software versions with all the necessary dependencies to run it from a realiable source.

              But one thing I always thought should be obligatory was that during installation of such programs, only the resources absent from the system would be added to the installation/system and any other resource bundled would be automatically discarded, thus saving disk space and avoiding redundant libraries present on the system.

              Do flatpaks have such working structure?

              I am not a programmer of any sort and up until now, everything single information I’ve read states these sources throw every necessary resource it require for running into the system storage, regardless if some/all are already available per the system or other programs.

              For me, this implies if I run 12 different programs that share, let’s say 2 libraries, for the sake of this conversation, and such libraries already exist in the base system, by using flatpaks to install each program I’ll be adding 24 redundant files to my hard drive.

              For someone that usually runs entry level hardware, as I do, the storage getting full(er) translates into an heavier, sluggish system. Not to mention that only this year, I’ll be finnally running a machine with more than 500GB of storage. Storage space is a concern for me.

              When I read on my distro “app store” that installing Libre Office from a flatpak would require 3.9GB after installed versus less than 1/4 of that if opting for the repo pack, the math wasn’t hard to make.

              Where am I missing here? What am I failling to understand regarding flatpacks?

              Easier system maintenance is a plus, per your words. I’m sold on that point.

              • Solar BearEnglish
                1•2 years ago

                But one thing I always thought should be obligatory was that during installation of such programs, only the resources absent from the system would be added to the installation/system and any other resource bundled would be automatically discarded, thus saving disk space and avoiding redundant libraries present on the system.

                Do flatpaks have such working structure?

                It’s possible, but rarely allowed because that would produce instability. Linux programs are built to rely on a specific version of a library. Depending on how much actually changes, you can sometimes get away with using a different version than the one it expects, but the more it changes the riskier it gets.

                One of the major goals of flatpaks was to create a way for developers to ship one build that was guaranteed to run the same regardless of distro or environment. The isolation is very much the point. It does use more storage space, but in most cases it’s not enough to matter. When storage space is at a premium, yeah, you generally want to avoid containers. They trade space for stability.

                Pretty much everything in the Linux space is converging on this concept. Desktop is moving to immutability with flatpak apps. The server space has been entirely taken over by containers. Even Valve has shipped a separate Linux runtime for as long as they’ve officially supported it, and they’re progressing on deeper containerization. You can direct it to run against your native packages instead of the runtime, but it’s rarely a good idea.

                The point is that it gives developers a single target that they can all rely on, instead of having to account for 20 distros with multiple still-supported versions each. And believe me, these efforts have made Linux so much easier as a user as well. It used to be that lots developers only targeted Ubuntu. Trying to get anything to run on another system was off like pulling teeth. Now, you can almost always expect to find a flatpak instead which runs on any distro.

                • qyron
                  1•2 years ago

                  You mind if I poke the subject for a little more? It is opening a new understanding for me.

                  Please keep in mind I’m not a programmer, to any degree.

                  As per what you are explaining, flatpaks working remembers me of a flower blooming on a tree: it uses resources provided by it, adds functions to it but doesn’t alter it in a significant fashion.

                  But again on the space saving and version controlling.

                  Let’s take a given flatpak, where 50 libraries are shipped with it to ensure it works properly, on any given distro.

                  As you already said, library versions between distros can vary wildly but would it be that difficult to have a script running pre installation (I think “connection” is more adequate to describe the process at this point) to check for what already available required resources exist on the system to avoid redundancies?

                  I can understand that by having this sort of an homeostatic environment aids in assuring a given program will be capable of running on any machine but I can’t shake the intuition that at some point this will backfire. It’s not hard to imagine software to be kept relying on older, perhaps unsafe or not as streamlined versions of given libraries just because the developer is not that motivated to make whatever changes necessary to keep up to date with the new versions, as their software already runs as expected.

                  I’ll risk it and try it.

        • @cmeerw@programming.devEnglish
          1•2 years ago

          Flatpaks can guarantee you have a known-good dependency chain directly tested by the developers/maintainers themselves

          What does known-good mean? What if a security vulnerability is found in one of the dependencies. With an old-style distribution there is a security team that monitors security reports and they will provide a fixed package. With flatpaks it’s not clear to me if those developers will monitor each dependency for security vulnerabilities and how they will handle that. Will users even be informed about a security issue, will a fix be backported or will it only be available in the latest version?

          • Solar BearEnglish
            1•2 years ago

            What does known-good mean?

            Known-good meaning a tested and working configuration approved by the developers/maintainers.

            What if a security vulnerability is found in one of the dependencies. With an old-style distribution there is a security team that monitors security reports and they will provide a fixed package.

            Flatpak is just another model of distribution. There isn’t really anything that needs to change here. The bugs are fixed upstream and they get pushed via the method of distribution, which is Flathub in this case.

            The security team in a given distribution is charged with getting upstream fixes backported and shipped. There’s no need for this role because they’re just shipped directly in most cases.

            With flatpaks it’s not clear to me if those developers will monitor each dependency for security vulnerabilities and how they will handle that.

            The developers are usually the ones doing the fixes in the first place.

            Will users even be informed about a security issue, will a fix be backported or will it only be available in the latest version?

            Well, fixes don’t normally need to be backported because flatpaks are usually fresh. They’re just built normally in most cases.

            For notifications, you’d have to follow the relevant projects directly.

            • @cmeerw@programming.devEnglish
              1•2 years ago

              Known-good meaning a tested and working configuration The bugs are fixed upstream and they get pushed via the method of distribution, which is Flathub in this case. Well, fixes don’t normally need to be backported because flatpaks are usually fresh.

              There are a few assumptions in here in order for that to work: the known-good version needs to be the latest upstream version (otherwise you might not have the latest security fixes) and users need to be comfortable always using the latest flatpak version. Some users might be more comfortable staying on a known stable version for some time.

              For notifications, you’d have to follow the relevant projects directly.

              Right, and each project will have its own way of handling security issues (particularly when it comes to older versions). Will they point out that versions x - y of their flatpak are affected by a security issue in component z?

      • @astray@lemm.ee
        6•2 years ago

        Flatpacks include the dependencies with the application. So different flatpacks may have the same libraries over and over, wasting space. RPM/DEB install just the application and each dependency is a separate package, and packages that use the same dependency will share the one copy. So flatpack is better for consistency when running the app because everyone is running the same dependency version, and space isn’t as much of an issue anymore with nearly everything having more than enough storage.

        • SALTEnglish
          3•2 years ago

          Flatpak share dependencies when they have same version, so they aren’t wasting space. e

    • NickEnglish
      15•2 years ago

      Fedora does the same thing where you can choose between RPM or Flatpak. The only flatpak package I’ve ever had problems with was OnlyOffice, and the issue was that the scaling was blown way out of proportions. Switching to the RPM version resolved that.

  • picnic
    11•2 years ago

    Well fuck snaps. Been using ubuntu for over 15 years and finally starting to move elsewhere, begrudgingly. Finally have had enough after latest lts release.

  • @CaptainJack42@discuss.tchncs.de
    47•2 years ago

    There’s a simple reason why Mozilla/canonical does this and that is security fixes. Due to the difference in support cycles of Firefox and Ubuntu LTS versions fixes would have to be manually backported to the system Firefox version and newer versions won’t run due to library dependencies. Snap solves all of that.

    Don’t get me wrong though, snap is still terrible, but other than flatpak or doing the work of backporting it’s the only option to get security fixes to Ubuntu

      • haruki
        2•2 years ago

        I’m curious, what are you considering moving into?

        • @PseudoSpock@lemmy.dbzer0.comOP
          3•2 years ago

          EndeavourOS. It’s available for Arm64. Has firefox, has chromium, has vivaldi, and even has a widevine plugin builder in their AUR repo for the first two.

          For UTM hypervisor, select the Arch for ARM from their gallery and install it. Then follow the instructions for Parallels to EndeavourOS it. Oh, expand the disk and filesystem first, though.

          It’s quite a step back in time for an installation process, though. Even after getting it installed and setup for KDE Plasma, still need to install a lot of things:

          • NetworkManager
          • git base-devel
          • man-pages man-db
          • dnsutils
          • LibreOffice Plus all the things one installs for customization on any Linux… preferred shell(s), if not bash, shell customizations and completions, various cli’s you’ll want or need, your favorite IDE, browsers, browser extensions, programming languages, ansible, terraform, helm, kubectl, podman and or docker, etc etc.
  • Montagge
    1•2 years ago

    I’ve been having no issues with the Firefox snap on Ubuntu 22.04lts since I upgraded last month.

  • Infiltrated_ad8271
    20•2 years ago

    I’m a bit confused to see that the hate falls entirely on ubuntu. Isn’t the change in the ppa of mozillateam, owned by mozilla?

    Edit: It seems that mozillateam is actually ubuntu.

    • @PseudoSpock@lemmy.dbzer0.comOP
      3•2 years ago

      First, it’s a version behind, prompting Firefox to ask me to erase my existing profile. That’s not going to do. Second, it’s not able to have Widevine added to it, which is needed for video / screen sharing in Teams web client.

    • space_comrade [he/him]English
      1•2 years ago

      I’ve used it a few years ago, it might have gotten better but when I was trying to use it it was annoying as fuck, cross-application links that you would expect to open the browser or whatever other app just didn’t seem to work right and that was kind of a big deal for me since I use Slack a lot.

      Also I’d imagine your disk usage would go through the roof with it.

      I just don’t see the point in it tbh, what was wrong with Linux package management as it is?