<i>instead, it&#x27;s a particular runtime that will increasingly differentiate itself from POSIX Linux</i><p>Ah, correct.<p><i>I believe that that friction will eventually cause developers to want to create an init daemon with branded zones to supercede systemd, where emulating systemd-as-it-stands (for apps built to expect it) would be one of that multi-runtime system&#x27;s goals. With the POSIX people and the bigcorp Linux providers pulling in opposite directions, a multi-runtime Linux would be the only Nash equilibrium. (Though it&#x27;d need someone like FreeDesktop to suggest it and start a working group for it, because neither &quot;side&quot; would care about it on their own.)</i><p>It&#x27;s a hypothesis, then. Plausible, certainly. I assume you&#x27;re presenting this as a probable way out of the portability concerns from GNU&#x2F;Linux becoming more of a closed environment to the point of instigating a massive developer schism? This still raises the question of why it would need to reside in the init daemon, but I suppose crass architectural decisions are not a stranger to Linux developers.<p><i>For example: imagine that systemd decides to integrate deeply with GNOME, to the point that you now have an integrated &quot;systemd+glib+GNOME platform&quot; with a unified API</i><p>Such a decision might just backfire quite tremendously and prove to be systemd&#x27;s overturning, though it does sound like a similar integration is very much in the spirit of the project. Then, yes, radical surgery would occur, but it may not be quite as dramatic as branded zones and simply an abandonment of systemd and related Freedesktop-ware.<p><i>RedHat and Debian to agree</i><p>Debian aren&#x27;t really that large of a player, more of a passive target platform. Being a non-affiliated foundation, they&#x27;re generally steered into things by whoever is on the committee and seldom ever lead themselves. So, no agreement strictly necessary.