Poettering: Revisiting how we put together Linux systems

That remains to be seen, there is room in this scheme for a whole marketplace of different pre-baked /usr filesystems with as much or as little included, how popular those runtimes are can help determine where the sweet spot is. There will surely be many different runtimes for different workloads under this scheme, very minimal ones for embedded and maximal ones for desktops, which can be built using the same tools that distros use now for yum grouplists and such.

There are definitely a group of people though who have a visceral reaction against anything they are not actively using being on their system and feel unclean, they will be resistant to a generic /usr because of the amount of stuff that must go in it. I figure for a generic desktop you can afford to spend maybe 10G on system libraries and apps given that most desktops have at least a 128G SSD, which is enough for 2 maybe 3 maximal /usr filesystems, for a generic server maybe 1-2G is appropriate and one /usr, although for a Docker-like container server it may be appropriate to have 50G or more with dozens of /usr filesystems for each distro and server framework, much like AWS images.

> This whole thing doesn't solve any real problem, and that's not a surprise given that the underlying problem is basically unsolvable: you want bugfixes for the libraries, but no regressions or incompatibilities. Given that there's no way to tell them apart, you're hosed.

You are right in that it doesn't solve this problem, it sidesteps it entirely because the problem is practically unsolvable as you state. By having a standardized scheme for managing multiple /usr filesystems it lowers the friction and increases the integration of a mix-and-match system, compared to running each app in a VM with nested kernels and limited shared system state (no shared services like d-bus or x or wayland). Instead of picking one way or the other, do both, cut the gordian knot.