Snaps, Flatpak's, and Hard Drive Space

[Shibblet]

I did an install of Kubuntu 24.04.1, and did a little testing.

I partition a 32g / (root) drive, and then use the rest of the disk space for /home.

I installed all of my usual apps. The app installations on the root drive add up to about 14.1gb of space.
I decided to install all of the apps as FlatPak's instead... This added up to 22.1gb of space
Then I loaded up all Snaps, and this added up to 25.7gb of space.

This is the total amount of space used on "/", including the OS.

I did not test AppImages.


Please tell me again what makes Snaps & Flatpaks so much better?
All of the problems have still not been taken care of.

They don't run as quickly.
They take up more disk space.
They don't integrate into your OS correctly.

Why do we keep pushing foward on these?

[deadflowr]

Please tell me again what makes Snaps & Flatpaks so much better?
All of the problems have still not been taken care of.

Not sure what makes them better but the goal is having a single package that runs across a broad range of distributions and versions.
So you can have the same version on Fedora as you do on Ubuntu or Arch, and it doesn't matter which version of any of those you're using.

For end users it means very little, but for developers it means less time trying to get it to work on errant releases all the time.
Which means getting updated, possibly better, versions rolled out faster to everyone.

[1fallen2]

Why do we keep pushing forward on these?

One of the reasons why Snap and Flatpak were developed was to remove the dependency issues found with traditional package managers. Snap and Flatpak packages contain all the software necessary to install the package in question, including dependencies.
So, when you go to install a certain piece of software via either Snap or Flatpak, you don't have to worry about installing dependencies .

I have No issues with speed and Flatpaks, Now Snap's is a totally different experience....That's about as nice as I'm going to get on that matter.

On which flatpak are you speaking about that don't work?>>>Never Mind if your going to use any Buntu DE they will protect their snaps.

If I want Flatpaks or even appimages, I'll flat just use another Linux system like Arch, Pure Debian w/o snaps, or any .rpm based system

[grahammechanical]

There is a push for immutable operating systems with the containerization of applications. This is supposed to provide a less hackable computer OS. Snaps and Flatpaks provide the containers that applications run in.

Fedora has an immutable OS that uses Flatpaks for application containers. Canonical has Ubuntu Core as an immutable OS with Snap packaging providing the containers for the applications.

Unlike Silverblue Ubuntu Core does not have a desktop environment or user interface. But it is an immutable OS.

https://fedoraproject.org/atomic-desktops/silverblue/

https://pages.ubuntu.com/rs/066-EOV-...412.1715731804

Canonical was working on a desktop environment for Ubuntu Core. A development version was supposed to be released during 2024 but there has not been much news about it. But then again, I do not do much Canonical reading.

There is this:

https://cdimage.ubuntu.com/experimental/ubuntu-core-desktop/24/stable/20240209/

I might give it a try, Regards

[TheFu]

Constraints and the fact that the OS running doesn't limit you from having the latest version of a specific program. Some people are running their Ubuntu desktops using ESM/PRO support for 10 yrs, so they could be on Ubuntu Desktop 18.04 still and need/want the latest version of Firefox to "just work".

For most people, using a few GB extra isn't a big deal. It is for you and for me. We aren't typical users with 1TB storage devices.

Of course, the constraints can be limiting for some people - perhaps you are in that group. I am as well.

But most people don't care much if the OS and packages use 50G or 100G. It isn't important, so they don't worry about it and move on.
As for RAM use, whenever we have 3 or more versions of Qt and GTK+ on a system and run programs that require all 6 of those to be in RAM, then it isn't unreasonable to expect the price of that flexibility to be more RAM used. It is less important on newer releases, but much more important on older, but still supported, OS releases.

If snaps and flatpaks aren't for you, that's fine. Don't use them. If you don't want to fight Canonical's choice, there are other distros which don't mandate using either. For example, MX Linux doesn't use systemd, which seems to be a requirement for snaps to work. Linux Mint has been vocal about not wanting to mandate snap packages, so it isn't required there, but we have the choice to use them, or flatpaks, if we like. I'm certain there are other distro that leave the choice to us as well.

In theory, 24.10 will allow more local control over the constraints required in snap packages. We shall see and I'll wait until 26.04 to see it myself. By then, hopefully, we'll be allowed to have HOME directories anywhere we like, not just to hard-coded /home/ locations and NFS support will be a 1st class citizen for anything related to snaps. I can hope.

[Shibblet]

