The concept of a sandboxed app is to run non-unix philosophy monolithic "and the kitchen sink" applications that are not integrated with the system. In that wa

The concept of a sandboxed app is to run non-unix philosophy monolithic "and the kitchen sink" applications that are not integrated with the system. In that way there's not going to be much FLOSS interest. No one in FLOSS-land wants to admin a box with seven different statically linked SSL libraries all of different ages and different vulnerability exploits all relying on the app vendor as a single point of failure as the only source of non-FLOSS binary packages. FLOSS devs could "improve" the sandbox system by having the OS provide one patched up to date and secure SSL library for all applications to dynamically link to. Being FOSS this is not a legal problem and the OS vendor existing means one person on the planet has to be "in charge" of it and it'll just work for everyone. It doesn't work so well with commercial closed source non-FOSS vendors. Oh well. Sucks to be them. I don't miss them. Or, how does "does one thing and does one thing well and interoperates with all the other finely honed tools" FOSS philosophy match with a sandboxed app architecture? It seems the opposite, the purpose of the sandbox is to create a NIH monolithic app. If I wanted to run windows, I'd just run windows, not emulate its architecture on a unix-like system. It seems like a lot of work to turn linux into windows... why not just use windows and not mess up linux? The pool of FLOSS sandbox devs would be restricted to FLOSS devs who want to shoot FLOSS in the foot to make life easier for non-FLOSS devs and harder for everyone else, and disagree with core beliefs of FLOSS philosophy of design and architecture. Other than that lack of motivation, no problem.