Re: What exactly is Snap or Flatpack ?

On 2024-10-19, Phillip Frabott <nntp@fulltermprivacy.com> wrote:

On 10/19/2024 15:55, Rich wrote:

Lars Poulsen <lars@cleo.beagle-ears.com> wrote:

I feel like I have been living under a rock for the the last decade
whenever people mention /snap/ and /flatpack/.
>
1) Are they the same idea as /kubernetes/, and if not, then what is
    *that*?

 
In a /similar/ ballpark, but not quite /the same/:
 
Snap: https://en.wikipedia.org/wiki/Snap_(software)
 
Flatpak: https://en.wikipedia.org/wiki/Flatpak
 

2) What is the difference between them (other than that they are two
    incompatible brands, like /apt/ and /yum/ (aka /dnf/) are functionally
    the same thing, but incompatible with each other)?

 
They are very similar to each other, to the point that one looks to be
a NIH syndrome [1] of the other.
 

Is it just packaging the executable with all the libraries it references
and a wrapper that sets up paths to those libraries, or is there a
virtual machine involved?

 
Both run inside a "sandbox".  So they therefore depend upon whether
your definition of "virtual machine" extends to include "sandboxed"
software.
 

Do these wrapped applications see the full file system, or is there a
shell game of /chroot/ and links or loopback mounts to break out?

 
Presumably they have a limited view of the native filesystem.  The snap
wikipedia page says "limited access to the host system" but does not
define if the "limits" included "limited access to native filesystem".
The Flatpak wikipedia page says "Flatpak[s] need permission to access
... files" so it somewhat more explicitly implies a limited view of the
native filesystem.
 

At 74 I am old, but I hope to still learn some new things!

 
[1] Not Invented Here
 
 
 

>
Just to add to what has already been said, snap and flatpak packages
tend to include all their dependencies so it is a self-contained
packages that doesn't tend to need dependencies beyond the package
manager itself. If I recall (I don't use flatpaks) they are mostly
statically linked within the pack so regardless of which distribution or
GNU/Linux installation you use, it's compatible (within reason). Based
on the technical definition of a virtual machine (a self-contained
hypervisor that is isolated from the rest of the hardware within the CPU
and memory mapping) it is not a VM. And I don't consider it a container
either (although others will likely disagree). it's just a package that
contains everything the application needs to run. And since it's kept in
a nice package, it's easy to remove as well.

It sounds like it is a great way to create a package that is
self-contained enough that it can be installed without change on a large
variety of distrubutions. That is great for the developer/maintainer.
But for the user, it is great if your distribution has chosen not to
support that application. But if a "native" package is available for
your distribution, it is less attractive.

If you have installed a snap/flatpack package, can you then later
install add-on plugins?

And how does this relate to kubernetes?