mirror of
https://github.com/ostreedev/ostree.git
synced 2025-03-16 10:50:43 +03:00
771 lines
37 KiB
HTML
771 lines
37 KiB
HTML
|
||
|
||
<!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&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> ->
|
||
<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 © <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>
|
||
|