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.
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.
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.
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.