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*?
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)?

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?

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?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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*?
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)?

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?

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?

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

Snap is the work of the devil [Ubuntu/Canonical]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-20, stepore <stepore@be.here.now> wrote:

On 10/19/24 18:11, Lars Poulsen wrote:

And how does this relate to kubernetes?

Snap, flatpak, appimage are distribution-independent software package formats. They bundle the application with all its required dependencies.

So does static linking. :-)

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/19/24 18:11, Lars Poulsen wrote:

And how does this relate to kubernetes?

Snap, flatpak, appimage are distribution-independent software package
formats. They bundle the application with all its required dependencies.

Kubernetes is an example of containerization or "virtualization" on an operating system level or application-level that includes network,
memory, cpu resources, so that applications can run ( using these
resources ) in isolated userspace and namespace.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

On 2024-10-20, stepore <stepore@be.here.now> wrote:

And how does this relate to kubernetes?

Snap, flatpak, appimage are distribution-independent software package
formats. They bundle the application with all its required dependencies.

So does static linking. :-)

I'm not sure about Snap and Flatpack, but from looking at AppImage
many of the packages for it are for programs that won't build with
static linking. It also does still leave some libraries to be
provided by the system by default, like OpenSSL.

I explored making AppImages to make a portable build of a large GUI
program that wouldn't link statically, but jeeze it was a whole
lot more work than making a static binary.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)