Except each container has its own libc and any other dependencies. If any linked binary or library has a different inode, it gets loaded separately. I would say it is indeed quite similar, even if the images in question here aren't hundreds of megabytes in size like with Electron.
theamigan
joined 1 year ago
It seems every new shiny technology today tries its darndest to short-circuit 40+ years of advances in OS virtual memory design. Between Electron and Docker, the entire idea of loading an image into memory once and sharing its pages among hundreds of processes is basically dead. But at least there's lower support burden!!!1111
If you think OpenAI themselves are any better than Google, I have a bridge to sell you.
This has been on my list of things to do for some time. I took a look at the API calls once and it seems they purposefully obfuscate doing a manual call.
By definition, if you don't feel like putting in the homework, you are ceding control to someone else. At that point, all bets are off. Even trustworthy entities can turn on a dime. Ease and full control are mutually exclusive.
What exactly do you want to achieve in terms of security?
I'm beginning to think many people here just want to throw money at a vague concept of "security" without having a crumb of a threat model in mind.
"Different inode" means a different file entirely, not necessarily its majorminor:inode tuple resolved through bind mounts/overlayFS/whatever. I'm saying that if you have containers using even slightly different base images, you effectively have n copies of libc in memory at once on the same system, which does not happen when you do not use containers.