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.