AFAIK its limited to desktop apps. Could find confirmation quickly.
Podman
Doesn’t need a daemon.
AppImage
does not offer form of self-check with package authenticity verification or runtime confinement by sandboxing
LXC
Starting with the LXC 1.0 release, it is possible to run containers as regular users on the host using “unprivileged containers”.[7] Unprivileged containers are more limited in that they cannot access hardware directly. However, even privileged containers should provide adequate isolation in the LXC 1.0 security model, if properly configured.
In contrast to OpenVZ, LXC works in the vanilla Linux kernel
LXD
alternative wrapper around LXC developed by Canonical
LXD is a system container manager, basically an alternative to LXC’s tools, not a “rewrite of LXC”. In fact it is building on top of LXC to provide a new, better user experience.
Snap
Snap is a software packaging and deployment system developed by Canonical for the operating systems that use the Linux kernel. The packages, called snaps, and the tool for using them, snapd, work across a range of Linux distributions and allow upstream software developers to distribute their applications directly to users. Snaps are self-contained applications running in a sandbox with mediated access to the host system.
Snaps are self-contained packages that work across a range of Linux distributions.
supports any class of Linux application such as desktop applications, server tools, IoT apps and even system services in contrast to flatpack
There is a Snap Store but Snap itself can be used without a store. Snap packages can be obtained from any source, including the website of a developer.
OpenVZ
Memory allocation with OpenVZ is soft in that memory not used in one virtual environment can be used by others or for disk caching.
allow each container to have its own file system.[2]
The OpenVZ kernel is a Linux kernel, modified to add support for OpenVZ containers. The modified kernel provides virtualization, isolation, resource management, and checkpointing. As of vzctl 4.0, OpenVZ can work with unpatched Linux 3.x kernels, with a reduced feature set.
Each container is a separate entity, and behaves largely as a physical server would. Each has its own files, System libraries, applications, virtualized /proc and /sys , virtualized locks, Users and groups (including root), virtual Process tree including init, virtual Network, Devices and IPC objects
A live migration and checkpointing feature was released for OpenVZ in the middle of April 2006. This makes it possible to move a container from one physical server to another without shutting down the container. The process is known as checkpointing: a container is frozen and its whole state is saved to a file on disk. This file can then be transferred to another machine and a container can be unfrozen (restored) there; the delay is roughly a few seconds.
Charliecloud
a set of container tools used on HPC systems
Kara Containers
Bottlerocket
Linux-based open-source operating system that is purpose-built by Amazon Web Services for running containers on virtual machines or bare metal hosts
Some may not be real containers because they don’t have compartmentalization or sandboxing, but this is not always clear at first encounter.
Actually I don’t like the term “sandbox” in context of security because a sandbox is a place where you can freely play around but nothing holds you back from leaving it and do something (potentially problematic) in the rest of the world.
If it is true that I can’t handle non desktop environment or GUI programs with flatpak than I probably don’t want to use it, too. Unfortunately there are flatpaks used (developed?) here in the community. They may have good reasons which I don’t see, yet. From my current perspective I would like a well designed system for all programs not only such with graphical UX.
Would be sad if the community and Purism bet on the wrong horse. Maybe someone can explain it. Maybe its just a system well known. Learning something new is always some effort and people have already stuff to do. But it may be good in the long term.
Some people may don’t like snap because of canonical. As long as I wouldn’t be to dependent on them personally I would focus on the technical criteria.
I liked the idea, but could never get Firejail to work on my Librem 13 v4. I would probably best be described as a Linux sophomore: I can usually get things done in the command line when needed, but can rarely accomplish this without a tutorial. This was not one of those times. I was either missing something crucial as to the basic functioning of Firejail, or flat out doing it wrong. This was in early 2019, maybe things have improved. Does anyone know of a good tutorial/manual for Firejail that they have used recently? I can’t remember, but assume I tried using whatever documentation came with it.
There are multiple separate concerns mixed up here. At least those:
package management
software distribution
permission management
For example, podman as such doesn’t do any distribution. AppImage doesn’t do package managmenent much, just leaves it to the file system. Flatpak doesn’t always include permission management.
It’s useful to classify things to understand what they are, because then you can realize that some entries on this list have no comparable properties. For example, Firejail doesn’t manage or distribute the software it runs, and for AppImage, distribution is the only thing it does (as far as I know).
Yes that’s true. I already thought of making a list of criteria and then we could reading search which system provides what. I just had to start the journey somewhere.
I guess if the aim is to run applications in an isolated environment, you could add guix containers to the list. You get those by running guix environment with the --container flag.
guix itself is a GNU project, and it’s both a package manager and a distribution. The package manager can be used on foreign distros
If the concern listed here are real, and I have no reason to doubt that they are, why is Flatpak being championed by Purism?
Furthermore why aren’t we just using snap? I get it Canonical dares to try to survive by making money and so they are evil, but it is clear their solution, as usual, is the better solution.
But maybe I’m too close to the thing, and am missing things.
I think we just see the reality of life differently. The reason the snap store has one repo is because this is one of the stumbling blocks for people learning Linux. Needing to add repos, and finding the info to add the repos is not always intuitive or something the user has time for.
I think Canonical has explained very well why things with the snap store are the way they are.
I get that this would be a reason for Purism not to use it, but Flatpak is not a better solution, and this is the tragedy of the FOSS mindset, IMHO.
I’m just curious, who is using these containers now? From practical experience, which is going to make it the easiest and most future proof to sandbox browsers and apps that pass internet data to the app?
I want all that completely isolated from the rest the system, with all the data self contained.
I’ve never built a container, but will dedicate the time to learn it, if others are having success doing this.
Now we agree. Declaring something better without considering the criteria is meaningless. And/or misleading.
I’m going to give a very unsatisfying answer: it depends on how you value different aspects of it.
Completely isolated - buy another computer. Or at least run it inside a VM, maybe using Qubes. Easiest - don’t do any isolation.
Flatpak is reasonably easy to use, but you must trust the developers again that they limited permissions themselves. It seems like it will improve in the future.
So far the constraint seems to be that a good number of the apps I use aren’t on Flatpak or Snap. And/or those containers don’t sandbox the data to the container.
I can imagine the right solution would A) make it easy to turn any app into a container and B) conitain all app data inside that container. Which of the ^^^ do you think would best meet those directives?
).