Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lars Poulsen Newsgroups: comp.os.linux.misc Subject: Re: What exactly is Snap or Flatpack ? Date: Sun, 20 Oct 2024 01:11:15 -0000 (UTC) Organization: A noiseless patient Spider Lines: 71 Message-ID: References: Injection-Date: Sun, 20 Oct 2024 03:11:16 +0200 (CEST) Injection-Info: dont-email.me; posting-host="b39cce8543f53c55c4b4499302579713"; logging-data="132693"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/SiPEECHVUIMycyEl0rt8eiPlMvP8HdPc=" User-Agent: slrn/1.0.3 (Linux) Cancel-Lock: sha1:FbAY/J/khDm3HhiB9UmDeGxz3Xg= Xref: csiph.com comp.os.linux.misc:59640 On 2024-10-19, Phillip Frabott wrote: > On 10/19/2024 15:55, Rich wrote: >> Lars Poulsen 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?