Re: libOSTree and casync

[Sébastien Wilmet <swilmet gnome org>]

On Fri, Aug 04, 2017 at 09:21:15PM -0400, Colin Walters wrote:
> Broadly speaking, I think casync has some good ideas, but the degree of
> overlap with libostree today is extremely high.  We've already got a fully
> fleshed out C API, GPG signing, TLS pinning, a delta format, etc.
>
> For anyone using ostree today for its primary intended use case (shipping
> base OS updates), as well as e.g. flatpak; and has things correctly set up
> and managed, I don't see casync offering much.
>
> casync does seem to simplify administration in some ways; ostree has two formats (the archive
> and deltas).  System builders need to manage that.  But on the other hand,
> the ostree deltas are more flexible and powerful than casync's default model.
> For example, ostree deltas could easily be extended later to use
> Courgette https://www.chromium.org/developers/design-documents/software-updates-courgette
> or similar.
>
> The bsdiff we use today (and admittedly this is where benchmarks would
> be interesting) likely compress a lot more than what casync does.  But
> they are also more CPU and RAM intensive on the client.
>
> On the other hand, related to administration: AIUI casync doesn't implement garbage collection today.
> That's likely to be quite problematic for nontrivial use.  And based on what
> I understand of the design, the way chunks get spread out makes this hard.
> ostree has GC, and one of the nice things is that it's symmetric across
> the client and server side.  On the client side, we can store multiple trees,
> dedup across them, but still perofrm GC.
>
> The other area of overlap with casync particularly for *host* system updates
> is that libostree has lots of logic today around e.g. handling /etc, backends
> for different bootloaders, etc.

OK, thanks for the explanations.

--
Sébastien