[GoLUG] Bottles

[Kyle Terrien]

On Sat, Feb 22, 2025 at 12:52:47PM -0800, Ron wrote:
> Alex Finkel wrote on 2025-02-22 12:02:
> 
> > One big difference between
> > Snaps and Flatpaks is that the Snap backend infrastructure is
> > proprietary and controlled by Canonical.
> 
> Who controls https://flathub.org, and how is that different than
> https://snapcraft.io/store?

Red Hat.  😛

Canonical controls Snapcraft, and Red Hat controls Flathub.  So, you
have to pick your political alliance and aim the mud cannon at your
opponent.  Tribalism is strong.

I, however, am aligned with neither Red Hat nor Canonical.  So, I will
throw mud at both.  The situation stinks.

Both are intended for use by upstream developers, so eventually they
will run into the “App Store” problem of having 50 different
flatulence apps, 48 of which are malware, because nobody can review
someone else’s code perfectly.  Both resolve and install dependencies,
in their own packaging formats, even though both claim they are
entirely flat packaging formats.

On the bright side, at least Flatpak will let you add third party
repos.  So, there is an escape hatch, for now.

At least Flatpak doesn’t require systemd.  Snap does require systemd,
so if you are a Gentoo or Devuan chad, then snap is not for you.

However, it is unfortunate how awkward Flatpak makes it to simply run
a program from the shell.  You have to do ‘flatpak run
org.wibblebubble.blahblah.cool-word-processor’ in order to get your
program to run.  It would be nice if Flatpak installed wrapper scripts
to pretend like there are actual binaries installed.  Unfortunately,
Red Hat’s answer to that is to install GNOME.

AppImage had the best approach, i.e. pack everything into
self-extracting executables, just like on a Mac.  Unfortunately for
AppImage, they didn’t have the right political alignments.  GNOME
threw a wrench in their plans when they made it harder to launch
executables from Nautilus (do they still let you do that?), because
GNOME is Red Hat’s toy.  Ubuntu (the other major desktop integration
effort) didn’t care to placate AppImage either, because Canonical had
snap, and why would you need anything other than snap?  So far no one
has standardized on decent glue for launching and managing AppImages,
because Red Hat and Canonical have strong political swing.  So, us
AppImage fans get by with symlinks, custom .desktop shortcuts, and ad
hoc glue attached to packages.

With regards to the security and isolation aspects of containers, I
have personally seen too many issues, in all three formats.
Sometimes, the UI is broken because of theming, and sometimes basic
things like opening a web page in the user’s web browser don’t work.
The common pattern is lack of knowledge of the packaging tool on the
part of the upstream developer.  Considering the current situation
pushes upstream developers into supporting two or three of the
“universal” packaging formats, I’m not surprised when one of their
packages have bugs.  Upstream developers are good at developing their
own applications.  You can’t expect them to understand all the system
intricacies Red Hat and Canonical invent to keep their supporters
employed.

Anyway, sooner or later, more people will realize that Plan 9 had the
right model---per process mountspaces.  If you want to isolate a
process (or a group of processes), simply unmount the resources you
don’t want it to access.  Because everything was a file (including
network sockets and /dev/draw), all the kernel had to do was keep
track of filesystem permissions and who had what mountspaces.  (Side
note: too bad Wayland doesn’t have /dev/draw.  Maybe its successor
will.)  Linux containerization implemented some of these per-process
mountspaces (and namespaces).  Unfortunately, not everything in Linux
is a file, so we need complex orchestration like Docker, AppArmor, and
SELinux to tell the kernel how to cordon off what we need to cordon
off.

That’s all for now!

--Kyle Terrien


-- 
[*] Kyle Terrien
    Terrenus => from the Earth, to the Cloud
    https://terren.us/

Dilexisti justitiam, et odisti iniquitatem.  -- Psalmus 44:8