I posted this as a slack post in the #iot channel but figured I’d post it here too for search-ability / different eyes. In my original version there were several links, but I am a new Discourse user, so it wouldn’t let me post with them - so I’ve inserted [1]-style numbers and the corresponding links are here: https://gist.github.com/donaldguy/40965bac2105929ad6097576ba80ffdf

Habitat vs (Ubuntu) Snappy

I haven't gotten tons of experience with either yet - but based on my doc skimming ( both Snapcraft docs[1] and Ubuntu Core docs[2]) and initial experiments heres a quick comparison, Let me know if you notice something I am saying is wrong.

`snapcraft` vs `hab build`:

more to explore, but the major weakness seems to be in the structuring of the dependency story:

you are largely expected to build a monolithic/"docker-style" file system image each time;

you can leverage the below, and

there is seemingly sugar for slurping in duplicates of whole apt trees from upstream "classic" ubuntu,

but its still much closer to "from scratch" each time than hab plans

there are plugins[3] (vaguely like scaffolding) for build dependencies (and interpreted language runtimes?)

there are parts[4] for runtime dependencies (e.g. dynamic libs, side cars, shellouts) but:

they are totally separate & distinct from snaps

they are maintained/published outside of normal stores (depots) here: https://wiki.ubuntu.com/snapcraft/parts

there are not that many available: I count 60 total and none or almost none maintained by upstream

I don't quite understand this bit, but they have a direct tie to plugins? its like you couldn't have a plan without a scaffold? - maybe the nil plugin makes this untrue

Builder

this brokering style and strict separation of dependencies from normal snaps seems to mean their version of builder[5] is necessarily much less compelling with non of the intelligent rebuilds that I've seen pitched in e.g. @reset 's ChefConf talk.

`snapd` vs `hab sub`

snapd takes on some similar responsibilities to hab sup but but it all seems to be just for single machines

snap set and configure hooks[6] do similar to some of hab sup's config loading and reconfigure hook (it seems like it could do something like hab's other hooks too but it doesn't yet)

the plugs/slots system, collectively "interfaces"[7] looks kinda like hab runtime bindings but also with file system mounts?

Runtime Sandboxing

The biggest difference perhaps though is that while classic and devmode confinement[8] settings can weaken it, snaps are always executed in a sandbox.

On the habitat side, though a hart can be pkg exported into one or another container format, the hab supervisor itself does not enforce any runtime sandboxing

Scope Differences

The runtime component of snapcraft is not as flexible, nor relevant apparently to distributed systems. A large part of the appeal of using habitat for IoT to me is that coworkers and I could have common tools and use common workflows between IoT devices on the one hand and (e.g. and specifically) kubernetes-hosted backend containers on the other.

Snappy does, unlike Habitat, aim to get all the way to the metal/manage the whole system via the kernel-snap[9]/loopback-mount + readonly file system.

(At my job, we probably are gonna manage that base layer via yocto & update it with mender.io[10], regardless of if we also add something like snap or hab as an app supervision and soft-update layer on top )

Ecosystem

snap & snapd's major advantage vs hab and hab sup for IoT use however is it that is written in Go and already shipping various flavors of arm binaries.

(I'd consider Rust's safety + runtime memory properties a mark in hab's favor if the cross-compilation story was already as good for Rust and the arm targetting studio was ready to go)

Canonical's Builder and Depot analogues ("stores"[11]) aren't open source at all, best as I can tell :disappointed: . There is one[12] alternative minimal snap store pointed to in docs but it does not appear to be what upstream uses at all, and doesn't support hosting parts at all, just full snaps(?).

This would reduce a hab pkg export snap to basically just generating a simply snap .yml using that plugin for the filesystem and setting up a command with daemon: true as a hab supervisor systemd unit and then invoke snapcraft cleanbuild or so.