Do containers have a maintenence problem?

Various types of containers (Flatpak, Snap, Appimage, Docker, Steam) are being promoted as alternatives to the traditional Linux package systems. It is asserted that containerising the runtime environment of an app solves the problem of dependency updates breaking a package.

There is , however a serious problem with this approach - it lacks a maintenance strategy.
Lets imagine that some important library ( such as has a bug. The fix, under a conventional package system, is to release an upgraded version of, and that automatically fixes every package that uses that library, in every computer worldwide.

But what happens to containers that have embedded in them because it is a requirement for the main container app. There is no organized maintenance system. Millions of containers all over the world have to be manually rebuilt to include an updated
A major disaster with an important library has not happened yet… but it will.
The situation is like a time-bomb

So I would question whether containers are really a solution to package management. I think containers freeze your app in time, and ignore maintenance needs.

There will certainly be other opinions.
If you want to read more about the disfunctional aspects of containers try this
Here is a challenge… prove me wrong!

1 Like

I can understand your warning in a hazy, conceptual way, but that makes it no less valid. I think you’re right–barn door closed, new horse can’t get in.

1 Like

Hi Neville, :wave:

I read your post and I must say: you certainly worded well what I am thinking too. :+1:

I totally agree with you and I´ve never been much of a friend of those alternative packaging formats, especially snap
… although I like experimenting with docker (in a vm though).

I also read the article you provided a link to. That was very intersting. :smiling_face:
I was particularly amazed at the download size of Kcalc :astonished:

It´s especially the forceful integration of firefox as a snap-package by ubuntu that in all probability will make we go away from Lubuntu next April and move to e.g. Linux Lite.

Many greetings from Rosika :slightly_smiling_face:

1 Like

It has been pointed out to me , privately, that Docker containers do have a feature called auto-pull. If this is set, and the user kills off the current container and starts a new one, then the new container automatically downloads the latest image from the image repositary.
I would not call that a maintenance system, but it obviously helps.

I have no idea whether Snap, Flatpak, or Appimage have any maintenance system. Does anyone know?

A partial answer here

1 Like

Here’s one thing that cheeses me off about docker - I have no idea how to look inside a docker container… I know perfectly well how to look inside a Solaris container - that’s a proven rock solid container system - well into it’s 2nd or 3rd decade of longevity (yeah we all know Solaris is doomed, it was the moment Oracle bought Sun)… I’m still a bit ambivalent about docker and kubernetes and all that stuff (lost count of the amount of airhead loudmouthed “architects” [on paper] who spout marketing buzzwords like “koober netties” like they even know what the f–k that even is)…

Take for example the two “today / yesterday” CVE’s for OpenSSL - I spent the whole morning looking through hundreds of Linux servers - only to realise - those CVE’s really only apply to “bleeding edge” shit - and Corporates don’t run bleeding edge, they mostly run LEGACY EOL (end of life) shit…

So - I can say with certainty - NONE of these servers have or are runningOpenSSL 3.x. Except / BUT - what’s inside those f–king docker instances I have no visibility of? Are they running OpenSSL and what version if yes?

and yes - I feel much better now I’ve got that off my chest and out of my spleen :smiley:

1 Like

If you have access to the image, you can start a container which runs bash like this
docker run -it imagename /bin/bash
then you can at least use the shell to look around the filesystem inside the container.
This may fail if the image does not contain bash. In that case use sh

I have not learnt any other method, except to read the Dockerfile

I dont know anything about Steam. Its websites are all hype and no substance. It says it can run games in a container, but is it a container itself? What does Steam actually do that makes everyone want to run games that way? Why dont people just run games like all other apps, by installing a package?
So can you enlighten me about Steam?
Is SteamOS the same thing as Steam?

1 Like


What an impressive read, I never like the idea of when installing an app with Appimage or snap and flatpak all the packaging is thrown in, in a just incase it’s needed,
As in Window$ need to find an app in the wide expanse of sites (trustworthy ?)
That’s why Linux is my choice for my computer,
Tried it once out of ?? , no thanks it’s better to find an alternative app than constipate my machine

A small quote from Nicholas Fraser

Mass containerization and alternate runtimes cannot possibly be the future of desktop apps on Linux. If this is really the direction it’s going, the future will be so shitty that we’ll all end up back on macOS or Windows.

Do you need a blanket for that chill down your back . . .

That Linux has it’s own software stores is a big plus, all the different Distros with different versions is exactly what keeps Linux safe and secure from attacks viruses malware etc

Yeah having a centralized set of base level libraries would seem to be a fantastic way to have software compatible with maybe not all but most Distros.

mm (much like Window$) yeah and how easy for some smartipants kid show all the friends look what I can do to Linux mm

If Linux stood proud of what it is and that is what attracted people to it’s shores back a decade or more (Its Own way of doing) instead of going into the latest trend or great idea. ( give a break )

Are we fashionistas ?

Stop trying to please this silly crowd who want The GIMP to look like Photoshop etc.
When MOST times these people seek help in forums And never give a Thank You reply or mark the post as solved.

Short time back I moved from GeckoLinux to SpiralLinux inbetween did a bit of hopping found that Gmusicbrowser is not supported in from the Debian family

Could have gone back to EndeavourOS can get all I want and need there BUT I now prefer the much slower pace where I am.

That’s OK found alternate ways of getting the replaygain tags done so solved, oops sidetracked

While visiting other Distros found that the only way to get Gmusicbrowser was appimage or snap what a shock to find that the music player ( the best on the shelf Thank You )

Normally Gmb is about 2.5 Mb is from Software center
Appimage or snap a huge 3.1.or 3.5 Gb
Just to be clear apart from being massive and soo sloow to start up I found thats not worth the extra baggage and moved on to another distro to stay.

NO if it is not in the software center of the Distro or the (with caution) AUR or OPI it’s not on for this machine.

Big no no to Snap, Flatpak, or Appimage

The way to screwing up your install or the Distro or the entire system is really easy go and install anything from anybody and that is a window to ruining all the hard work and long hours from millions of volunteers.

0Oh what happened I just had an episode.

I think I should wear a hat out in the sun.

Kind Regards

1 Like

Hi @artytux ,
Those 2 points are incredibly important.
We need Linux to stay diverse.
We need Linux to improve its own package management systems, so that there is no argument for promoting bloated alternatives like snap and flatpak

A centralised repo of base level libraries would be a good start.

One of the questions I keep asking is
“What do snap and flatpak offer that could not be achieved by using static binaries”
True, static binaries would still be bloated, but they are a hell of a lot simpler than containers.
There must be another better solution




Yes I agree partly
sounds good on paper
Don’t know if I’m right or wrong that I also strongly fear if that centralised libraries was to happen in Linux then only a matter of time before one or more of the libraries could be corrupted with a virus, malware or any other malicious code.

Isn’t Linux’s distros sort of isolation from each other kept all of Linux distros safe for the most part kept the malicious garbage out ?

Then Linux would not any better off than Window$ with it’s battle from the ongoing assault of malicious coders.


C’mon, Nev, I’ve been really stretching my brain trying to understand the container concept and now you tell me there’s a simple solution? Are developers so egotistical that elaborate container concepts are ‘better’ than simple static binaries? Linux needs to be diverse and SIMPLE.


@ daniel.m.tripp
To see the Dockerfile without having the Dockerfile you can do: docker inspect imagenamehere

That produces a JSON result that shows each line of the Dockerfile. It probably started with some other container as a base and performed a few things on it like updates and adding a few other packages.

Maybe that isn’t quite what you were looking for?

Running the container and opening an interactive shell like @nevj said is even better for you especially. You can get right to the nuts and bolts of what’s there.

1 Like

Hi Neville,

Quick question about updates. In Linux when I “apt” an install or update of a package, what update type of maintenance is it? (Flatpak, Snap, Appimage, Docker, Steam). And what about “.deb”.

Or more general, how is Ubuntu types Linux updated?


1 Like

I think that is partly true.
What also protects Linux is the smaller number of users to target with malware. But if you then divide that small number of users across 200 distros, it makes for an even smaller target.
I do,also think that the Linux code, at least the kernel is inherantly superior, both for security issues and for actual performance.

Well can someone please tell me if I am wrong.
What does a container do that a static binary can not do?

To make a container you have to hand assemble all the components.
With a static binary the compiler makes it for you.

We have forgotten our past. Static binaries were once the only form of executable program

Dont know about egotistical , but there is a tendency to make things complex then declare that it is ‘improved’


So wouldn’t a centralized library

Make it easier to organize and publish new and improved software, yes with a huge risk factor.

If the software (pick anything) becomes more standardized, more accessible, more shared between Distros, that would in time prove to be making Linux a popular and easy choice for computer users.

Containerized apps didn’t do that, probably because of their size in Gb and not Mb for an app.

Looking forward IF a centralized library system was in place with all the niceties and Linux ( in the future) has a marketplace of not 1% to 5% lets say it had 25% to 50% and that is possible.

How does a centralized library (that most will be distros sharing) stack up from a cyber attacker

It’s that decentralized libraries that Keep Linux diverse will keep Linux and it’s user safe


Hi Howard,
Apt updates are just .deb files.
A .deb file is an ar archive containing tarfiles and a few scripts.
Maintenance of .deb files consists of adding new versions to the distros repositary, and letting all users download them with apt.
A release upgrade shifts to a whole new repositary.

Appimage is not really a container , it is an image file… like .iso files or squashfs files. I imagine it has a few scripts as well as an image, but I have not looked in detail. Think of it as an iso file, but for just one app, rather than a whole linux distro.

Snap and flatpak are genuine containers, like docker containers.
Ubuntu seem to have setup snap to behave like apt, but to use containers instead of .deb files. So you can update them.
Dont know how flatpak works.

Docker is containers without any update system. You just do it by hand.
There is some setting that says automatically download the latest version from from a docker repo, but that is all the help you get with maintenance. There are things like Kubernetes which help to manage large collections of docker containers, but management is not maintenance.

Steam I cant fathom. Its website is all hype and no content. It is some thing that runs on either Ubuntu or SteamOS that allows users to use games, videos, etc.


There is a fair bit of centralisation ,already.
A lot of Debian derivatives depend on Debian repos.

So , in your view , the other major distros ( rhel, opensuse, arch, …) and the smaller independent distros ( void, solus, bsd, …) are very important, because they maintain the diversity.
I agree.

1 Like

Did not know that.

The bottom line is, you cant look at a running container. You have to have access to the image.

You can with what you suggested earlier. Right?

Quite a bit to unpack… :smiley:

  1. that method looks very similar to how I’d look inside a FreeBSD jail :

jexec $JAILNAME /bin/tcsh

AFAIK - and - I am a big Steam on Linux user - they’re not “containerised” - but Steam manages the licensing?

e.g. I can find the binaries - and I can tweak various settings (e.g. the occasional game setting that’s in a “naked” text file I can edit with vi)… Another example : I use Proton / SteamPlay to run quite a few Windows only games - e.g. Age of Empires II HD Edition : and I hate how it fires up some lame piece of crap “launcher.exe” (i.e. through steam) - so - I just rename launcher.exe to “AoK HD.exe”… that simple… the files are not obscured or obfuscated or anything, not even the Windows games…
Note also : I used to do “cheating” by hacking my Borderlands 2 (NATIVE Linux game ported by Aspyr and 2KGames) savegames e.g. adding stacks of loot and $$$ into my savegame - then editing those into a Windows 7 VM with a savegame editor that does even more cool stuff…

SteamOS is “two things”… and not the same thing as Steam necessarily…

e.g. I run Steam on Ubuntu 22.04… Steam still assumes Ubuntu 12, and installs a bunch of i386 stuff as well as x86_64 - and has folders here and there about your system like “ubuntu12” or whatever… This is just “Steam” - the client.

SteamOS :

“SteamOS” that you can download to run on your own hardware is a Debian based (10???) distribution that Valve used to market and you can still get it.

“SteamOS 3” is their own Arch** based operating system that ships on their SteamDeck portatable handheld (Ryzen with AMD Vega8 graphics) - its a similar form factor as the Nintendo Switch (which I also believe, like the Wii, runs some kinda Linux or BSD NIX under the hood). Valve do plan on releasing “SteamOS 3” to run on stuff other than their own hardware - I’m planning to try this out on my Lenovo E495 Thinkpad, as it is similar specs as the SteamDeck (Ryzen 5, Vega8 graphics).
** at one time - Valve (the Steam people) recommended trying Manjaro if you wanted something close to what they’re shipping on the SteamDeck…