Can someone summarize the difference between Mender and OSTree? I see that QtOTA chose OSTree as their underlying mechanism, which is significant in embedded automotive industry.
From my perspective as a curious observer of both projects, OSTree certainly looks attractive, because it doesn't waste space on two rootfs partitions which have to be oversized to accommodate future growth of the image. I initially thought OSTree required btrfs, because Project Atomic used btrfs the last time I looked at it. But according to the docs, while OSTree will take advantage of btrfs features if btrfs is being used, OSTree itself will work with a variety of filesystems including ext4.
Edit: An upside of the alternating rootfs partition approach is that the rootfs can be cryptographically verified at the block level. Chromium OS implemented this, and CoreOS also uses that implementation. This is probably outside the scope of Mender itself, but the updating approach used by Mender enables it.
Cryptographic signing and verification is in scope for Mender [0], and frankly it should be in scope for all updaters -- too many hacks have happened due to lack of codesigning.
Mender should be pretty immune to power failures in the middle of the updates -- even if second partition is only half-written , it is still not activated.
OSTree seems to rely on underlying filesystem to provide protection from power failures. This is, in my experience, is not a very reliable mechanism, especially when the SD cards are used. Thus, it is likely that if you have a device using OSTree updater and someone yanks the power cord at the bad time, your device may become unbootable.
block level signatures is not possible, which we feel is a requirement for an over-the-air updater
rollback is not built-in and can be quite challenging to implement reliably (bootloader level)
Think OSTree as more of a building block, like Git is for your development process. We might use it in the future but robustness and easy integration are our first priorities.
Signing an archive would probably be good enough for many cases. Block level is a bit simpler (all or nothing) and thus less risk of mixing with unsigned parts (sideloading attacks).
For security-sensitive embedded devices (e.g. payment terminals), block level signatures would allow hardware verification during boot as well (1st stage bootloader verifies 2nd stage, then kernel, etc.) if designed correctly.
And yes, we have chosen it because you don't have to waste twice as much disk space, and, more importantly (for wireless networks at least), you don't have to download the whole image.
