4 ms·
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 res
by vbezhenar 4y ago
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 4y agoContainers usually ship their own libraries, which means less sharing, more disk usage and higher memory pressure.
- vbezhenar 4y agoThat 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 4y agoContainers can use the same base image for the OS.
- rusk 4y agoI 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 4y agoAnd much lower chances of getting security updates, now that everything is a huge blob.
- IshKebab 4y agoIt's not just the camera process though - containers ship an entire OS (except the kernel).
- aljarry 4y agoThough 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.