13

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.

Improve this question
3
  • 1
    Even if no kernel features were involved, I wouldn't expect any non-trivial application, even statically compiled, to run without re-compiling on macOS and Linux - the executable formats are different, the ABIs would be different for the underlying POSIX system calls would be different, and especially for applications going above and beyond POSIX, equivalent system calls be different. Those are not barriers I think any packaging can overcome. Otherwise projects like Wine and Darling would have succeeded long ago.
    – muru
    Jun 25, 2016 at 19:23
  • So do you want to install snaps on macOS or create snaps on macOS? Your question initially looked like the former, and now it looks like the latter.
    – muru
    Jun 25, 2016 at 19:32
  • At any rate, since snaps still haven't been completely ported to other Linux distros, I'd expect any action on macOS to be a pipe dream.
    – muru
    Jun 25, 2016 at 19:41

3 Answers 3

Reset to default
22

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

Improve this answer
11

While I can't find any information about macOS, this OMG! Ubuntu article has an interesting quote from Mark Shuttleworth:

As for running Snaps on Windows 10? “It’s absolutely plausible” Shuttleworth said.

“Snaps are using modern features in the Linux kernel to do security confinement, set up file system access, etc, and all of that involves using modern mechanisms in the kernel. And Canonical lead a lot of [this work]. It’ll take a while for Microsoft to [get to hook in to it].”

If it's "plausible" to get it running in Windows, I'd say the same for macOS, except that Microsoft seems to be cooperating with Canonical, which is not something I have heard about Apple doing.

The documentation on Snap security policy and sandboxing and the Arch Wiki entry on snapd are informative:

From the Arch Wiki:

Note that snap-confine is built with the --disable-confinement option; full confinement relies on an AppArmor enabled kernel and related profile for the snap.

From the policy:

Under the hood, the launcher:

  • Sets up various environment variables: […]
  • When hardware is assigned to the snap, sets up a device cgroup with default devices (eg, /dev/null, /dev/urandom, etc) and any devices that are assigned to this snap
  • Sets up a private /tmp using a per-command private mount namespace and mounting a per-command directory on /tmp
  • Sets up a per-command devpts new instance
  • Sets up the seccomp filter for the command
  • Executes the command under the command-specific AppArmor profile under a default nice value

This combination of restrictive AppArmor profiles (which mediate file access, application execution, Linux capabilities(7), mount, ptrace, IPC, signals, coarse-grained networking), clearly defined application-specific filesystem areas, whitelist syscall filtering via seccomp, private /tmp, new instance devpts and device cgroups provides for strong application confinement and isolation.

While AppArmor and seccomp are Linux only, it looks like confinement can be made optional, so we can ignore that. Then there's usage of devpts, cgroups and mount namespaces. If there's any blocking, I think it would be for those. I'm not familiar enough with the BSDs to say what the equivalents are.

The snapd application itself is written in Go, which should make it reasonably cross-platform. Indeed, some files have very interesting build targets:

osutil/group_other.go:

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build !linux,!darwin,!freebsd

osutil/group_linux.go:

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build darwin freebsd linux
// +build cgo

So it looks like someone has an interest in this.

Improve this answer
1

As of today, snap can be installed on MacOS but cannot be used.

$ brew install snap
$ snap install ./some-app.snap --devmode
Interacting with snapd is not yet supported on darwin.
This command has been left available for documentation purposes only.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .