Service manager and container spawner is the same thing. So yes. The whole insight of systemd is that the cgroup tree can be used for service management. It wa

Service manager and container spawner is the same thing. So yes. The whole insight of systemd is that the cgroup tree can be used for service management. It was a container manager before container management was even a thing. (Including private mount namespaces, network namespaces, all that shebang) Systemd-nspawn contains no new code; just calls existing systemd library code. It gives people a familiar image based interface for a small cost in terms of lines of code. Bootloader i have a less strong argument for but at least it allows them to iterate in hopefully-standards-soon. Also systemd-boot is not an UEFI implementation. I'm not sure where you read that. It's an extremely small UEFI executable that lists a list of boot entries. (Note that an UEFI executable is just a Windows .EXE file). UEFI itself has more lines of code than the Linux kernel, replacing it would be insane (though very noble. See coreboot and Linuxboot projects). One argument is that it allows them to iterate on standards like the following: https://systemd.io/BOOT_LOADER_INTERFACE.html https://systemd.io/BOOT_LOADER_INTERFACE.html And https://systemd.io/BOOT_LOADER_SPECIFICATION.html https://systemd.io/BOOT_LOADER_SPECIFICATION.html And https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html