Poettering: Revisiting how we put together Linux systems

Posted Sep 2, 2014 11:13 UTC (Tue) by helge.bahmann (subscriber, #56804)
Parent article: Poettering: Revisiting how we put together Linux systems

And how will integration work out? You download something in chrome which is inside its compartment, and expect "show download folder" to delegate to the system file viewer, or launch the "correct" libreoffice instance (out of the possible multiple ones if different compartments)? Interface to print dialogue/network manager/desktop notification mechanism?

Standardizing containers for runtimes to catch odd-ball applications is one thing, declaring it the primary paradigm for application distribution is another thing. There is not even consideration of integration (which is the really hard problem), only about isolation (which is the trivial problem).

Poettering: Revisiting how we put together Linux systems

Posted Sep 2, 2014 18:48 UTC (Tue) by mezcalero (subscriber, #45103) [Link] (2 responses)

Well, there are two options for the sandboxing apps: grant full access to specific dirs in $HOME, or do so only indirectly via "portals", where an app simply invokes some bus call to generically tell the system that something is supposed to be done, and the system then figures out a way to do it, with involving the user, so that the apps can't do bad stuff...

Chrome in your example would probably get fully access to the XDG userdir download directory. It would be mounted into the app's sandbox to the exact same place it appears at externally, so chrome wouldn't have to care...

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 23:32 UTC (Wed) by nix (subscriber, #2304) [Link]

Of course, the problem with Chrome is less its userdir and more its hundreds of megabytes of version-dependent, non-downgradeable configuration state. (But then, this proposal isn't about version migration, only dependency management -- one assumes that all the Chromes you were choosing between would be the same version and would in some way conflict with all later versions, such that installing even one later container upgrades all the others... which is suddenly looking very like a package manager again.)

Poettering: Revisiting how we put together Linux systems

Posted Sep 7, 2014 18:19 UTC (Sun) by helge.bahmann (subscriber, #56804) [Link]

The problem is less about sharing of storage, but sharing of behavior that is in turn dependent on common code -- see the example about maintaining a consistent print dialog throughout the system: Full sandboxing makes this problem even worse, and nothing in the proposal even acknowledges this (lest hint at an intended direction for a solution).