&gt; systemd is nothing like the OS X Core frameworks or like the Windows Runtime, it&#x27;s much lower level than that. It&#x27;s more of a middleware than a runtime platform<p>You&#x27;re not considering the full scope of the thing labelled &quot;systemd.&quot; If you only use parts of it, it&#x27;s middleware, yes. If you &quot;work with the grain&quot; of systemd, though, then you&#x27;re packaging services in nspawn containers and so forth, which <i>does</i> constitute a separate &quot;platform target&quot;, in the same way that e.g. CoreOS is a (mostly-ignored attempt at a) &quot;platform target.&quot;<p>Basically, I&#x27;m talking here about a Linux equivalent to Solaris&#x27;s &quot;Branded Zones&quot;: within a container boundary, an app can be made by the system to think it&#x27;s running on &quot;systemd Linux&quot;, or on &quot;POSIX Linux&quot;, or on &quot;Android Linux&quot;, or on BSD or Win32 or Cocoa or whatever else. Runtime-virtualization is done at the system container-management level (with more or less help from the kernel), rather than expecting applications to &quot;port&quot; themselves by applying their own proprietary virtualization wrappers ala Cider for OSX.<p>&gt; Not sure what &quot;first-class Wine support&quot; is supposed to mean. Wine is pretty self-contained.<p>I mean, basically, support to the level of DOS applications run in Win32 VMM containers, rather than to the level of X11 applications run on OSX: management of Wine sandboxes as OS-level &quot;runtime containers&quot;, such that you could run and <i>maintain</i> Wine apps alongside other apps, in production, using the OS&#x27;s maintenance tooling. A Linux &quot;ReactOS Runtime&quot; equivalent to Windows&#x27;s &quot;POSIX Runtime.&quot;<p>&gt; Nor is there any expressed interest from any Android vendor to have any serious GNU&#x2F;Linux convergence to begin with.<p>I don&#x27;t mean to suggest convergence. This is something very different: making &quot;running an Android binary&quot; a primitive action of <i>the system</i> (not the Linux kernel), where &quot;using an Android virtualization layer&quot; is then an <i>implementation detail</i> of how the system accomplishes this. Think of Linux&#x27;s binfmt_misc and its ability to execute e.g. JVM code by booting a JVM, but with an upcall to the init daemon to decide how to implement the policy of running a particular binary format. If that init daemon is effectively a container-manager that understands how to instantiate and manage different &quot;branded containers&quot; for each runtime it supports, Linux multi-runtime support just falls out.