The parent is advocating for the Slackware approach—just take whatever&#x27;s in the upstreams and slam it together—but installed into a container (so all that slamming doesn&#x27;t <i>conflict</i> with anything), and distributed as a container image. This is effectively the &#x27;modern Linux app philosophy&#x27;, as supported by systemd et al. It&#x27;s similar in concept to app bundles, but it also assumes automatic sandboxing.<p>It&#x27;s great for <i>games</i> in particular, given that you&#x27;ll be able to boot up a 10-year-old game container-image as if it were new. (In that way, it&#x27;s like game emulation, but without the performance drawbacks.) Most other &quot;app&quot; software gets lesser-but-still-significant benefits, in much the same way you see on e.g. the Mac App Store with their self-sandboxing apps.<p>There&#x27;s little advantage in distributing <i>system</i> software this way, given that system software is usually full of low-level extension-points that other system software plugs into to achieve the purpose. And this is what can make a <i>platform abstraction layer</i> like Android make sense. With a platform, the system software is all composed together by the platform maker into an underlayer, and a single, clean API is specified atop it. Above the platform abstraction, there doesn&#x27;t need to be any exposed runtime model for system software—since it&#x27;s all been encapsulated into the black box of the underlayer. The platform only needs to specify a model for developing+running+distributing app software.<p>Sometimes things straddle the boundary, though. There are numerous cases of software that has &quot;failed out&quot; of the Mac App Store after a while, because the software is fundamentally a system-software&#x2F;app-software hybrid, and sandboxing the system-software aspects just didn&#x27;t work.