[vbezhenar]

Do you oppose running camera software in a separate process? I think it makes sense. Camera process might crash and will be restarted, this should not cause restart of the entire shell.

What people should understand is that container in Linux is just a separate process running in powerful chroot (which isolates not just file tree, but also process tree and other things).

So the same reasoning which applies to running some code in a separate process also applies to running some code in a separate container.

I'd even argue that in an ideal world, almost every process should run in a separate container. The tooling is not here, but concept is just fine.

[garaetjjte]

Containers usually ship their own libraries, which means less sharing, more disk usage and higher memory pressure.

[vbezhenar]

That depends on implementation. Shared libraries which use the same inode will be shared AFAIK. If containers use different libraries, they'll not be shared, of course, but that's a deliberate choice of container creator.

[bonzini]

Containers can use the same base image for the OS.

[rusk]

I see these as a relatively straightforward set of problems to identify, quantify, and remedy. It’s a tradeoff between static memory usage and stability. If that additional memory footprint becomes an issue you can make plans to align dependencies.

[goodpoint]

And much lower chances of getting security updates, now that everything is a huge blob.

[IshKebab]

It's not just the camera process though - containers ship an entire OS (except the kernel).

[aljarry]

Though you don't need most of the OS - you may run bare bones containers with just a statically built binary inside the image, e.g. it's possible in Go.