Skip to content

Commit

Permalink
wip
Browse files Browse the repository at this point in the history
Signed-off-by: Colin Walters <[email protected]>
  • Loading branch information
cgwalters committed Jan 4, 2024
1 parent 47f8a34 commit b5a4373
Showing 1 changed file with 119 additions and 0 deletions.
119 changes: 119 additions & 0 deletions docs/relationship-particles.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,119 @@
---
nav_order: 6
---

# Relationship with systemd "particles"

There is an excellent [vision blog entry](https://0pointer.net/blog/fitting-everything-together.html)
that puts together a coherent picture for how a systemd (and [uapi-group.org](https://uapi-group.org/))
oriented Linux based operating system can be put together, and the rationale for doing so.

The "bootc vision" aligns with parts of this, but differs in emphasis and also some important technical details - and some of the emphasis and details have high level ramifications. Simply stated: related but different.

## System emphasis

The "particle" proposal mentions that the desktop case is most
interesting; the bootc belief is that servers are equally
important and interesting. In practice, this is not a real point
of differentation, because the systemd project has done an excellent
job in catering to all use cases (desktop, embedded, server) etc.

An important aspect related to this is that the bootc project exists and must
interact with many ecosystems, from "systemd-oriented Linux" to Android and
Kubernetes. Hence, we would not explicitly compare with just ChromeOS, but also
with e.g. [Kairos](https://kairos.io/) and many others.

## Design goals

Many of the toplevel design goals do overall align. It is clear that e.g. Discoverable Disk Images and container image (OCI) align on managing systems in an image-oriented fashion.

### A difference on goal 11

Goal 11 states:

> Things should not require explicit installation. i.e. every image should be a live image. For installation it should be sufficient to dd an OS image onto disk.
The `bootc install` approach is explicitly intending to support things such
as e.g. static IP addresses provisioned via kernel arguments at install time;
it is not a goal for installations to be equivalent to `dd`.

(The bootc creator has experience with systems that install this way, and it creates
practical problems in nontrivial scenarios such as ["Advanced Format"](https://en.wikipedia.org/wiki/Advanced_Format) disk drives)

### Goal: An explicit alignment with cloud-native

The bootc project has an explicit goal to to take formats, cues and inspiration
from the container and cloud-native ecosystem. More on this in several sections below.

## Hermetic `/usr`

One of the biggest differences starts with this. The idea of having
the entire operating system self-contained in `/usr` is a good one. However,
there is an immense amount of prior history and details that make this
hard to support in many generalized cases.

[This tracking issue](https://github.com/uapi-group/specifications/issues/76) is a good starting point - it's mostly about `/etc` (see below).

### bootc design: Carve out sub mounts

Instead, the bootc model allows arbitrary directory roots starting from `/`
to be included in the base operating system image.

This first notable difference is rooted in bootc taking a stronger cue from the [opencontainers](https://github.com/opencontainers) ecosystem (including docker/podman/Kubernetes).
There are no restrictions on application container filesystem layout (everything
is ephemeral by default, and persistence must be explicit); bootc aims to be closer
to this.

There is still alignment: bootc design does *strongly encourage* operating
system state to live underneath `/usr` - it should be the default place for all
operating system executable binaries and default configuration. It should be
read-only by default.

### `/etc`

Today, the bootc project uses [ostree](https://github.com/ostreedev/ostree/) as a backend,
and a key semantic ostree provides for `/etc` is a "3 way merge".

This has several important differences. First, it means that `/etc` does get updated
by default for unchanged configuration files.

The default proposal for "particle" OSes to deal with "legacy" config files in
`/etc` is to copy them on first OS install (e.g. `/usr/share/factory`).

This creates serious problems for all the software (for example, OpenSSH) that put config
files there; - having the default configuration updated (e.g. for a security issue) for a package manager but not an image based update is not viable.

However a key point of alignment between the two is that we still aim to
have `/etc` exist and be useful! Writing files there, whether from `vi`
or config management tooling must continue to work. Both bootc and systemd "particle"
systems should still Feel Like Unix - in contrast to e.g. Android.

At the current time, this is implemeted in ostree; as bootc moves
towards stronger integration with podman, it is likely that this logic
will simply be moved into bootc instead on top of podman.
Alternatively perhaps, podman itself may grow some support for
specifying this merge semantic for containers.

### Other persistent state: `/var`

Supporting arbitrary toplevel files in `/` on operating system
updates conflicts with a desire to have e.g. `/home` be persistent by default.

Hence, bootc emphasizes having e.g. `/home``/var/home` as
a default symlink in base images.

Aside from `/home` and `/etc`, it is common on most Linux systems to
have most persistent state under `/var`, so this is not a major point
of difference otherwise.

### Other toplevel files/directories

Even the operating systems have completed "UsrMerge" still have
legacy compatibility symlinks required in `/`, e.g. `/bin``/usr/bin`.
We still need to support shipping these for many cases, and they
are an important part of operating system state. Having them
not be explicitly managed by OS updates is hence suboptimal.

Related to this, bootc will continue to support operating systems that have
not completed UsrMerge.

0 comments on commit b5a4373

Please sign in to comment.