LXC has supported user namespaces since 2013 and it works well enough. You could run unprivileged containers from Ubuntu 14.04. I think Nspawn supports it now t

LXC has supported user namespaces since 2013 and it works well enough. You could run unprivileged containers from Ubuntu 14.04. I think Nspawn supports it now too. This is different from running the Docker from a user account. With Docker you are interfacing with the Docker daemon from a non root account but the container is still running as root. With Unprivileged containers thanks to user namespaces containers are launched and run from the user account. But unprivileged containers need to be a simple no fuss experience and this can only get addressed in the kernel. On top of that the most popular user land container implementation Docker chooses to run containers without an init and since most apps you want to run in a container are not designed to work in an init less environment and will require daemons, services, logging, cron and when run beyond a single host, ssh and agents, just managing the basic process of running apps and their state adds tons of additional complexity for users. Integrating user namespaces on top of this is going to be non trivial. Contrast that with LXC containers which have a normal init and can manage multiple processes enabling your VM workloads to move seamlessly to containers without any extra engineering. Any orchestration you already use will work obviating the need for reinvention. That’s a huge win but if you listen to the current container narrative and the folks pushing a monoculture and container standards it would appear there are no alternatives and running init less containers is the only ‘proper’ way to use containers, never mind the complexity. A lot of problems related to unprivileged containers are in kernel namespaces and cgroups which are not going to be solved in user land. Cgroups are not namespace aware and only root users can manage them. Access to resources like mounts and networking require privileges and that won’t change. These are probably not 'sexy or fundable’ so the problems remain unsolved, and instead complexity deriving from niche use cases whether security or micro services is foisted on everyone. A container is just a Linux process in its own namespace that anyone can create with unshare, iplink and chroot or pivot root. An ‘immutable container’ is nothing but launching a copy of a container enabled by overlay file systems like aufs or overlayfs, a ‘stateless’ container is a bind mount to the host. Using worlds like stateless, immutable or idempotent just obscures simple underlying technologies and prevents wider understanding of core Linux technologies that need to be highlighted and supported. But we choose to focus on wrappers and the narrative becomes about funding and standards. Without more focus and support on the filesystems, namespaces and other critical enabling technologies end users will not get a consistent experience. How much support do they have beyond the occasional article on LWN? These devs and projects work in obscurity with little support. This does not seem to be sustainable development model.