Sorry; that’s not quite the point I’m making. The difference I want to emphasise between 2 and 3 is whether the new tool is layered on top of the existing tool, or made by modifying the existing tool. If you want a new approach to storing data, do you make it by writing a new kernel module, or by doing some new thing in userland on top of the filesystem?

All of docker’s features could be built into the Linux kernel. And it would probably be better as a result, and have ancillary benefits to existing Linux programs. But docker was built as a separate userland tool instead.

Building a new thing is usually easier, since you don’t need to dive into the politics of an existing community. But if each new generation of software engineers builds new software by layering on top of the old stuff, then we end up with layers on layers of cruft and our computers run slower and are more buggy as a result.

The POSIX apis aren’t very good in lots of ways. With a lot of complex effort in userland I can make a database with atomic write semantics. But maybe we should just add atomic file operations to Linux instead. In the long run I think it would be safer and result in faster programs in most cases.

Yes. Docker has proved there's utility in what it does. Assuming kinks in the implementation have been ironed out, now is the time to start thinking about making it a kernel module.

If you just put every half thought out, poorly implemented idea straight in the kernel, you'd have a 5 petabyte kernel.