| I respect the attempt to shift perspective very much, but you only engaged at a surface level with the reasons I listed. >The first is that it's not easy; but `docker run` or `podman run` is easy. I was referring to easy use from a full fledged programming language. When you start a subprocess in your programming language of choice, do you always run it in a container? I seriously doubt it, and the reason for that is because it's hard. >The second reason was about gdb No, the second reason was about user namespaces, which break many things including ptrace, which in turn breaks gdb, as just one example. There's lots of useful tracing and monitoring software which makes occasional use of ptrace. >if multiple processes should be managed as a single unit (including the case when we'd want to terminate a whole group of processes) they should run in the same container Yes, that's true. And indeed, scripting use cases often have that characteristic, where everything can be terminated at once at the end. You can compare this to missile-style garbage collection: Just never free your memory/processes. Unfortunately, long-lived applications both need to free their memory over time and need to clean up their processes over time. |
I use a (standard) library to start subprocesses in my favourite programming languages.
For running a container, I'd also use a library.
Seems about equally hard, no?