Consider flatpak for some system apps

Flatpak runtime takes ~300mb + ~300mb for locales (shared between runtimes), with a runtime installed, flatpaks are smaller than .deb counterparts, as .deb still need to install dependencies, that flatpak already has in the runtime, so the size overall is very comparable, the problem is that different apps are on different runtimes due to lack of synchronization in release cycles.

So the summary is:

  • under 1gb more space used on end-user machine
  • i haven't seen performance difference between .deb and flatpak on 14 years old core2quad + hd6450 + ssd. investigate if on a hdd there is a noticeable difference and how much does it matter. maybe RAM usage will increase, because apps like nautilus aren't flatpaked, so launching nautilus will launch it's gnome dependencies into ram, and then all the other apps will use flatpak version of libraries. a big issue? for sure on Lite. is it worthwhile to have flatpak on core and .deb on lite? probably not, but lite and core use different apps iirc, one is gnome, the other is xfce
  • apps add new features and provide fixes that don't get added to .deb unless a whole new Zorin release comes along, so we are stuck with say Calendar 3.36 that on flatpak is v41.2 with added ICS file import.
  • removes dependency on given distro packages, making Zorin more flexibile to change distro under the hood
  • if users want to install 3rd party flatpak, there is a chance they will not need to download a runtime, as it would already be installed

App candidates for flatpaking:

  • gnome calendar, gedit, rhythmbox, evince, clocks, todo, calculator and more.

The problem would be, it'd make sense to help upstream keep them updated, because some gnome flatpaks are at v41, and some still use v40 etc. which requires 300mb for each differing runtime needed, ideally there would be only one runtime.

No thank you.

I don't use Flatpaks or Snaps, as I hate them both equally. And yes there are performance issues between them. I only use deb or tar to install any program, and I grab the deb directly from them. Zorin uses Ubuntu to get their software, so Zorin isn't waiting or doing anything in regards to the software, Ubuntu is who you are waiting for.

They're behind, because you have to wait until they compile any update that comes out.

I suspect they are also behind as they are promoting Snaps.

1 Like

I'd advise to not reply to the post if one has no arguments.

On the performance side, snap is very slow, but flatpak is just as fast as .deb, maybe there is some RAM used increase, although my system has 4GB+2GB swap and it runs fine with multiple flatpaks open (tuner, markets, element, bitwarden, signal, geary,evince + .deb brave,vscode,nautilus)
Also, my root partition is 32GB and it accommodates all of this + development libraries for Rust, C++, Flutter + more programs

And the Ubuntu part, Zorin being based on Ubuntu doesn't mean things cannot be changed. They can be, and are.

Moving from .deb to flatpak actually might reduce work required to put the distro together as less QA is needed, because flatpaks are more or less handled by the original developer + all other distros can provide bug reports + things have ability to be updated if something bad is happening rather quickly.

Zorin is using PPA's of their own, a great thing to be replaced by Flatpak if feasible. That what this post is all about.

It's unnoticeable if the app is .deb or flatpak just by using it. They are drop-in replacement except for things that aren't handled by portals currently, which mostly are integrated development environments.

You got me lost here...

For me all .deb packages i download don't even need dependencies. Most of that is already in the OS.

Show me a package other than some extremely simple CLI command that has no dependencies :sweat_smile:

Apt handling it for you doesn't mean there are none.
There are. Flatpak preinstall a whole set of dependencies, that's what i meant.

Overall the flatpak disk cost is small, less than 1GB, the problems arise if there are tons of runtimes because one app uses say gnome 3.36, another 40, 41 etc. so each one downloads ~300mb of runtime.

But that might be easy to handle, especially if tackled together with elementaryOS which switched to flatpaks, and probably Linux Mint could also be interested if the results were promising and calculated.

The only argument you make in favor of Flatpak is that it may contain newer files or versions. For some packages, this is true.
The rest of your arguments in favor of Flatpak are strained... For example, stating that Flatpaks are comparable in size to .deb packages; as long as you support the caveat that the necessary runtimes and dependencies are already on the system.
In reality, most Flatpaks are quite bloated and take up more space than comparable .deb packages.
Packages in .deb formatted are generally more stable, better supported and are not double-sandboxed, so they mesh better with the system and can inter-communicate whereas Flatpaks are isolated.
This "isolation" results in Flatpak packages (Or Snap Packages) simply not working at all because applications that cannot or should not be double-sandboxed or isolated and need communication do not have it.
This is partly due to packaging as Flatpak or Snap being heavily promoted and application developers not fully understanding how Flatpak works, even if Flathub will easily accept any package. It is not standardized appropriately for systems, so anyone can put anything into a Flatpak.

1 Like

Hold on i grab my popcorn...

5 Likes

Flatpak preinstall a whole set of dependencies, that's what i meant.

It might be helpful because someone gets an ISO with say one runtime, and then to install an app like Markets would only use 1.2mb of bandwitch, compared to say 50mb if it was installed through apt, because some dependencies weren't there yet.

BTW Markets isn't even available through apt, so flatpak is not only about the size, which is meant to be reasonable once you have more than 5 flatpaks.
Flatpak is much more.

I'll get some too...

1 Like

Packages in .deb formatted are generally more stable, better supported and are not double-sandboxed, so they mesh better with the system and can inter-communicate whereas Flatpaks are isolated.

The reverse is true. Upstream projects are mad at Debian users reporting bugs that are long gone on newer releases.

Intercommunication is handled by flatpak it uses dbus and portals, if anything it provides infrastructure for better intercommunication akin to ios/android sharing between apps.

This "isolation" results in Flatpak packages (Or Snap Packages) simply not working at all because applications that cannot or should not be double-sandboxed or isolated and need communication do not have it.

That's the case for a limited set of applications, none of the ones i brought up. It happens for wireshark or vs code. the latter might get fixed in a future release.

Might get fixed some day is not really a good argument.

What is this app "Market" that you mentioned? You would do well to post links that demonstrate support for your claims.
Does this Market app have a repository?
Can you cite these upstream developers?

It does not make sense to sacrifice stability just so a few users feel "cutting-edge."

This statement is highly misleading. We are not just referring to dbus, but to dependent Shared Object Files and conveniently omitting them does not eliminate that problem, nor magically enable Flatpak packages communication that they simply lack.

1 Like

You are pathetic, why did you close the UEFI thread by saying it had no merit while you were the person to provide ZERO merit and haven't even read the post?

Might get fixed some day is not really a good argument.

How impertinent you are, it WORKS ALREADY, there are edge cases that are not proposed in this post. Please step down.

What is this app "Market" that you mentioned

Just use GNOME Software, begone troll.

It does not make sense to sacrifice stability just so a few users feel "cutting-edge."

There is less stability from not using flatpaked apps, because those lack updates for years and except hard security problems there are no backports.

Shared Object Files

The RAM usage is what i've already brought up and it is to be determined what is the impact, it is rather low as i mentioned with my machine.

For the same reason I just closed this one:

Continued personal attacks from you will result in more closures.
Remember to weigh arguments and attack the idea, not the person.
Making belittling attacks, mocking or resorting to ad hominem attacks will result in corrective action and This is Not Going to Change.

6 Likes