Deutsch English Français Italiano |
<vnbjih$bkg$1@reader2.panix.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.2602:f977:0:1::2!not-for-mail From: Ruben Safir <mrbrklyn@panix.com> Newsgroups: comp.os.linux.misc Subject: Re: What exactly is Snap or Flatpack ? Date: Tue, 28 Jan 2025 21:52:17 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <vnbjih$bkg$1@reader2.panix.com> References: <slrnvh80eq.2vpb7.lars@cleo.beagle-ears.com> <vf12sb$tb1$1@dont-email.me> <vf18h9$1qgm$1@dont-email.me> Injection-Date: Tue, 28 Jan 2025 21:52:17 -0000 (UTC) Injection-Info: reader2.panix.com; posting-host="2602:f977:0:1::2"; logging-data="11920"; mail-complaints-to="abuse@panix.com" User-Agent: tin/2.6.3-20231224 ("Banff") (NetBSD/10.0 (amd64)) 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. > That sound do different than a statically compilled binary in a tarball.