Ubuntu Talks Up Faster KDE Snaps, But Still Takes A While For Cold Apps To Launch

[Paradigm Shifter]

How about ignoring Ubuntu? If you need something with ppa support just use an Ubuntu based distro like pop, they ripped that bs out. Even though I have to admit in some cases it seems to have more trouble than even Debian, at least with proprietary software like Zoom and Discord, or with properly using Wayland. Or use Mint, would be surprised if they didn't kick snaps to the curb

Mint has been extremely vocal about their dislike of Snap and preference for Flatpak.

I've had issues with Flatpaks as well (the Flatpak for GNU Octave used to take some effort to get packages to install/compile/run correctly; not sure about current state because I gave up and started compiling the whole thing from source) but my experiences with Snaps has always been poor.

[mppix]

Mint has been extremely vocal about their dislike of Snap and preference for Flatpak.

I've had issues with Flatpaks as well (the Flatpak for GNU Octave used to take some effort to get packages to install/compile/run correctly; not sure about current state because I gave up and started compiling the whole thing from source) but my experiences with Snaps has always been poor.

Snaps should be piped to /dev/null.

Flatpaks have a ton of potential. However, I don't know why they don't somewhat simplify the use of the command line. It is quite clunky.

[rmnscnce]

I recently set up a jammy (22.04) install, and they re-versioned firefox so that the snap firefox version number now starts with 1:, this means it will by default have a higher preference than even a higher non 1: package. This means that if you try to install the Firefox Next ppa for example it won't work as the snap version will always have a higher preference, regardless of the firefox version (snap vs non snap). So to fix this I had to add a

/etc/apt/preferences.d/nosnap.pref

file with the following;

# kill it
Package: snapd
Pin: release a=*
Pin-Priority: -10

# kill it with fire
Package: firerfox*
Pin: release o=Ubuntu
Pin-Priority: -10

This will stop any Ubuntu released versions of Firefox from being considered for installation. Unnecessary pain to avoid snap versions of software. You may also need to add other package names after firefox in the second rule if you're doing something similar with other packages.

In packaging terms it's called an epoch, by the way. It's useful to revert software versions to a latest-known-working version after an engineering mishap was shipped into the package repositories, without creating a million conflicts in the package management system -- something that Manjaro decided to not do back in 2019 with its systemd package.

[jo-erlend]

I wonder if that's system-related, 'cause the Snap fan club always points out that Snaps always launch fast, even on cold starts.

Can you provide an actual example of that? I've been accused of saying that so many times I couldn't possibly remember, but the only thing that I have _actually_ said is that I think that fixing so many fundamental problems with Linux is worth some temporary speed issues.

I see a lot of people like you, though. I think it's possible that you're being tricked by your own propaganda.

[ssokolow]

Snaps should be piped to /dev/null.

Flatpaks have a ton of potential. However, I don't know why they don't somewhat simplify the use of the command line. It is quite clunky.

If you look through their GitHub Issues, you'll see that their response is essentially RESO WONTFIX "Out of Scope. We do GUI apps and don't want to have to be responsible for the complexities of CLI invocation."

Here's a Proof of Concept I wrote and daily-drive for vetoing their idiotic, Tab-completion-hostile "Reverse DNS CLI command names" export system in favour of a hand-rolled one that, as a POC, just trusts that you won't install two things with the same command name at the same time.

It doesn't restore the MPV manpage or rename PPSSPPSDL, scummvm_wrapper, or jd-wrapper to their expected names (ppsspp, scummvm, and jdownloader), and I'm still waiting on the open discussion surrounding how to officially support applications that need to access siblings of the file access has been granted to, so there are some places on the hard drive where my tightened sandboxing settings for Firefox break local HTML rendering but, otherwise, it's trivial to forget that the applications are installed via Flatpak, aside from being newer versions than the usual offerings for an LTS release.

[ssokolow]

but the only thing that I have _actually_ said is that I think that fixing so many fundamental problems with Linux is worth some temporary speed issues.

However, Flatpak shows that said speed issues aren't inherent in fixing the problem... especially if you rely on Flatpak's runtimes and OSTree-based file deduplication and ZFS's filesystem compression together to get what should be much better space efficiency than Snap can offer with its compressed bundles.

[skeevy420]

I hope their team finds out about the ZSTD

That'll be a Phoronix headline in 2032.

[jo-erlend]

