Well can't speak to the horror of the design as I'm not a really proponent of that particular design. Just clarifying the parent's statement a little. Though the rancheros design is not particularly worse than what systemd does now, based on my recent experiences. It's all one giant (poorly?) implemented binary either way. From a pragmatic standpoint I don't see a difference. What's the difference between one opaque binary vs another, except possibly one's written in Go which I find easier to read if needed and is less likely to have buffer overruns. Really cutting out one crapshoot seems logical as at least there's only one system you'd need to learn. Still I'd like a non-either of those options approach.
Personally I prefer running SmartOS and Triton containers. Their system seem much more stable than any of the Linux containers and/or systemd setups I've tried. It sticks a bit more to traditional unix design which makes sense to me. Items like the caching layer for containers build on ZFS snapshots, a well tested file system layer, rather than ad hoc userland tools. Triton also runs all of the orchestration layers in separate zones (containers) like RancherOS is trying to build. But each component is a simple(ish) service, it's easy to `zfs list` and check on a container's file system or fix it or backup, etc. Same with SVC or VM machine management which both have small simple tools that do one thing pretty well.
To that note, docker has been moving towards breaking out and using smaller daemons haven't they? If that continues it might turn out more modular in the end wherein RancherOS would end up being more modular than systemd Linux setups. Imho, that'd be great.
