Well, I'm fine with journalctl and machinectl as they're part of systemd. I'm not really fine with having to install respectively arch-install-script, deboostrap+debian-archive-keyring, debootstrap+ubuntu-archive-keyring to run an Arch, Debian or Ubuntu container. What if I want to run something like CentOS or Alpine?

>But then, I can't expect Red Hat to invest into advertising for a core system component, because developers ought to be aware of it.

That's why Docker has the market. systemd is huge and scary, developers see it as a sysadmin only component. You cannot expect developers to know systemd without explaining it to them in a way they can understand.

>nspawn also offers faster startup time

Is Docker slow? Starting a container is usually instantaneous. Maybe the engine? For me it's managed with systemd and its weird socket binding, it's pretty fast too.. Fast is good but I can't remember thinking "wow docker is slow"

>better integration with cgroups and chroot jails

How? Why do I need this better integration?

- - -

I'm convinced there are not a lot of things Docker cannot do in comparison to systemd-nspawn. On the contrary, with systemd-nspawn:

- how do I spawn a container remotely?

- how do I share my "images"? is there an easy way to bundle the app I want to isolate? something at least kinda portable between Linuxes, so no .deb/.rpm

- can I include a file to my source code and tell my users something like "run docker build, then docker run and you're good to go"?

- my sysadmins just gave me the rights to run the docker command (we configured the user namespace so that I'm not indirectly root on the host), would it be that easy for them with nspawn?

- say I want a specific dependency, redis for example. Can I do something as simple as `docker run -p6379:6379 -v/data/redis:/data --name redis redis` or would I have to manually install the redis in the nspawn?