Ubuntu – Is snap portable across other UNIX (example macOS)

macosxpackage-managementsnap

I love the idea behind snap and played with it on a Ubuntu VM.

Snapcraft Overview

Snapcraft is a build and packaging tool which helps you package your
software as a snap. It makes it easy to incorporate components from
different sources and build technologies or solutions. Key concepts

A .snap package for the Ubuntu Core system contains all its
dependencies. This has a couple of advantages over traditional deb or
rpm based dependency handling, the most important being that a
developer can always be assured that there are no regressions
triggered by changes to the system underneath their app.

Snapcraft makes bundling these dependencies easy by allowing you to
specify them as "parts" in the snapcraft.yaml file. Snappy

Snappy Ubuntu Core is a new rendition of Ubuntu with transactional
updates – a minimal server image with the same libraries as today's
Ubuntu, but applications are provided through a simpler mechanism.

Snappy apps and Ubuntu Core itself can be upgraded atomically and
rolled back if needed. Apps are also strictly confined and sandboxed
to safeguard your data and system.

IoT ›Build apps

On what technologies is snap based? How do the architecture and toolkits look? Does snap depend on Linux kernel features?

I ask, because I'm wondering whether in the future I'll be able to use the same snap packages also on macOS?

Clarification, after first comment:

I know that macOS and Ubuntu are not binary compatible. A recompile is needed. There is almost any Open Source available already for macOS with Homebrew. The developer could develop on macOS and deploy on Ubuntu when snap will be (in future) available for macOS.

Best Answer

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 :)

Related Question