The MacOS kernel and userspace does recognize bundles yes. If you exec() a program inside a bundle it will use the bundled frameworks (hence the name), and the OS will verify the code signature over every file, for example. Other OS services will use bundle identities for all kinds of things. That's why if you run a terminal you have to give it special access if you want to run vim on a file inside an app bundle. This is all mediated by the kernel and Mach IPC.
1. You can export images, but why is this complexity necessary in the first place? Efficiency does matter.
2. Bundles support different versions of frameworks than what comes with the system, that's not a problem. However it isn't mandatory like it is with containers. And yes, obviously you can make a container that isn't contained, but they aren't meant to be used like that - you are meant to always ship a complete userspace with the program, even if it's nothing more than a tiny script.
3. They aren't decentralized in any meaningful way. Blackhole Docker Hub on your machine and see how far you get. There's no equivalent problem for bundles.
4. Docker containers aren't natively files or directories, which is why you have to use separate commands like "docker image ls" instead of the real ls. You can turn them into files but then they aren't natively usable in that state until you import them.
5. Look into Apple's entitlements, code signing and TCC system. It's much more advanced than anything Linux has.
6. We'll just have to disagree on that. Namespacing is a crude hack that introduces many new kinds of bugs and configuration difficulties. Compared to just running the thing, it's worse.
1. The OCI format is what gives you the efficiency. If one company is producing 10 dozen dmgs with shared library or framework in all of them, on mac today those are all not shared. With OCI those layers are shared when needed and different when needed. If you want to flatten them to tarballs, you can if you don't care about that efficiency vector.
2. They are meant to be used however you want them to be used. That was my point in their flexibility. There is literally no reason you couldn't get the same behavior of macos bundles with containers with the examples I gave if you have uniform host (like Apple gives with their macos uniform/controlled systems)
3. Docker Hub is already blackholed in most enterprise environments as you mentioned. There is literally no problem other than convenience. What possible problem could there be? Would git not work if GitHub is blackholed?
4. Again, there is literally no reason you couldn't get it to work that way. It's a very low hanging fruit that no one cares about.
5. Not true. It's more centralized and wallgardend, so it's easier to configure since there is one way of doing it which is Apple Inc way. I thought you argued against centralization. Again, how do I do user mode kernel in macos?
1. You can export images, but why is this complexity necessary in the first place? Efficiency does matter.
2. Bundles support different versions of frameworks than what comes with the system, that's not a problem. However it isn't mandatory like it is with containers. And yes, obviously you can make a container that isn't contained, but they aren't meant to be used like that - you are meant to always ship a complete userspace with the program, even if it's nothing more than a tiny script.
3. They aren't decentralized in any meaningful way. Blackhole Docker Hub on your machine and see how far you get. There's no equivalent problem for bundles.
4. Docker containers aren't natively files or directories, which is why you have to use separate commands like "docker image ls" instead of the real ls. You can turn them into files but then they aren't natively usable in that state until you import them.
5. Look into Apple's entitlements, code signing and TCC system. It's much more advanced than anything Linux has.
6. We'll just have to disagree on that. Namespacing is a crude hack that introduces many new kinds of bugs and configuration difficulties. Compared to just running the thing, it's worse.