For end users it means very little, but for developers it means less time trying to get it to work on errant releases all the time.
Which means getting updated, possibly better, versions rolled out faster to everyone.

So, what you're saying is that it's more beneficial for the developer, and not necessarily the end-user?

One of the reasons why Snap and Flatpak were developed was to remove the dependency issues found with traditional package managers. Snap and Flatpak packages contain all the software necessary to install the package in question, including dependencies.

Even if you already have the dependencies required? The Snap and Flatpak has them reduntantly?

Fedora has an immutable OS that uses Flatpaks for application containers. Canonical has Ubuntu Core as an immutable OS with Snap packaging providing the containers for the applications.

I like the concept of an immutable OS, but that gives too many limitations. One set of dependencies is all that is needed. i.e. If Telegram needs "whatevertheheck.xml," and so does Signal, there is no point in having it twice.

For most people, using a few GB extra isn't a big deal. It is for you and for me. We aren't typical users with 1TB storage devices.

Not as a whole... but it can REALLY mess up smaller partitions.

[Tadaen_Sylvermane]

So, what you're saying is that it's more beneficial for the developer, and not necessarily the end-user?

The typical average user doesn't know the difference other than "why are my packages on this distro but not that one?" type of thing. They don't generally have any philosophical reasons to be against them nor does it impact them in any noticeable way. And it's a good thing to make it easier for developers. Contrary to popular belief just because you have access to source code doesn't mean you can successfully build it. Most people cannot do that, much less port it to match a given library difference or whatever. And the developers are working on new stuff and fixing bugs. Why should they waste time making a separate package for each of the billion distros when they can make one agnostic package that doesn't rely on anything specific from any specific distro. Makes to much sense to not do it. In cases where distros package stuff for their prized distro then that is duplicated effort all over the place for almost no real benefit to the average normal day to day user who doesn't give a crap and just wants it to work.

The shared library distro specific packages are very fitting in a server environment. Desktops are different, the end goals are different. It just can't work because there will always be a distro or hundred that are left out of some software for some ridiculous or arbitrary reason. People should be able to pick a distro they like (personally I think there are to many options and it needs tamping down) but they can't do that when they have to pick the one that runs the software they need without jumping through hoops.

An example. I enjoyed my time with Fedora Silverblue. I like the immutable concept and really didn't want to layer packages on top of it. I couldn't get Makemkv to build properly and run in a home directory bin to save my life. Fedora doesn't include non free packages. So Fedora is out the door for me. The flatpak just stopped working on me for some reason so I had to leave Silverblue to rip my dvds. I picked immutable for a reason. I didn't pick it so I could modify the base image.

People who care about the philosophical stuff like this are an ever decreasing minority. I think the arrival of appimage, flatpak, and snaps is a harbinger of this. People just want their software to work and care less and less everyday about the little things that the "older" generation of *nix users cared about. Now they just want to run their games or whatever. They don't want to have religious discussions on why distro X is better than distro Y or vise versa. They just want their software with no fuss.

It's ironic. We see this daily in governments. The younger generations want something different than the older generations. The older generations fight tooth and nail to keep things the way they always were, even when people benefit from some of the changes. It's human nature to change over time. Things that were once important aren't as much anymore.

[1fallen2]

In theory, 24.10 will allow more local control over the constraints required in snap packages. We shall see and I'll wait until 26.04 to see it myself. By then, hopefully, we'll be allowed to have HOME directories anywhere we like, not just to hard-coded /home/ locations and NFS support will be a 1st class citizen for anything related to snaps. I can hope.

It's still in theory, I'm on 24.10 currently and I see no changes on that front.

What I do "see" is from 24.04 thru 24.10 is they seemly are making what was working to not working without some sort of work around.(Flatpaks and Appimages)

[lammert-nijhof]

I experience an advantage every week. I still use Ubuntu 16.04 ESM (Extended Security Maintenance). I also installed the latest stable snaps of Firefox and LibreOffice, Ubuntu 16.04 LTS already had almost full support for snaps. I only have to drag the icon of the refreshed snap back to the Unity dock.

Note that Ubuntu 16.04 ESM now has the same releases of Firefox and LibreOffice than Ubuntu 24.04 LTS and for LibreOffice Ubuntu 16.04 ESM is sometimes ahead on the deb version in 24.04 LTS

[Perfect Storm]

I always advise people to get rid of Snap and rely on .deb and in cases flatpaks. Snap is sloooooooooow when you try to use an app that is packaged that way, also snap.d has a great impact on the bootup speed in a negative way.