forked from containers/bootc
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Colin Walters <[email protected]>
- Loading branch information
Showing
1 changed file
with
119 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. | ||
|