However, Flatpak shows that said speed issues aren't inherent in fixing the problem... especially if you rely on Flatpak's runtimes and OSTree-based file deduplication and ZFS's filesystem compression together to get what should be much better space efficiency than Snap can offer with its compressed bundles.

I have no clue how your comment relates to my statement that I am willing to sacrifice several seconds per month for an improved situation down the line. I'm not sure what you mean by compressed bundles. I am terrified to think that you might still believe that snaps can't use shared dependencies, as if we're still in 2014. That would've been so humiliating that I would feel compelled to hide my face in a pillow on your behalf.

Obviously, snaps can use whatever filesystem is most productive, including ZFS or Btrfs; it's just a filesystem on a loop device. It is only limited by the oldest kernels in common use. Right now, there is no support for ZFS in the Linux kernel, so it should not be set as a requirement for using universal Linux packages. But it really seems weird to me to use ZFS as an attack vector on Canonical. Who else are working to make ZFS a first class citizen on Linux?

The snap format was obviously designed to be used on phones that only had access to Android kernels, the goal being to provide a plain GNU+Linux BSP snap that you could then build any normal distro on, Ubuntu Personal obviously being Canonical's priority. We would simply have to accept that we can't fight the OHA at this point, but in return, get access to modern phone hardware on which we could start the process of making Linux for phones. Sure, I own a PinePhone and I love it, but I also have a Samsung Galaxy S8 in my drawer doing nothing. I would really love to be able to install a GNU+Linux distro on such powerful hardware and use that to demonstrate where things are going. I think that would accelerate interest in Linux phones.

Sure, if Snap had not been designed for convergence, then the old Linux versions used in Android phones could simply have been ignored and more modern technologies used from the very beginning and then you would've had less leverage to enforce obedience to the IBM. That's ok. I accept that. But I am disobedient by nature and I don't believe in enforced conformity. As an explorer, I thrive on being able to play around with different technologies and different combinations of tools.

I like the traditional Linux distro using a package manager. I think Snap is the most promising solution to the problem. I enjoy flatpak as well, but I don't see it as a sacred weapon to destroy the enemy, but simply as an GUI app delivery method.

[ssokolow]

I have no clue how your comment relates to my statement that I am willing to sacrifice several seconds per month for an improved situation down the line.

My argument is that it's completely unnecessary to make that sacrifice. I'm reminded of that scene in Robin Hood: Men in Tights when Achoo is pointing out that Robin Hood and Little John don't need to fight over crossing the bridge when the stream is so tiny you can just step over it.

I'm not sure what you mean by compressed bundles.

Installed snaps are stored as compressed filesystem images. That's why a switch in compression algorithm affects program startup time.

Installed Flatpak apps are stored in an OSTree repository, which looks sort of like the inside of a .git/objects directory.

That's why the compression Flatpak people choose is only relevant to download+install times and you or the system integrator get to choose whatever filesystem-provided compression you want, including none at all.

Much more flexible in response to things like what hardware primitives may make a given compression algorithm the best trade-off and applicable to all installed applications, not just the ones installed through snappy.

I am terrified to think that you might still believe that snaps can't use shared dependencies, as if we're still in 2014. That would've been so humiliating that I would feel compelled to hide my face in a pillow on your behalf.

Because it uses a Git-inspired repository system rather than compressed filesystem images, Flatpak can complement its shared runtimes with a system of using hardlinks to automatically deduplicate individual files that weren't available in any of the runtimes and had to be bundled into the application package.

They then ensure it will have good results by providing "baseapps" for things like Electron, QWebEngine, and Godot, which are like superclasses for packages. They do get bundled into your package, but they also ensure that there will be a lot of duplication that can be skipped by the "download only the chunks we need" install process and the hardlink-based deduplication of installed files.

(That's why the Flatpak CLI's download progress indications are "up to..." values and you often see the download complete at a lower number than expected... I assume because OSTree's plumbing doesn't do a preliminary pass to give Flatpak's porcelain accurate information on how much required data is already present.)

For example, here's a fragment of a Flatpak manifest I wrote for "LGOGDownloader, with the optional QtWebEngine-based reCAPTCHA support enabled":

"runtime": "org.kde.Platform",
"runtime-version": "5.15-21.08",
"base": "io.qt.qtwebengine.BaseApp",
"base-version": "5.15-21.08",
"sdk": "org.kde.Sdk",

...and deduplication can be quantified. For example, this script reports that I have 17.6GB of files installed through Flatpak, but only 10.6GB of files actually on disk (determined by counting each inode's filesize only once to omit deduplicated paths). That's...

• ...before any sort of filesystem compression. (And compression doesn't automatically replace deduplication even within a single compressed artifact, since making your compression too solid prevents random access.)
• ...including deduplicating both the runtimes and the applications. (eg. two different versions of org.kde.Platform will share inodes for any identical files)
• ...not counting savings from using runtimes. (eg. None of that is from "Snappy can use runtimes too!". It's purely "Because we don't store installed applications as compressed filesystem images, we can automatically deduplicate at the file-by-file level.")

Obviously, snaps can use whatever filesystem is most productive, including ZFS or Btrfs; it's just a filesystem on a loop device. It is only limited by the oldest kernels in common use. Right now, there is no support for ZFS in the Linux kernel, so it should not be set as a requirement for using universal Linux packages. But it really seems weird to me to use ZFS as an attack vector on Canonical. Who else are working to make ZFS a first class citizen on Linux?

You missed my point entirely. I'm pointing out that Flatpak demonstrates that it's unnecessary for the package maintainer to choose a filesystem or on-disk compression scheme at all, giving downstream more freedom to choose what best fits their situation.

I like the traditional Linux distro using a package manager. I think Snap is the most promising solution to the problem. I enjoy flatpak as well, but I don't see it as a sacred weapon to destroy the enemy, but simply as an GUI app delivery method.

Look up OSTree, the underlying system that Flatpak extends that's used for things like Fedora Silverblue. Snaps are "a sacred weapon to destroy the enemy" because Canonical has been PR-spinning "We smushed the functionality of OSTree and Flatpak together into a single poorly-factored system" as "We're better than Flatpak".

Aside from that, I find Flatpak to be much more philosophically aligned with traditional package management. For example:

• You can technically run your own snappy repository, but parts of Canonical's server-side componentry are proprietary. Flatpak and Flathub are fully open-source. There's a section in the Flatpak manual on hosting your own repository and Flathub page footers link to the GitHub repo for linux-store-frontend where the README tells you how to set it up.
• Last I heard, Snappy is still built around Steam-like forced updates while Flatpak follows the APT/RPM/etc. lead in letting you choose what you update when.

The design model that Flatpak operates on for Snappy's functionality is:

• Use OSTree directly if your distro incorporates Snappy-like immutable packages for system components.
• Use the sandboxing support in systemd unit files if you don't want to run your system components unconstrained.
• Use the filesystem image mounting support in systemd unit files if you still have a need for services distributed as filesystem images.
• Use Flatpak for desktop applications, which builds on reusable components intended to also get used on their own, like OSTree, bubblewrap, and XDG Portals. (XDG Portals being an example of a Flatpak component from the days when it was called xdg-app that Snappy adopted too.)

In the longer term, systemd's support for user services is intended to bring a lot of what systemd offers for system services to the desktop application sphere, rather than reinventing it separately.

Snappy is "here's a monolithic blob we're throwing over the wall", while Flatpak is more "here's a family of cooperating components, emerging out of discussions on Freedesktop.org, that align with the UNIX philosophy". (Heck, that's why bubblewrap presents a more primitive API than Firejail. Stuff like D-Bus proxying is handled by a different component.)

[conualfy]

Because it uses a Git-inspired repository system rather than compressed filesystem images, Flatpak can complement its shared runtimes with a system of using hardlinks to automatically deduplicate individual files that weren't available in any of the runtimes and had to be bundled into the application package.

They then ensure it will have good results by providing "baseapps" for things like Electron, QWebEngine, and Godot, which are like superclasses for packages. They do get bundled into your package, but they also ensure that there will be a lot of duplication that can be skipped by the "download only the chunks we need" install process and the hardlink-based deduplication of installed files.

(That's why the Flatpak CLI's download progress indications are "up to..." values and you often see the download complete at a lower number than expected... I assume because OSTree's plumbing doesn't do a preliminary pass to give Flatpak's porcelain accurate information on how much required data is already present.)

Question from a newbie: how does this work in the case of a library that is not downloaded initially (abc.v1) that is needed for a program to run, but the system then updated it's library to abc.v2 and my software needs v1 to properly work? It will download v1 at that moment or my software will break? Thanks.