J@bsherman in here
Bw00t
Jcc @bketelsen
Jright, so bluefin-dx right
Jit has to be a seperate image because we're adding a bunch of stuff right
Jwhat if the
just devmodelike if you want dx but you don't want vscode, you're stuck with it
BI love this so so much
Byes, i think this could be killer for dev
Jyeah let's try it with incus imo if brian wants to prototype
Bbrian is already prototyping
B
BI 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.
It's one of the things I don't like a lot since it's a duplicate of podman unless users really need it.
JI'm thinking about the pattern
Jnot the exact package
Jbut to use docker as an example
Jyou know how the -dx updates are like 1.6GB?
Jwhat if docker was an extension instead of in the bluefin image?
B(there I go again, getting stuck in specifics)
Jlike 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
Jright, but let's say someone was like "but I want docker in ucore"
Jyou tell them go make a custom image and they go do that
Jor they just add a docker sysext
Byes, 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
Jactually what flatcar did is remove docker, containerd, etc OFF of their base image
Jso you could do flatcar + podman if you wanted to
Jor flatcar + the entire k8s stack
Jso 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"
Jactually that'd be an interesting exercise, take base-main and systext in the gnome from GNOME OS.
Jalso what's cool, you can do this on any linux, so it's additive
Bthis is key, it's a philosophical question
Jlike someone will do ublue but with sysext, no problemo
Bso, 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? 
JI'm going to reserve my opinion until I try incus. 
Bseems to me we'd be providing our own sysext packages and maintaining those, vs maintaining a few RPM COPRs and just putting things together
Jyeah, or submitting them to this bakery flatcar is doing
B* but enabling those same sysext packages to be used in any systemd linux
BDISTRO? Where we're going we don't need a DISTRO
JJthis is what they have
Jalso, I am not advocating "let's add our own extensions to maintain alongside our existing stuff." that's a road to madness
Jbut 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
BI was thinking you were heading that way and was confused.
Jthat's kyle's schtick.
Jlol
Bplease 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
Am I incorrect, and yes, scripts need to exist(be hosted), but every system would build the images locally?
1) the scripts to build docker/torcx/wasm/inucs sysexts
2) also (maybe?) the resulting
docker.rawAm I incorrect, and yes, scripts need to exist(be hosted), but every system would build the images locally?
Bthe scripts need to exist (the bakery repo hosts them in this example), and the resulting images are hosted in github releases
Bin the model they're using they're built on github, nothing is built on the host.
Bok, yeah, so i didn't misunderstand...
in my mind, that's at least part of a distro
in my mind, that's at least part of a distro
Bthat's not the only option
