[derefr]

> but that actually asks your users for even more control of their systems

Or you can support one of the limited-capability package ecosystems, like Flatpak or Snap or AppImage. Then it's sort of like installing an app on your Android phone: the installed app (and its updates) only get to interact with the system through a customized sandbox that must first be described to, and accepted by, the user.

[simiones]

Sure, but there is plenty of software for which that doesn't make any sense, since the whole point is to interact with your system. ohmyzsh is a good example, as are most SDKs, as is plenty of specialty software.

[derefr]

SDKs are an interesting case — it wouldn't work to package them into a sandbox by default, but do look at how macOS treats XCode for an example of how something can be "sandboxed" but still reach out into the system by the system instead actually reaching into it. A thin layer of non-sandboxed system components on macOS "expect" XCode, and so work with it if it's available, to extract specific sandboxed data from the XCode sandbox and so "publish" it into being standalone software (rather than software that ends up also running inside the XCode sandbox.)

Essentially, an SDK in this sense would be a sandboxed plugin for a non-sandboxed system-level meta-SDK manager, that knows how to use these SDKs (in their sandboxes!) to compile and/or test-run things; where a test-run gets granted capabilities that the SDK-as-compiler does not itself possess, per a capabilities manifest fed in with the meta-SDK development project.

[AnIdiotOnTheNet]

AppImage is not "limited-capability" and has no sandbox mechanism at all without additional tools. An AppImage is the rough equivalent of a statically compiled binary.