Universal Blue•2y ago•

198 replies

systemd-sysext discussion

j0rgeOP•1/10/24, 4:37 PM

@bsherman in here

bsherman•1/10/24, 4:37 PM

w00t

j0rgeOP•1/10/24, 4:37 PM

cc @bketelsen

j0rgeOP•1/10/24, 4:38 PM

right, so bluefin-dx right

j0rgeOP•1/10/24, 4:38 PM

it has to be a seperate image because we're adding a bunch of stuff right

j0rgeOP•1/10/24, 4:38 PM

what if the just devmodejust devmode switch just added all the things we need in dx to normal bluefin, and you could add/remove any of those components and add more without having to make it a seperate image

j0rgeOP•1/10/24, 4:39 PM

like if you want dx but you don't want vscode, you're stuck with it

bketelsen•1/10/24, 4:39 PM

I love this so so much

bsherman•1/10/24, 4:43 PM

yes, i think this could be killer for dev

j0rgeOP•1/10/24, 4:43 PM

yeah let's try it with incus imo if brian wants to prototype

bketelsen•1/10/24, 4:45 PM

brian is already prototyping

bketelsen•1/10/24, 4:45 PM

bsherman•1/10/24, 4:50 PM

I like how you (Brian) added docker to bluefin with it... i think this could give us a story for support docker, but not having to pre-install it... even in ucore.

It's one of the things I don't like a lot since it's a duplicate of podman unless users really need it.

j0rgeOP•1/10/24, 4:50 PM

I'm thinking about the pattern

j0rgeOP•1/10/24, 4:50 PM

not the exact package

j0rgeOP•1/10/24, 4:50 PM

but to use docker as an example

j0rgeOP•1/10/24, 4:50 PM

you know how the -dx updates are like 1.6GB?

j0rgeOP•1/10/24, 4:51 PM

what if docker was an extension instead of in the bluefin image?

Jj0rge not the exact package

bsherman•1/10/24, 4:52 PM

(there I go again, getting stuck in specifics)

j0rgeOP•1/10/24, 4:52 PM

like my question would be, what if the containerfile for -dx was "pull in these extensions", they'd be diffed updates, etc and it wouldn't be this huge custom layer

j0rgeOP•1/10/24, 4:52 PM

right, but let's say someone was like "but I want docker in ucore"

j0rgeOP•1/10/24, 4:52 PM

you tell them go make a custom image and they go do that

j0rgeOP•1/10/24, 4:52 PM

or they just add a docker sysext

Jj0rge like my question would be, what if the containerfile for -dx was "pull in these ...

bsherman•1/10/24, 4:52 PM

yes, I agree, especially with "dev-mode"/-dx developers need different stuff, so one size fits all is huge, this makes it much more managable and per-user custom

j0rgeOP•1/10/24, 4:52 PM

actually what flatcar did is remove docker, containerd, etc OFF of their base image

j0rgeOP•1/10/24, 4:53 PM

so you could do flatcar + podman if you wanted to

j0rgeOP•1/10/24, 4:53 PM

or flatcar + the entire k8s stack

j0rgeOP•1/10/24, 4:54 PM

so the philosophical question is, "what if our base image was actually base-main and people could atomically bolt on the desktop stuff but it wouldn't be a custom image for each one"

j0rgeOP•1/10/24, 4:55 PM

actually that'd be an interesting exercise, take base-main and systext in the gnome from GNOME OS.

j0rgeOP•1/10/24, 4:56 PM

also what's cool, you can do this on any linux, so it's additive

Jj0rge so the philosophical question is, "what if our base image was actually base-main...

bsherman•1/10/24, 5:02 PM

this is key, it's a philosophical question

j0rgeOP•1/10/24, 5:02 PM

like someone will do ublue but with sysext, no problemo

bsherman•1/10/24, 5:02 PM

so, if we use Fedora, but strip all it's packages out, and just use these sysexts, then are we Fedora still or a new thing?

j0rgeOP•1/10/24, 5:03 PM

I'm going to reserve my opinion until I try incus.

bsherman•1/10/24, 5:04 PM

seems to me we'd be providing our own sysext packages and maintaining those, vs maintaining a few RPM COPRs and just putting things together

j0rgeOP•1/10/24, 5:04 PM

yeah, or submitting them to this bakery flatcar is doing

bketelsen•1/10/24, 5:04 PM

* but enabling those same sysext packages to be used in any systemd linux

bketelsen•1/10/24, 5:05 PM

DISTRO? Where we're going we don't need a DISTRO

j0rgeOP•1/10/24, 5:05 PM

https://github.com/flatcar/sysext-bakery/releases

j0rgeOP•1/10/24, 5:05 PM

this is what they have

j0rgeOP•1/10/24, 5:05 PM

also, I am not advocating "let's add our own extensions to maintain alongside our existing stuff." that's a road to madness

j0rgeOP•1/10/24, 5:06 PM

but if it's "let's get incus from the automated release pipeline upstream instead of hoping someone will package incus in fedora" then I'm 100% behind that

Jj0rge also, I am not advocating "let's add our own extensions to maintain alongside ou...

bsherman•1/10/24, 5:06 PM

I was thinking you were heading that way and was confused.

j0rgeOP•1/10/24, 5:06 PM

that's kyle's schtick.

j0rgeOP•1/10/24, 5:06 PM

lol

Bbketelsen DISTRO? Where we're going we don't need a DISTRO

bsherman•1/10/24, 5:10 PM

please enlighten me... i may have misread: It seemed that with sysext-bakery, as I read the butane yaml, there's still a need for someone to host
1) the scripts to build docker/torcx/wasm/inucs sysexts
2) also (maybe?) the resulting docker.rawdocker.raw images (example)

Am I incorrect, and yes, scripts need to exist(be hosted), but every system would build the images locally?

bketelsen•1/10/24, 5:10 PM

the scripts need to exist (the bakery repo hosts them in this example), and the resulting images are hosted in github releases

bketelsen•1/10/24, 5:11 PM

in the model they're using they're built on github, nothing is built on the host.

Bbketelsen the scripts need to exist (the bakery repo hosts them in this example), and the ...

bsherman•1/10/24, 5:11 PM

ok, yeah, so i didn't misunderstand...

in my mind, that's at least part of a distro

bketelsen•1/10/24, 5:11 PM

that's not the only option

systemd-sysext discussion

Similar Threads

Similar Threads

Similar Threads