The first two situations are handled in a clever way.
One of the interesting features talked about is deduplication support
for content within Snap packages. Snaps would be automatically
deduplicated of common files shared between snaps based upon their
file hashes. There would be de-duplication on the file-system layer,
de-duplication on snap downloads (with server support), and perhaps
de-duplication of mapped libraries from the linker. Deduplication is a
big work item and likely will take a while to implement fully, but
it's an interesting goal nevertheless.
Source: http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snappy-Deduplication
As for the third situation, they have something similar to the runtimes that you mentioned:
There are three layers that make up a snappy machine: the system
layer, provided by Canonical, a layer of frameworks that extend the
base system produced by vendors in collaboration with Canonical, and a
set of snappy applications, provided directly by vendors. Updating any
piece just means using the new version of a read-only image. Reverting
to a previous version is just as easy.
Source: http://www.ubuntu.com/cloud/snappy
There is no good documentation describing frameworks yet, primarily because they seem to still be working out the boundaries of what a framework is. Here is an excerpt from their mailing list that might help clarify things.
I am experimenting with Frameworks to essentially extend the Snappy
base system by software and services which lots of snaps require but
should not be included in any and each snap due to update issues and
size. The best example i have for this, is the openssl binary. Many
snaps need this to generate and validate keys and certificates.
The other issue i tied to solve with a framework is the access to
system wide resources, mote notably ports. Eg, a web server framework
would provide ways for other snapps to inject their web service api
and end points via reverse proxy into the framework running the web
server.
I was told on IRC that i am kind of abusing the framework concept, but
still these two issues come up on my desk often.
Source: https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000442.html
Yes, thanks to the stability of the Linux syscall interface, this is possible.
One of Linus Torvalds' great commitments to Linux users is that the set of interfaces offered by the kernel is stable. Many people don't appreciate the value of this, or how challenging it is as a leader of an open project to achieve that commitment. Consider for example how unpredictable changes in the GNOME APIs are by contrast! When you hear about Linus getting intense on a mailing list, it's almost always because some committer to the kernel decided to change such an interface 'because they had a better idea'. Linus says you can innovate wildly INSIDE the kernel, but please don't break the 'userspace' apps which depend on existing syscalls.
As a consequence of that stability it is possible for other kernels to offer the same syscalls, allowing apps built on Linux to run on those other kernels.
One example of that is the Joyent Triton project, which offer Linux-compatible syscalls in containers on SmartOS (a descendent of IllumOS, a descendent of Solaris).
A more widely known example is the new Linux subsystem in Windows.
Of course, how many of the syscalls are offered, and how bug-for-bug compatible they are, is the real question. At least for now, there is not another environment where all the necessary syscalls are in place, because the ones snaps use are relatively new and deep in the way the kernel thinks about the things it manages.
But they will certainnly come, in time, and I think snaps will thus be usable in a wide range of contexts.
Which is very cool, patches welcome :)
Best Answer
Unfortunately Snapcraft doesn't yet support cross-building. In order to build a snap for x86 it needs to be run on an x86 host; for arm, an arm host.
Indeed, as mentioned by didrocks, you can run Snapcraft directly on the Snappy device by using the Classic Dimension on Ubuntu Core 16.04.