shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2025-03-16 10:50:43 +03:00
Code Issues Projects Releases Wiki Activity
ostree/related-projects/index.html

771 lines
37 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html lang="en-US">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=Edge">
<link rel="stylesheet" href="/ostree/assets/css/just-the-docs-default.css">
<script src="/ostree/assets/js/vendor/lunr.min.js"></script>
<script src="/ostree/assets/js/just-the-docs.js"></script>
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Begin Jekyll SEO tag v2.8.0 -->
<title>Related Projects | ostreedev/ostree</title>
<meta name="generator" content="Jekyll v3.9.5" />
<meta property="og:title" content="Related Projects" />
<meta property="og:locale" content="en_US" />
<meta name="description" content="ostree documentation" />
<meta property="og:description" content="ostree documentation" />
<link rel="canonical" href="https://ostreedev.github.io/ostree/related-projects/" />
<meta property="og:url" content="https://ostreedev.github.io/ostree/related-projects/" />
<meta property="og:site_name" content="ostreedev/ostree" />
<meta property="og:type" content="website" />
<meta name="twitter:card" content="summary" />
<meta property="twitter:title" content="Related Projects" />
<script type="application/ld+json">
{"@context":"https://schema.org","@type":"WebPage","description":"ostree documentation","headline":"Related Projects","url":"https://ostreedev.github.io/ostree/related-projects/"}</script>
<!-- End Jekyll SEO tag -->
</head>
<body>
<a class="skip-to-main" href="#main-content">Skip to main content</a>
<svg xmlns="http://www.w3.org/2000/svg" class="d-none">
<symbol id="svg-link" viewBox="0 0 24 24">
<title>Link</title>
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-link">
<path d="M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71"></path><path d="M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71"></path>
</svg>
</symbol>
<symbol id="svg-menu" viewBox="0 0 24 24">
<title>Menu</title>
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-menu">
<line x1="3" y1="12" x2="21" y2="12"></line><line x1="3" y1="6" x2="21" y2="6"></line><line x1="3" y1="18" x2="21" y2="18"></line>
</svg>
</symbol>
<symbol id="svg-arrow-right" viewBox="0 0 24 24">
<title>Expand</title>
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-chevron-right">
<polyline points="9 18 15 12 9 6"></polyline>
</svg>
</symbol>
<!-- Feather. MIT License: https://github.com/feathericons/feather/blob/master/LICENSE -->
<symbol id="svg-external-link" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-external-link">
<title id="svg-external-link-title">(external link)</title>
<path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"></path><polyline points="15 3 21 3 21 9"></polyline><line x1="10" y1="14" x2="21" y2="3"></line>
</symbol>
<symbol id="svg-doc" viewBox="0 0 24 24">
<title>Document</title>
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-file">
<path d="M13 2H6a2 2 0 0 0-2 2v16a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2V9z"></path><polyline points="13 2 13 9 20 9"></polyline>
</svg>
</symbol>
<symbol id="svg-search" viewBox="0 0 24 24">
<title>Search</title>
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-search">
<circle cx="11" cy="11" r="8"></circle><line x1="21" y1="21" x2="16.65" y2="16.65"></line>
</svg>
</symbol>
<!-- Bootstrap Icons. MIT License: https://github.com/twbs/icons/blob/main/LICENSE.md -->
<symbol id="svg-copy" viewBox="0 0 16 16">
<title>Copy</title>
<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-clipboard" viewBox="0 0 16 16">
<path d="M4 1.5H3a2 2 0 0 0-2 2V14a2 2 0 0 0 2 2h10a2 2 0 0 0 2-2V3.5a2 2 0 0 0-2-2h-1v1h1a1 1 0 0 1 1 1V14a1 1 0 0 1-1 1H3a1 1 0 0 1-1-1V3.5a1 1 0 0 1 1-1h1v-1z"/>
<path d="M9.5 1a.5.5 0 0 1 .5.5v1a.5.5 0 0 1-.5.5h-3a.5.5 0 0 1-.5-.5v-1a.5.5 0 0 1 .5-.5h3zm-3-1A1.5 1.5 0 0 0 5 1.5v1A1.5 1.5 0 0 0 6.5 4h3A1.5 1.5 0 0 0 11 2.5v-1A1.5 1.5 0 0 0 9.5 0h-3z"/>
</svg>
</symbol>
<symbol id="svg-copied" viewBox="0 0 16 16">
<title>Copied</title>
<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-clipboard-check-fill" viewBox="0 0 16 16">
<path d="M6.5 0A1.5 1.5 0 0 0 5 1.5v1A1.5 1.5 0 0 0 6.5 4h3A1.5 1.5 0 0 0 11 2.5v-1A1.5 1.5 0 0 0 9.5 0h-3Zm3 1a.5.5 0 0 1 .5.5v1a.5.5 0 0 1-.5.5h-3a.5.5 0 0 1-.5-.5v-1a.5.5 0 0 1 .5-.5h3Z"/>
<path d="M4 1.5H3a2 2 0 0 0-2 2V14a2 2 0 0 0 2 2h10a2 2 0 0 0 2-2V3.5a2 2 0 0 0-2-2h-1v1A2.5 2.5 0 0 1 9.5 5h-3A2.5 2.5 0 0 1 4 2.5v-1Zm6.854 7.354-3 3a.5.5 0 0 1-.708 0l-1.5-1.5a.5.5 0 0 1 .708-.708L7.5 10.793l2.646-2.647a.5.5 0 0 1 .708.708Z"/>
</svg>
</symbol>
</svg>
<div class="side-bar">
<div class="site-header">
<a href="/ostree/" class="site-title lh-tight">
ostreedev/ostree
</a>
<a href="#" id="menu-button" class="site-button">
<svg viewBox="0 0 24 24" class="icon"><use xlink:href="#svg-menu"></use></svg>
</a>
</div>
<nav aria-label="Main" id="site-nav" class="site-nav">
<ul class="nav-list"><li class="nav-list-item"><a href="/ostree/" class="nav-list-link">libostree</a></li><li class="nav-list-item"><a href="/ostree/introduction/" class="nav-list-link">OSTree Overview</a></li><li class="nav-list-item"><a href="/ostree/repo/" class="nav-list-link">Anatomy of an OSTree repository</a></li><li class="nav-list-item"><a href="/ostree/deployment/" class="nav-list-link">Deployments</a></li><li class="nav-list-item"><a href="/ostree/atomic-upgrades/" class="nav-list-link">Atomic Upgrades</a></li><li class="nav-list-item"><a href="/ostree/atomic-rollbacks/" class="nav-list-link">Atomic Rollbacks</a></li><li class="nav-list-item"><a href="/ostree/adapting-existing/" class="nav-list-link">Adapting existing mainstream distributions</a></li><li class="nav-list-item"><a href="/ostree/var/" class="nav-list-link">OSTree and /var handling</a></li><li class="nav-list-item"><a href="/ostree/formats/" class="nav-list-link">OSTree data formats</a></li><li class="nav-list-item"><a href="/ostree/buildsystem-and-repos/" class="nav-list-link">Writing a buildsystem and managing repositories</a></li><li class="nav-list-item"><a href="/ostree/authenticated-repos/" class="nav-list-link">Handling access to authenticated remote repositories</a></li><li class="nav-list-item"><a href="/ostree/repository-management/" class="nav-list-link">Managing content in OSTree repositories</a></li><li class="nav-list-item"><a href="/ostree/copying-deltas/" class="nav-list-link">Static deltas for offline updates</a></li><li class="nav-list-item"><a href="/ostree/ima/" class="nav-list-link">Using Linux IMA with OSTree</a></li><li class="nav-list-item active"><a href="/ostree/related-projects/" class="nav-list-link active">Related Projects</a></li><li class="nav-list-item"><a href="/ostree/composefs/" class="nav-list-link">Using composefs with OSTree</a></li><li class="nav-list-item"><a href="/ostree/bootloaders/" class="nav-list-link">Bootloaders</a></li><li class="nav-list-item"><a href="/ostree/CONTRIBUTING/" class="nav-list-link">Contributing</a></li><li class="nav-list-item"><a href="/ostree/contributing-tutorial/" class="nav-list-link">OSTree Contributing Tutorial</a></li><li class="nav-list-item"><a href="/ostree/README-historical/" class="nav-list-link">Historical OSTree README</a></li></ul>
</nav>
<footer class="site-footer">
This site uses <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, a documentation theme for Jekyll.
</footer>
</div>
<div class="main" id="top">
<div id="main-header" class="main-header">
<div class="search">
<div class="search-input-wrap">
<input type="text" id="search-input" class="search-input" tabindex="0" placeholder="Search ostreedev/ostree" aria-label="Search ostreedev/ostree" autocomplete="off">
<label for="search-input" class="search-label"><svg viewBox="0 0 24 24" class="search-icon"><use xlink:href="#svg-search"></use></svg></label>
</div>
<div id="search-results" class="search-results"></div>
</div>
<nav aria-label="Auxiliary" class="aux-nav">
<ul class="aux-nav-list">
<li class="aux-nav-list-item">
<a href="https://github.com/ostreedev/ostree" class="site-button"
>
OSTree on GitHub
</a>
</li>
</ul>
</nav>
</div>
<div id="main-content-wrap" class="main-content-wrap">
<div id="main-content" class="main-content" role="main">
<h1 class="no_toc" id="related-projects">
<a href="#related-projects" class="anchor-heading" aria-labelledby="related-projects"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Related Projects
</h1>
<ol id="markdown-toc">
<li><a href="#combining-dpkgrpm--btrfslvm" id="markdown-toc-combining-dpkgrpm--btrfslvm">Combining dpkg/rpm + (BTRFS/LVM)</a></li>
<li><a href="#chromiumos-updater" id="markdown-toc-chromiumos-updater">ChromiumOS updater</a></li>
<li><a href="#ubuntu-image-based-updates" id="markdown-toc-ubuntu-image-based-updates">Ubuntu Image Based Updates</a></li>
<li><a href="#clear-linux-software-update" id="markdown-toc-clear-linux-software-update">Clear Linux Software update</a></li>
<li><a href="#casync" id="markdown-toc-casync">casync</a></li>
<li><a href="#menderio" id="markdown-toc-menderio">Mender.io</a></li>
<li><a href="#olpc-update" id="markdown-toc-olpc-update">OLPC update</a></li>
<li><a href="#nixos--nix" id="markdown-toc-nixos--nix">NixOS / Nix</a></li>
<li><a href="#solaris-ips" id="markdown-toc-solaris-ips">Solaris IPS</a></li>
<li><a href="#google-servers-custom-rsync-like-approach-live-updates" id="markdown-toc-google-servers-custom-rsync-like-approach-live-updates">Google servers (custom rsync-like approach, live updates)</a></li>
<li><a href="#conary" id="markdown-toc-conary">Conary</a></li>
<li><a href="#bmap" id="markdown-toc-bmap">bmap</a></li>
<li><a href="#git" id="markdown-toc-git">Git</a></li>
<li><a href="#conda" id="markdown-toc-conda">Conda</a></li>
<li><a href="#rpm-ostree" id="markdown-toc-rpm-ostree">rpm-ostree</a></li>
<li><a href="#gnome-continuous" id="markdown-toc-gnome-continuous">GNOME Continuous</a></li>
<li><a href="#docker" id="markdown-toc-docker">Docker</a></li>
<li><a href="#docker-related-balena" id="markdown-toc-docker-related-balena">Docker-related: Balena</a></li>
<li><a href="#torizon-platform" id="markdown-toc-torizon-platform">Torizon Platform</a> <ol>
<li><a href="#torizon-os" id="markdown-toc-torizon-os">Torizon OS</a></li>
<li><a href="#torizoncore-builder" id="markdown-toc-torizoncore-builder">TorizonCore Builder</a></li>
<li><a href="#torizon-cloud" id="markdown-toc-torizon-cloud">Torizon Cloud</a></li>
</ol>
</li>
</ol>
<!-- SPDX-License-Identifier: (CC-BY-SA-3.0 OR GFDL-1.3-or-later) -->
<p>OSTree is in many ways very evolutionary. It builds on concepts and
ideas introduced from many different projects such as
<a href="http://0pointer.net/blog/projects/stateless.html">Systemd Stateless</a>,
<a href="https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/">Systemd Bootloader Spec</a>,
<a href="http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate">Chromium Autoupdate</a>,
the much older
<a href="https://fedoraproject.org/wiki/StatelessLinux">Fedora/Red Hat Stateless Project</a>,
<a href="http://linux-vserver.org/index.php?title=util-vserver:Vhashify&amp;oldid=2285">Linux VServer</a>
and many more.</p>
<p>As mentioned elsewhere, OSTree is strongly influenced by package
manager designs as well. This page is not intended to be an
exhaustive list of such projects, but we will try to keep it up to
date, and relatively agnostic.</p>
<p>Broadly speaking, projects in this area fall into two camps; either
a tool to snapshot systems on the client side (dpkg/rpm + BTRFS/LVM),
or a tool to compose on a server and replicate (ChromiumOS, Clear
Linux). OSTree is flexible enough to do both.</p>
<p>Note that this section of the documentation is almost entirely
focused on the “ostree for host” model; the <a href="https://github.com/flatpak/flatpak/">flatpak</a>
project uses libostree to store application data, distinct from the
host system management model.</p>
<h2 id="combining-dpkgrpm--btrfslvm">
<a href="#combining-dpkgrpm--btrfslvm" class="anchor-heading" aria-labelledby="combining-dpkgrpm--btrfslvm"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Combining dpkg/rpm + (BTRFS/LVM)
</h2>
<p>In this approach, one uses a block/filesystem snapshot tool underneath
the system package manager.</p>
<p>The
<a href="https://gerrit.ovirt.org/gitweb?p=imgbased.git">oVirt Node imgbased</a>
tool is an example of this approach, as are a few others below.</p>
<p>Regarding <a href="https://btrfs.wiki.kernel.org/index.php/Main_Page">BTRFS</a>
in particular - 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 <a href="https://en.wikipedia.org/wiki/F2FS">f2fs</a>, and Red
Hat Enterprise Linux still defaults to
<a href="https://en.wikipedia.org/wiki/XFS">XFS</a>.</p>
<p>Using a snapshot tool underneath a package manager does help
significantly. In the rest of this text, we will use “BTRFS” as a
mostly generic tool for filesystem snapshots.</p>
<p>The obvious thing to do is layer BTRFS under dpkg/rpm, and have a
separate subvolume for <code class="language-plaintext highlighter-rouge">/home</code> so rollbacks don’t lose your data. See
e.g. <a href="http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs">Fedora BTRFS Rollback Feature</a>.</p>
<p>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.</p>
<p>This problem in many ways is addressed by the changes OSTree forces,
such as putting all local state in <code class="language-plaintext highlighter-rouge">/var</code> (e.g. <code class="language-plaintext highlighter-rouge">/usr/local</code> -&gt;
<code class="language-plaintext highlighter-rouge">/var/usrlocal</code>). Then one can BTRFS snapshot <code class="language-plaintext highlighter-rouge">/usr</code>. This gets pretty
far, except handling <code class="language-plaintext highlighter-rouge">/etc</code> is messy. This is something OSTree does
well.</p>
<p>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. A good
example of this is the <a href="http://snapper.io/">snapper.io</a> project.</p>
<p>The OSTree author believes that having total freedom at the block
storage layer is better for general purpose operating systems. For
example, the ability to choose dm-crypt per deployment is quite useful;
not every site wants to pay the performance penalty. One can choose
LVM or not, etc.</p>
<p>Where applicable, OSTree does take advantage of copy-on-write/reflink
features offered by the kernel for <code class="language-plaintext highlighter-rouge">/etc</code>. It uses the now generic
<code class="language-plaintext highlighter-rouge">ioctl(FICLONE)</code> and <code class="language-plaintext highlighter-rouge">copy_file_range()</code>.</p>
<p>Another major distinction between the default OSTree usage and package managers
is whether updates are “online” or “offline” by default. The default OSTree
design writes updates into a new root, leaving the running system unchanged.
This means preparing updates is completely non-disruptive and safe - if the
system runs out of disk space in the middle, it’s easy to recover. However,
there is work in the <a href="https://github.com/projectatomic/rpm-ostree/">rpm-ostree</a>
project to support online updates as well.</p>
<p>OSTree supports using “bare-user” repositories, which do not require
root to use. Using a filesystem-level layer without root is more
difficult and would likely require a setuid helper or privileged service.</p>
<p>Finally, see the next portion around ChromiumOS for why a hybrid but
integrated package/image system improves on this.</p>
<h2 id="chromiumos-updater">
<a href="#chromiumos-updater" class="anchor-heading" aria-labelledby="chromiumos-updater"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> ChromiumOS updater
</h2>
<p>Many people who look at OSTree are most interested in using
it as an updater for embedded or fixed-purpose systems, similar to use cases
from the <a href="http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate">ChromiumOS updater</a>.</p>
<p>The ChromiumOS approach uses two partitions that are swapped via the
bootloader. It has a very network-efficient update protocol, using a
custom binary delta scheme between filesystem snapshots.</p>
<p>This model even allows for switching filesystem types in an update.</p>
<p>A major downside of this approach is that the OS size is doubled on
disk always. In contrast, OSTree uses plain Unix hardlinks, which
means it essentially only requires disk space proportional to the
changed files, plus some small fixed overhead.</p>
<p>This means with OSTree, one can easily have more than two trees
(deployments). Another example is that the system OSTree repository
could <em>also</em> be used for application containers.</p>
<p>Finally, the author of OSTree believes that what one really wants for
many cases is image replication <em>with</em> the ability to layer on some
additional components (e.g. packages) - a hybrid model. This is what
<a href="https://github.com/projectatomic/rpm-ostree/">rpm-ostree</a> is aiming
to support.</p>
<h2 id="ubuntu-image-based-updates">
<a href="#ubuntu-image-based-updates" class="anchor-heading" aria-labelledby="ubuntu-image-based-updates"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Ubuntu Image Based Updates
</h2>
<p>See <a href="https://wiki.ubuntu.com/ImageBasedUpgrades">https://wiki.ubuntu.com/ImageBasedUpgrades</a>. Very architecturally
similar to ChromeOS, although more interesting is discussion for
supporting package installation on top, similar to
<a href="https://github.com/projectatomic/rpm-ostree/pull/107">rpm-ostree package layering</a>.</p>
<h2 id="clear-linux-software-update">
<a href="#clear-linux-software-update" class="anchor-heading" aria-labelledby="clear-linux-software-update"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Clear Linux Software update
</h2>
<p>The
<a href="https://clearlinux.org/features/software-update">Clear Linux Software update</a>
system is not very well documented.
<a href="https://lists.clearlinux.org/pipermail/dev/2016-January/000159.html">This mailing list post</a>
has some reverse-engineered design documentation.</p>
<p>Like OSTree static deltas, it also uses bsdiff for network efficiency.</p>
<p>More information will be filled in here over time. The OSTree author
believes that at the moment, the “CL updater” is not truly atomic in
the sense that because it applies updates live, there is a window
where the OS root may be inconsistent.</p>
<h2 id="casync">
<a href="#casync" class="anchor-heading" aria-labelledby="casync"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> casync
</h2>
<p>The <a href="https://github.com/systemd/casync">systemd casync</a> project is
relatively new. Currently, it is more of a storage library, and doesn’t
support higher level logic for things like GPG signatures, versioning
information, etc. This is mostly the <code class="language-plaintext highlighter-rouge">OstreeRepo</code> layer. Moving up to
the <code class="language-plaintext highlighter-rouge">OstreeSysroot</code> level - things like managing the bootloader
configuration, and most importantly implementing correct merging for <code class="language-plaintext highlighter-rouge">/etc</code>
are missing. casync also is unaware of SELinux.</p>
<p>OSTree is really today a shared library, and has been for quite some time.
This has made it easy to build higher level projects such as
<a href="https://github.com/projectatomic/rpm-ostree/">rpm-ostree</a> which has quite
a bit more, such as a DBus API and other projects consume that, such as
<a href="http://cockpit-project.org/">Cockpit</a>.</p>
<p>A major issue with casync today is that it doesn’t support garbage collection
on the server side. OSTree’s GC works symmetrically on the server and client
side.</p>
<p>Broadly speaking, casync is a twist on the dual partition approach, and
shares the general purpose disadvantages of those.</p>
<h2 id="menderio">
<a href="#menderio" class="anchor-heading" aria-labelledby="menderio"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Mender.io
</h2>
<p><a href="https://mender.io/">Mender.io</a> is another implementation of the dual
partition approach.</p>
<h2 id="olpc-update">
<a href="#olpc-update" class="anchor-heading" aria-labelledby="olpc-update"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> OLPC update
</h2>
<p>OSTree is basically a generalization of olpc-update, except using
plain HTTP instead of rsync. 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.</p>
<p>OSTree has built-in plain old HTTP replication which can be served
from a static webserver, whereas olpc-update uses <code class="language-plaintext highlighter-rouge">rsync</code> (more server
load, but more efficient on the network side). The OSTree solution to
improving network bandwidth consumption is via static deltas.</p>
<p>See
<a href="http://blog.verbum.org/2013/08/26/ostree-v2013-6-released/#comment-1169">this comment</a>
for a comparison.</p>
<h2 id="nixos--nix">
<a href="#nixos--nix" class="anchor-heading" aria-labelledby="nixos--nix"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> NixOS / Nix
</h2>
<p>See <a href="http://nixos.org/">NixOS</a>. It was a very influential project for OSTree.
NixOS and OSTree both support the idea of independent “roots” that are bootable.</p>
<p>In NixOS, files in a package are accessed by a path depending on the checksums
of package inputs (build dependencies) - see
<a href="http://nixos.org/nix/manual/#chap-package-management/">Nix store</a>.
However, OSTree uses a commit/deploy model - it isn’t tied to any particular
directory layout, and you can put whatever data you want inside an OSTree, for
example the standard FHS layout. A both positive and negative of the Nix model
is that a change in the build dependencies (e.g. being built with a newer gcc),
requires a cascading rebuild of everything. It’s good because it makes it easy
to do massive system-wide changes such as gcc upgrades, and allows installing
multiple versions of packages at once. However, a security update to e.g. glibc
forces a rebuild of everything from scratch, and so Nix is not practical at
scale. OSTree supports using a build system that just rebuilds individual
components (packages) as they change, without forcing a rebuild of their
dependencies.</p>
<p>Nix automatically detects runtime package dependencies by scanning content for
hashes. OSTree only supports only system-level images, and doesn’t do dependency
management. Nix can store arbitrary files, using nix-store --add, but, more
commonly, paths are added as the result of running a derivation file generated
using the Nix language. OSTree is build-system agnostic; filesystem trees are
committed using a simple C API, and this is the only way to commit files.</p>
<p>OSTree automatically shares the storage of identical data using hard links into
a content-addressed store. Nix can deduplicate using hard links as well, using
the auto-optimise-store option, but this is not on by default, and Nix does not
guarantee that all of its files are in the content-addressed store. OSTree
provides a git-like command line interface for browsing the content-addressed
store, while Nix does not have this functionality.</p>
<p>Nix used to use the immutable bit to prevent modifications to /nix/store, but
now it uses a read-only bind mount. The bind mount can be privately remounted,
allowing per-process privileged write access. OSTree uses the immutable
bit on the root of the deployment, and mounts /usr as read-only.</p>
<p>NixOS supports switching OS images on-the-fly, by maintaining both booted-system
and current-system roots. It is not clear how well this approach works. OSTree
currently requries a reboot to switch images.</p>
<p>Finally, NixOS supports installing user-specific packages from trusted
repositories without requiring root, using a trusted daemon.
<a href="https://lwn.net/Articles/687909/">Flatpak</a>, based on OSTree, similarly has a
policykit-based system helper that allows you to authenticate via polkit to
install into the system repository.</p>
<h2 id="solaris-ips">
<a href="#solaris-ips" class="anchor-heading" aria-labelledby="solaris-ips"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Solaris IPS
</h2>
<p>See
<a href="http://hub.opensolaris.org/bin/view/Project+pkg/">Solaris IPS</a>. Broadly,
this is a similar design as to a combination of BTRFS+RPM/deb. There
is a bootloader management system which combines with the snapshots.
It’s relatively well thought through - however, it is a client-side
system assembly. If one wants to image servers and replicate
reliably, that’d be a different system.</p>
<h2 id="google-servers-custom-rsync-like-approach-live-updates">
<a href="#google-servers-custom-rsync-like-approach-live-updates" class="anchor-heading" aria-labelledby="google-servers-custom-rsync-like-approach-live-updates"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Google servers (custom rsync-like approach, live updates)
</h2>
<p>This paper talks about how Google was (at least at one point) managing
updates for the host systems for some servers:
<a href="https://www.usenix.org/node/177348">Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One (USENIX LISA 2013)</a></p>
<h2 id="conary">
<a href="#conary" class="anchor-heading" aria-labelledby="conary"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Conary
</h2>
<p>See
<a href="http://wiki.rpath.com/wiki/Conary:Updates_and_Rollbacks">Conary Updates and Rollbacks</a>. If
rpm/dpkg are like CVS, Conary is closer to Subversion. It’s not bad,
but e.g. its rollback model is rather ad-hoc and not atomic. It also
is a fully client side system and doesn’t have an image-like
replication with deltas.</p>
<h2 id="bmap">
<a href="#bmap" class="anchor-heading" aria-labelledby="bmap"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> bmap
</h2>
<p>See
<a href="https://source.tizen.org/documentation/reference/bmaptool/introduction">bmap</a>.
A tool for optimized copying of disk images. Intended for offline use,
so not directly comparable.</p>
<h2 id="git">
<a href="#git" class="anchor-heading" aria-labelledby="git"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Git
</h2>
<p>Although OSTree has been called “Git for Binaries”, and the two share the idea
of a hashed content store, the implementation details are quite different.
OSTree supports extended attributes and uses SHA256 instead of Git’s SHA1. It
“checks out” files via hardlinks, rather than copying, and thus requires the
checkout to be immutable. At the moment, OSTree commits may have at most one
parent, as opposed to Git which allows an arbitrary number. Git uses a
smart-delta protocol for updates, while OSTree uses 1 HTTP request per changed
file, or can generate static deltas.</p>
<h2 id="conda">
<a href="#conda" class="anchor-heading" aria-labelledby="conda"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Conda
</h2>
<p><a href="http://conda.pydata.org/docs/">Conda</a> is an “OS-agnostic, system-level binary
package manager and ecosystem”; although most well-known for its accompanying
Python distribution anaconda, its scope has been expanding quickly. The package
format is very similar to well-known ones such as RPM. However, unlike typical
RPMs, the packages are built to be relocatable. Also, the package manager runs
natively on Windows. Conda’s main advantage is its ability to install
collections of packages into “environments” by unpacking them all to the same
directory. Conda reduces duplication across environments using hardlinks,
similar to OSTree’s sharing between deployments (although Conda uses package /
file path instead of file hash). Overall, it is quite similar to rpm-ostree in
functionality and scope.</p>
<h2 id="rpm-ostree">
<a href="#rpm-ostree" class="anchor-heading" aria-labelledby="rpm-ostree"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> rpm-ostree
</h2>
<p>This builds on top of ostree to support building RPMs into OSTree images, and
even composing RPMs on-the-fly using an overlay filesystem. It is being
developed by Fedora, Red Hat, and CentOS as part of Project Atomic.</p>
<h2 id="gnome-continuous">
<a href="#gnome-continuous" class="anchor-heading" aria-labelledby="gnome-continuous"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> GNOME Continuous
</h2>
<p>This is a service that incrementally rebuilds and tests GNOME on every commit.
The need to make and distribute snapshots for this system was the original
inspiration for ostree.</p>
<h2 id="docker">
<a href="#docker" class="anchor-heading" aria-labelledby="docker"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Docker
</h2>
<p>It makes sense to compare OSTree and Docker as far as <em>wire formats</em>
go. OSTree is not itself a container tool, but can be used as a
transport/storage format for container tools.</p>
<p>Docker has (at the time of this writing) two format versions (v1 and
v2). v1 is deprecated, so we’ll look at <a href="https://github.com/docker/docker/blob/master/image/spec/v1.1.md">format version 2</a>.</p>
<p>A Docker image is a series of layers, and a layer is essentially JSON
metadata plus a tarball. The tarballs capture changes between layers,
including handling deleting files in higher layers.</p>
<p>Because the payload format is just tar, Docker hence captures
(numeric) uid/gid and xattrs.</p>
<p>This “layering” model is an interesting and powerful part of Docker,
allowing different images to reference a shared base. OSTree doesn’t
implement this natively, but it’s not difficult to implement in higher
level tools. For example in
<a href="https://github.com/flatpak/flatpak">flatpak</a>, there’s a concept of a
SDK and runtime, and it would make a lot of sense for the SDK to
depend on the runtime, to avoid clients downloading data twice (even
if it’s deduplicated on disk).</p>
<p>That gets to an advantage of OSTree over Docker; OSTree checksums
individual files (not tarballs), and uses this for deduplication.
Docker (natively) only shares storage via layering.</p>
<p>The biggest feature OSTree has over Docker though is support for
(static) deltas, and even without pre-configured static deltas, the
<code class="language-plaintext highlighter-rouge">archive</code> format has “natural” deltas. Particularly for a “base
operating system”, one really wants on-wire deltas. It’d likely be
possible to extend Docker with this concept.</p>
<p>A core challenge both share is around metadata (particularly signing)
and search/discovery (the ostree <code class="language-plaintext highlighter-rouge">summary</code> file doesn’t scale very
well).</p>
<p>One major issue Docker has is that it <a href="https://github.com/projectatomic/skopeo/issues/11">checksums compressed data</a>,
and furthermore the tar format is flexible, with multiple ways to represent data,
making it hard to impossible to reassemble and verify from on-disk state.
The <a href="https://github.com/docker/docker/blob/master/pkg/tarsum/tarsum_spec.md">tarsum</a> effort
was intended to address this, but it was not adopted in the end for v2.</p>
<h2 id="docker-related-balena">
<a href="#docker-related-balena" class="anchor-heading" aria-labelledby="docker-related-balena"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Docker-related: Balena
</h2>
<p>The <a href="https://github.com/resin-os/balena">Balena</a> project forks Docker and aims
to even use Docker/OCI format for the root filesystem, and adds wire deltas
using librsync. See also <a href="https://mail.gnome.org/archives/ostree-list/2017-December/msg00002.html">discussion on libostree-list</a>.</p>
<h2 id="torizon-platform">
<a href="#torizon-platform" class="anchor-heading" aria-labelledby="torizon-platform"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Torizon Platform
</h2>
<p><a href="https://www.toradex.com/operating-systems/torizon">Torizon</a> is an open-source
software platform that simplifies the development and maintenance of embedded
Linux software. It is designed to be used out-of-the-box on devices requiring
high reliability, allowing you to focus on your application and not on building
and maintaining the operating system.</p>
<h3 id="torizon-os">
<a href="#torizon-os" class="anchor-heading" aria-labelledby="torizon-os"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Torizon OS
</h3>
<p>The platform OS - <a href="https://www.toradex.com/operating-systems/torizon">Torizon OS</a> -
is a minimal OS with a Docker runtime and libostree + Aktualizr. The main goal
of this system is to allow application developers to use containers, while the
maintainers of Torizon OS focus on the base system updates.</p>
<h3 id="torizoncore-builder">
<a href="#torizoncore-builder" class="anchor-heading" aria-labelledby="torizoncore-builder"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> TorizonCore Builder
</h3>
<p>Since the Torizon OS is meant as a binary distribution, OS customization is
made easier with <a href="https://developer.toradex.com/torizon/os-customization/torizoncore-builder-tool-customizing-torizoncore-images/">TorizonCore Builder</a>,
as the tool abstracts the handling of OSTree concepts from the final users.</p>
<h3 id="torizon-cloud">
<a href="#torizon-cloud" class="anchor-heading" aria-labelledby="torizon-cloud"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Torizon Cloud
</h3>
<p><a href="https://developer.toradex.com/torizon/torizon-platform/torizon-platform-services-overview/">Torizon Cloud</a>
is a hosted OTA update system that provides OS updates to Torizon OS using
OSTree and Aktualizr.</p>
<hr>
<footer>
<p class="text-small text-grey-dk-100 mb-0">Copyright &copy; <a href="https://www.redhat.com">Red Hat, Inc.</a> and <a href="https://github.com/ostreedev">others</a>.</p>
<div class="d-flex mt-2">
<p class="text-small text-grey-dk-000 mb-0">
<a href="https://github.com/ostreedev/ostree/tree/main/docs/related-projects.md" id="edit-this-page">Edit this page on GitHub</a>
</p>
</div>
</footer>
</div>
</div>
<div class="search-overlay"></div>
</div>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink