[conspire] People failing to learn about package gatekeeping, part 2

[Rick Moen]

Deliberately circumventing your distro's package regime is reckless.
People keep learning that the hard way (or, worse, never figuring it
out.

Here, three more of innumerable examples of the "circumvent the package
regime" questionable idea:  AppImage, Flatpak, and Snap -- all three 
intended as "non-native "universal package formats" so that the same
ill-suited binary and bundled libs / support files can be kludged into
working anywhere without the work of creating and maintaining distro
packages.

Autopackage, Zero Install, and AppDirs are similar "universal package
formats", cited in passing.   All deliberately circumvent the
orderliness and protection of your package regime, to your detriment,
and should be used, if at all, with reluctance, caution, _and
expertise_.

Or, tl;dr:  if you're not absolutely certain you know what you're doing,
just don't.


----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Sat, 16 Apr 2022 20:52:15 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Felton LUG <felton-lug at googlegroups.com>
Subject: Re: [Felton LUG] Flatpak cs. Snap vs. AppImage
Organization: If you lived here, you'd be $HOME already.

Quoting Robby Elliott (robbytexteditorelliott at gmail.com):

> What's the BEST? Flatpak vs. Snap vs. AppImage Benchmarking (youtube.com) 
> <https://www.youtube.com/watch?v=OftD86RgAcc&t=329s>

How about:  All three non-native "universal package formats" are bad
ideas?

"AppImage":  You don't get normal distro files in a package.  Instead,
you get a ISO 9660 Rock Ridge FUSE filesystem, that inside, has the
executables, all support libraries, and all support files.

"Flatpak":  You don't get normal distro files in a package.  Instead,
you get an OCI (Open Container Initiative; basically, Docker) sandbox
managed by systemd, cgroups, and bind mounts, that inside has the
executables, all support libraries, and all support files.

"Snap":  You don't get normal distro files in a package.  Instead,
you get a SquashFS FUSE filesystem, that inside, has the
executables, all support libraries, and all support files.

What problem do these three things solve?  Basically, it's "Hi, we're a
distro that doesn't want to bother with software package maintenance
construction and maintenance, so we're going to push some concept that
amounts to reimplementing Docker badly, so that users don't get apps
compiled for their distro policies and libraries, but instead
self-contained software environments that _duplicate_ system libraries 
and ignore distro policies."  Basically, they're borrowed the Windows
.EXE format and made it worse.

GNOME pushes Flatpaks because they're all about replicating every single
mistake Microsoft ever made.

Canonical, Ltd. pushes Snap because it caters centrally to Windows users
and saw an opportunity to add support for untold thousands of
proprietary applications without spending Canonical money -- a high
priority when you're such notorious skinflints that you're incorporated
in a tax haven (the Isle of Man) so you don't have to pay corporate
taxes.

I have no clear idea exactly why Simon Peter invented AppImage.

Other implementation of this solution to the wrong problem:  Mike
Hearn's Autopackage, Thomas Leonard's Zero Install, ROX Desktop's
AppDirs.  Collect the whole set!


Among the metrics the YouTuber self-identifying as "TechHut" didn't
bother to measure is RAM usage.  As mentioned, all of the non-native
"universal package formats" bundle the desired executable with a 
special, bespoke full set of support libraries, rather than using distro
system libraries.  So, each Docker-style containerised app hurls _all_
of its special libraries into RAM and hogs it.  This is true even if you
run _two_ containerised apps that happen to use the same libraries.
That doesn't signify, because each is running in its own secluded
pseudo-OS, and there's no opportunity to gain the normal benefit of
shared dynamic libs (of, e.g., loading and using only _one_ of each).

His idea of measuring "performance" is just execution time, as if
nothing else matters.  Must be nice to have gobs of RAM to waste.

That having been said, he's correct that real, native packages
inherently are going to make significantly better use of CPUs.  (He
said, e.g., that an AppImage of GIMP on Ubuntu (or Fedora?) was "faster"
(in rendering) than was the native package.  That may be so, but that
means that the native package was badly constructed.  AppImage imposes
non-trivial overhead.

Personally, I'd _consider_ getting an AppImage of something if, for some
bizarre reason, there's no real native distro package -- but, first, I'd
look into just compiling to /usr/local/* from a tarball, as a less-bad
fallback.  I don't find "let's reinvent .EXE, except worse" to be a good
idea.


----- End forwarded message -----