Systemd author thinks "OCI is just terrible by any standard"?

General
1

I just stumbled upon these news:

The linked Mastodon thread started by Lennart Poettering gives more insight.

One particular exchange of words starting from this post caught my attention:

@pid_eins Slowly but surely, systemd is turning into a container engine and I’m here for it!

Out of curiosity, did you ever take a look at boot2container (gfx-ci / Boot2container · GitLab)? It is my podman- and u-root based initrd that boots any container(s) without any installation, based on the kernel cmdline.

That’s IMO the next level of flexibility, but I must admit I have not worked on its security at all… but this is mostly meant for CI purposes (DUTs or gateway) so the needs are different.

@mupuf OCI/podman is really not my world, sorry. I didn’t drink that cool-aid.

@pid_eins aside from OCI or DDIs, are there any plans for a more practical or efficient image format?

It currently feels somewhat cumbersome to try to generate and distribute raw ddi’s + extensions for things like portable services or nspawn. It also feels a bit wasteful when you’re basing multiple containers on the same image.

I’d love to see something git- or ostree-like…

@risen uh, i am happy with ddis.

To say this politely I am not a believer and the security model ostree folks and OCI folks subscribe to. I subscribe to the idea that we should do W^X also for file systems: i.e. a file system is either writable, or it may contain executable files, but never both, as part of guaranteeing that attackers cannot gain persistency, no matter what.

DDIs fit perfectly into the model, but ostree (regardless with or without composefs glue) does conceptually not come close, and well, OCI is just terrible by any standard.

(DDI stands for Discoverable Disk Image.)

Now I really wonder why Lennart Poettering thinks that “OCI is just terrible by any standard”… :smile: Maybe someone here knows more about the underlying dispute?

2

Lennart is famously not into containers. Some people are always going to prefer an image based approach, both methods have plenty of use cases and plenty of people who will consume them.

Most of this doesn’t matter to us, the image based equivalent to Bluefin would be something like GNOME OS, and to the end user the ux is the same, apps from flathub, development in containers, etc.

The core OS here doesn’t matter (which is what we’ve been saying since the beginning), how it’s made is more a matter of taste and preferred tooling. We’re cloud nerds so we naturally fit with an OCI based workflow.

3

Thanks for your assessment! I understand that it’s more about the journey than the destination, i.e. how the OS (image) is built rather than the resulting OS (image).

Most of this doesn’t matter to us, the image based equivalent to Bluefin would be something like GNOME OS

IIUC, GNOME OS is built using Apache BuildStream, same as FlatHub’s hosted runtimes. BuildStream appears rather unsexy to me compared to OCI tooling, but I’m certainly not an expert.

I’m really curious to see which “denomination” will prevail (i.e. scale better) in the midterm! I tend to bet on the OCI bandwagon…

4

We’ve talked about making a Bluefin built this way, someone can take GNOME OS and make a build, it’s probably not too hard. We’ll see what people end up making!

1 Like