Would be nice to see at least a high-level overview of how it works under the hood. Is it doing anything interesting with reusable layers? Actually, thinking further that might be a moot point; I feel like running as a remote proxy loses some fun optimization chances. I could imagine a world where you install a package from the host's pip/uv, and then add it to a container image, and both of those are actually the same thing on disk. (Granted, that's likely harder to implement)
There are still growing pains, but https://github.com/osbuild/bootc-image-builder exists and is likely to become exactly that in the general case (as it already is for the redhat family).
Oh those size limits are pushed plenty by AI images, no worries. I recently had a good laugh when I found a docker image that was 2 - 3 times as big as the OS partition of a lot of our smaller servers.
And our OS image build order would reuse layers better than those.
Would be nice to see at least a high-level overview of how it works under the hood. Is it doing anything interesting with reusable layers? Actually, thinking further that might be a moot point; I feel like running as a remote proxy loses some fun optimization chances. I could imagine a world where you install a package from the host's pip/uv, and then add it to a container image, and both of those are actually the same thing on disk. (Granted, that's likely harder to implement)
Or you could use GitLab which has support for Python packages without a proxy.
can we agree to use OCI for everything :D
as long as we can convert the OCI to an bootable VM image, i am fine with that. But i also think, there's an size limit
There are still growing pains, but https://github.com/osbuild/bootc-image-builder exists and is likely to become exactly that in the general case (as it already is for the redhat family).
Oh those size limits are pushed plenty by AI images, no worries. I recently had a good laugh when I found a docker image that was 2 - 3 times as big as the OS partition of a lot of our smaller servers.
And our OS image build order would reuse layers better than those.
No doubt, I've regularly encountered ~2TB container images with enough layers to make one weep. SISO, slop in/slop out (sorry).
Time to find out if one can make a dockerbomb image >:-)
I believe in you, 'fallocate' can be put into entrypoint :P This way the size is a surprise, not constant
i think it's already been done with bootable containers.
redhat has recently GA bootable container as well.