This is quite a long list...

dpkg and rpm

See dpkg and rpm. These are probably the most widely deployed tools for building and deploying Linux-based systems. OSTree is designed to complement them, and make up for their weaknesses. For example, neither of these have support for multiple roots or atomic upgrades. They have fairly weak stories for configuration management in /etc out of the box. OSTree provides these and more.

BTRFS

See Btrfs.

First of all, the OSTree author believes that Linux storage is a wide world, and while BTRFS is quite good, it is not everywhere now, nor will it be in the near future. There are other recently developed filesystems like f2fs, and Red Hat Enterprise Linux still defaults to xfs.

Even when using BTRFS, it is not a magic bullet, but yes - it helps significantly. The obvious thing to do is layer BTRFS under dpkg/rpm, and have a separate subvolume for /home so rollbacks don't lose your data. See e.g. http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs.

More generally, if you want to use BTRFS to roll back changes made by dpkg/rpm, you have to carefully set up the partition layout so that the files laid out by dpkg/rpm are installed in a subvolume to snapshot.

This problem in many ways is addressed by the changes OSTree forces, such as putting all local state in /var (e.g. /usr/local -> /var/usrlocal). Then one can BTRFS snapshot /usr. This gets pretty far, except handling /etc is messy. This is something OSTree does well.

In general, if one really tries to flesh out the BTRFS approach, a nontrivial middle layer of code between dpkg/rpm and BTRFS (or deep awareness of BTRFS in dpkg/rpm itself) will be required.

The OSTree author believes that having total freedom at the block storage layer is better for general purpose operating systems. For example, with OSTree, one is free to use BTRFS in any way you like - you can use a subvolume for /home, or you can not.

Furthermore, in its most basic incarnation, the rpm/dpkg + BTRFS doesn't solve the race conditions that happen when unpacking packages into the live system, such as deleting the files underneath Firefox while it's running. One could unpack packages into a separate root, and switch to that, which gets closer to the OSTree architecture.

Note though OSTree does take advantage of BTRFS if installed on top of it! In particular, we use reflink for the copies of /etc.

Google ChromeOS autoupdate

See http://www.chromium.org/chromium-os/chromiumos-design-docs/autoupdate-details . This is extremely efficient for upgrades, and is very safe. It even would allow switching filesystems, since it operates at the block layer. However, it doubles the OS size; the OSTree model only requires space proportional to the size of updates. Further, OSTree allows for efficient branching - for example, it's easy for a developer or system administrator to create new local snapshots, and a user or developer could easily have 50 or more OS snapshots locally, and bisect across those.

Ubuntu Image Based Updates

See https://wiki.ubuntu.com/ImageBasedUpgrades. Very architecturally similar to ChromeOS, although more interesting is discussion for supporting package installation on top.

NixOS

See NixOS. It was a very influential project for OSTree. A comparison of object stores is in Projects/OSTree/NixOSComparison.

OLPC update

I would describe OSTree as a generalization of olpc-update. OSTree has the notion of separate trees that one can track independently or parallel install, while still sharing storage via the hardlinked repository, whereas olpc-update uses version numbers for a single OS.

OSTree has built-in plain old HTTP replication which can be served from a static webserver, whereas olpc-update uses rsync (more server load, but more efficient on the network side). The OSTree author plans to address network bandwidth consumption via static deltas.

See this comment for a comparison.

Solaris IPS

See Solaris IPS. Broadly, this is a similar design as to a combination of BTRFS+RPM/deb. ZFS is a nonstarter for Linux.

schroot

See schroot. This is attempting to use a "live" chroot, with the downside that you can't e.g. sanely run gdm from inside it.

Gentoo prefix

See Gentoo Prefix. Needs comparison analysis.

Conary

See Conary Updates and Rollbacks. If rpm/dpkg are like CVS, Conary is closer to Subversion. It's not bad, but ostree is better than it for the exact same reasons git is better than Subversion.

bmap

A tool for optimized copying of disk images. Intended for offline use, so not directly comparable.

https://source.tizen.org/documentation/reference/bmaptool/introduction

Razor

https://github.com/krh/razor. A faster rpm, but our real problem isn't speed.

Mirage

See Mirage. Has some hybrid image/filesystem features. At a first glance, this system is only capable of totally offline upgrades, whereas OSTree is capable of that and upgrading running systems.

CernVM file system

See CernVM. Basically I think this is an "application" mechanism. You can't boot off of it; that makes it fundamentally different from OSTree. Like many "application" mechanisms such as Docker, it may (or may not) make sense layered on top of an OSTree-based system.