Linux Containers Comparison - Quest for the best

There are several containers or containerization systems for Linux let’s discuss the differences, pros and cons for comparison.

I am no expert but this is my current state of knowledge (without having used any of those containers at all :innocent:).

List of known containers:

  1. Docker
    Future seems questionable.

  2. Flatpak
    There are critics like that on https://flatkill.org

    AFAIK its limited to desktop apps. Could find confirmation quickly.

  3. Podman
    Doesn’t need a daemon.

  4. AppImage
    does not offer form of self-check with package authenticity verification or runtime confinement by sandboxing

  5. 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

  6. 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.

  7. 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

    Depends on systemd and AppAmor.

    more on sandboxing, resource management and security

    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.

  8. 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.

    more on resource management

    more on limitations

  9. Rkt

  10. Singularity

  11. Linux-VServer

  12. System-nspawn

  13. Charliecloud
    a set of container tools used on HPC systems

  14. Kara Containers

  15. 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

  16. Imctfy
    not actively developed since 2015

  17. Manual chroots, namespaces and cgroups

3 Likes

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.

I prefer snap, and I haven’t seen a single reason to use flatpak over it. In fact, I’ll be installing snapd on my Librem 5 just as soon as I get it.

1 Like

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.

Podman seems another promising candidate.

Any comments on Firejail?
https://ownyourbits.com/2017/10/29/sandbox-your-applications-with-firejail/

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.

Some general info to this subject. I didn’t read it myself, yet.

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).

7 Likes

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.

Thank you so much for your explanation, @dcz Dorota!!
So, please let us know which container(s) L5 uses and why?

1 Like

I have only seen Flatpak on the L5. It’s focused on user experience, and has security capabilities, so I think it covers the needs.

3 Likes

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

4 Likes

I think I can only edit the post a limited number of times. So I will wait a bit if there comes more and then I’ll add what has been found.

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.

1 Like

Guix seems to be onto something.
that EXWM + Emacs combo looks so yummy :slight_smile:

  1. https://open.lbry.com/@SystemCrafters:e/what-is-system-crafting:b
  2. https://open.lbry.com/@SystemCrafters:e/an-introduction-to-gnu-guix:9
  3. https://open.lbry.com/@SystemCrafters:e/installing-the-gnu-guix-package-manager:c

there are some more indepth on the channel but David said that he does requests/sponsorships so if you CAN go for it :slight_smile:

2 Likes

Some reasons:

https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html

Although it is open-source, Snap on the other hand, only works with the Ubuntu Store. Nobody knows how to make a Snap Store and nobody can.

Sadly, part of the Snap store is still closed source.

Sounds like you declared it better prematurely :slight_smile:

5 Likes

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.

2 Likes

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.

3 Likes

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?