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
andconfigure
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?
- autorefresh stands in decently for
at-once
update strategy I guess; (edited)
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 export
ed 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(?).
Edit: short afterthoughts
There are package & store / depot features that are pretty similar, semver + revision (though habitat uses datetime where snap uses index); channels
Snap stores are (at least potentially) set up to host snap’s for purchase, whereas habitat, to my knowledge, is only looking to distribute gratis harts
Snappy is linux only, Habitat seeks to be cross platform
Habitat uses bash and powershell, snapcraft uses yaml