I think Blow has a different take on this, but here are my thoughts on why Docker shouldn't be necessary in the first place.
Operating systems we use today were designed in an era when security and isolation were an afterthought at best. Plenty of security features have been bolted on over time to enable what we now call containerization, such as cgroups, namespaces, seccomp-bpf, capabilities, etc. But each part was added separately with its own API and tricky edge cases. Docker is needed as a midlayer to package them up into something a normal person can use.
If, however, the OS was designed from the ground up so that every process is only handed exactly the resources it needs (files, network endpoints, device handles, ...) as capabilities, every application would simply run sandboxed by default. Instead of taking away / altering permissions from a process that starts out with all permissions, we'd only add the exact capabilities it needs via a unified and clean system API. Capabilities handle not only permissions but also make namespacing practically free. The only Docker-like thing we might still need is a way to package and distribute images, but that's a much simpler problem to solve.
This is not a new idea, Fuchsia basically implements this. seL4 provides the necessary foundation as well. Plan 9 at least has per-process namespaces, which get us most of the way there.
Docker is a workaround for the lack of coordination that occurs when there's no ownership of things. Other operating systems have no equivalent of Docker because they don't need it.
Consider macOS. The closest equivalent to a container is the bundle. Bundles are much better that containers in several ways:
1. They're much simpler. Just directories with a special structure that's recognized by the OS.
2. They're much more efficient. A bundle ships only the program and any dependencies that sit outside the OS, but Apple invests so much in developing frameworks and in backwards compatibility, that a huge range of apps can be built that require no additional dependencies whatsoever. It's common for sophisticated Mac GUI apps to have bundle sizes in the tens of megabytes, whereas Docker images often require pulling gigabytes. Bundles are typically updated using tight per-file delta update schemes like Sparkle or the App Store, whereas Docker's delta update support is minimal (whatever was easy to implement at the time, basically).
3. They're decentralized. There is no de-facto reliance on a collection of hubs which charge lots of money for bandwidth (some companies block Docker Hub for this reason). Nor is bundle identity allocated by registries - you can create a bundle with a stable identity that survives upgrades even if you pass the bundles around on SD cards.
4. They're actually more "UNIX philosophy". You can move them around and organize them in the same way as any other kind of file or directory. You can "cd" into them from the shell, or synchronize them with Google Drive. There is no need for special servers, repositories, pulls or pushes.
5. They have much better support for sandboxing.
6. They share the same namespaces as the host, so there are no confusing path remappings going on. Despite that, sandboxed app get private areas of the user's home directory that are protected from other apps.
The underlying architecture here isn't perfect; bundles evolved over a period of decades and there's no rigid spec for the internal directory layout. The OS relies on collections of heuristics to identify bundles in a few cases. But it's architecturally much cleaner than Docker.
First of all, macos bundles are nowhere near as flexible or "powerful" as OCI containers though. Even if you add all of docker features and knobs onto macos bundles, how do you think that's implemented? through a darwin syscall `run_bundle()`?
as for the list of points:
1. sure, though an OCI image can be exported to a flat bundle too if you don't care about layer efficiency
2. that's one of the things you don't want with docker containers. Nothing is stopping you from `-v /usr/lib:/usr/lib -v /bin:/bin` but you don't want that. Arguments about how much Apple or Windows puts into backward compatibility are moot once a minor breaking change is pushed to these machines without you knowing about it or if you want to explicitly have a different version of a platform library or dependency for one particular container
3. OCI registries are decentralized. The reliance on docker hub is just a convenance. It's like git is decentralized, the fact that everyone relies on GitHub is their own issue. If a DmgHub came up tomorrow where everyone uploads their dmg to it, and it became the socially acceptable place to always fetch dmgs from, did bundles become suddenly centralized and we need a different OS primitive to be decentralized again? the reason they are decentralized today is because no one cared to centralize them (except Apple's App Store of course)
4. You can do that with OCI images too
5. Nope. What's the bundle's equivalent of seccomp profiles? user-mode kernel/runsc? kata (VT-x or AMD-V) isolation?
6. That's a downside not an upside. You can put all your OCI files under /app, and mount the rest of the host mount namespace too. No one does that because they don't want to, not because it's not possible.
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?
> Hey Windows MCP, run X on one core, run it on a linux kernel shim, isolate it from every other core, and assign it its own file system. Use a cooperative scheduler, but retain the ability to release the core. Assign 8GB RAM to be addressable by that core only. Create a virtual network adapter, and assign an IP , which uses taht reserved core and 8GB only.
We're so far away from that its absurd. Yet an O/S designed from the ground-up to be simple (on modern hardware), would make that very simple.
It does all the constraints up until the memory only addressable by that core. Not sure if all of them support that. Also not sure where the external networking state of all 4 solutions are, but all 3 platforms are fully capable of that. So I guess what's mainly missing is the MCP? It doesn't sound like a "design an OS from the ground up" type work, more like create an MCP that can orchestrate the existing primitives to achieve that.
