Very good, thank you. I did miss the significance of 'unshare' in your post.

Appimage is terrible. It works by trying to make applications in appimages adhere to a lowest common denominator between Linux distros... which amounts to forcing application developers to develop for the oldest version of Linux appimage supports.

Nix is a huge pain to deal with.

Nix makes me think of the old Zawinski joke of:

"Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems,"

Except there are less upsides for using Nix over something like OCI.

It would be more accurate to say that toolbx is based on Podman, but is intended to provide tight configuration with your user's outside environment.

If you want to use toolbx for more isolation you'll have to end up turn off a bunch of features and configuring it in weird ways that ultimately defeats the purpose of having toolbx in the first place....

It is a lot easier to just to cut out the middle man and use podman directly.

Apptainer, like the vast majority of container solutions for Linux, take advantage of Linux namespaces. Which is a lot more robust and flexible then simple chroot.

In Linux (docker, podman, lxc, apptainer, etc) containers are produced by combining underlying Linux features in different way. All of them use Linux namespaces.

https://www.redhat.com/en/blog/7-linux-namespaces

When using docker/podman/apptainer you can pick and choose when and how to use namespaces. Like I can use just use the 'mount' namespace to create a unique view of file systems, but not use the 'process', 'networking', and 'user' namespaces so that the container shares all of those things with the host OS.

For example when using podman the default is to use the networking namespace so it gets its own IP address. When you are using rootless (unprivileged) mode it will use "usermode network" in the form of slirp4netns. This is good enough for most things, but it is limited and slow.

Well I can turn that off. So that applications running in a podman container share the networking with the host OS. I do this for things like 'syncthing' so that the container version of that runs with the same performance as non-containered services without having to require special permissions for setting up rootful network (ie: macvlans or linux bridges with veth devices, etc) )

By default apptainer just uses mount and user namespaces. But it can take advantage of more Linux isolation features if you want it to.

So the process ids, networking, and the rest of it is shared with the host OS.

The mount namespace is like chroot on steroids. It is relatively trivial to break out of chroot jails. In fact it can happen accidentally.

And it makes it easier to take adavantage of container image formats (like apptainer's SIF or more traditional OCI containers)

This is Linux's approach as opposed to the BSD one of BSD Jails were the traditional limited Chroot feature was enhanced to make it robust.

Containers in Linux are more a conceptual collection of different isolation techniques. Mostly just based on Linux namespaces. But things like cgroups, Linux capabilities, occasionally MAC (selinux, etc) and a few other items often get thrown in the mix.

https://www.redhat.com/en/blog/7-linux-namespaces

After a quick view of the apptainer documentation it looks like it minimally takes advantage of user and mount namespaces. So each apptainer gets its own idea of what the users/groups are and what the file system looks like.

Flatpak is more about desktop application sandboxing. So while it does use user and mount namespaces like apptainer it takes advantage of more Linux features then that to help enhance the isolation.

Which appears to be the opposite of the point of apptainer. Apptainer wants to use containers that integrate tightly with the rest of the system with very little isolation versus Flatpak wants to be maximally isolated with only the permissions necessary for the application.

That isn't to say that apptainer can't use more Linux features to increase isolation. It supports the use of cgroups for resource quotas and can take advantage of different types of namespaces for network isolation among other things.

Now as far as "OSTree vs containers" statement you are replying to... This is kinda misleading.

OSTree is designed to manage binaries files in a way similar to git with text file. It isn't a type of container technology in itself. It just used for managing how objects on the file system are arranged and managed.

It is used by some flatpak applications, but it is used for things besides flatpak.

The 'containers' he mentioned is really a reference to OCI container image format.

OCI container images is, again, a way to manage the file system contents typically used in containers. It isn't a container technology itself.

It is like a tarball, but for file system images.

OCI containers is a standardized version of Docker images.

Due to the popularity and ubiquity of OCI image related tools and hosting software it makes sense for Flatpak to support it.

OCI images, when combined with bootc, also can be used to deploy Linux container images to "bare hardware". Which is gaining popularity in helping to create and deploy "immutable" or "atomic" Linux distributions. Fedora Atomic-based OSes seem to be moving to use Bootc with OCI over pure OSTree approach... although they still use OSTree in some capacity.

Incidentally Apptainer supports the use of OCI images (in addition to it's native SIF) as well as other commonly used container technologies like CNI. CNI is container network interface and is used with Kubernetes among other things.