✧✦Catherine✦✧the expectation of being able to run docker whenever in CI jobs is probably the single worst outcome of free GitHub Actions minutes because reproducing it in a bring-your-own-compute environment is borderline impossible unless you make every machine single-tenant
even if you make every machine single-tenant, most configurations of Forgejo Actions runners would enable malware to escape the build container, persist itself and infect all future releases
it's possible that LXC or firecracker-containerd would solve my problem here
I love this, so I@whitequark about 2 weeks ago I learned that “incus” is the new LXC
Inga stands with 🇺🇦 🇵🇸@jpm @whitequark isn't it the new LXD? While under the hood both use LXC.
@IngaLovinde @whitequark don’t know the details, might be the other way around? Every lxc command is replaced with an identical incus command. The only reason I found out was because I was trying to deploy a new LXC guest and it failed due to linuxcontainers dot org refusing service to LXC tools now.
@jpm @whitequark it used to be LXC for low-level container functionality (a bunch of CLI tools with a bunch of logic on top of kernel containers interface) + LXD on top of LXC, for nice UX to manage the containers.
Then Ubuntu did a takeover of LXD, so incus was born as a libre community fork of LXD.
But incus still uses LXC under the hood, and e.g. on alpine LXC is still a dependency of incus: https://pkgs.alpinelinux.org/package/edge/community/x86_64/incus
I'm not sure which LXC tools are you referring to or how or why linuxcontainers dot org would refuse service to them (seeing how LXC is still listed there https://linuxcontainers.org/lxc/ ) or which LXC commands are you referring to.
@IngaLovinde @whitequark I don't know the details of it, but this explains what they did and why my existing setup broke: https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479 - migration to Incus was easy though. I don't deploy new images very often, and tend to stick with older stable releases until support officially ends because I just want things to work and don't care about the new shiny unless I actually need it.
Important notice for LXD users (image server)
Introduction The image server at https://images.linuxcontainers.org has been in operation since early 2014, first offering images to LXC users through the download template and then once LXD came around, it was expanded to also provide LXD container and eventually virtual-machine images. The infrastructure used to build and distribute those images has always been purposefully kept community owned and operated. That’s so that every distribution represented on the image server is on equal footing...
@jpm @whitequark ...but that's about LXD, not LXC. Just as I was saying.
@IngaLovinde @whitequark ok, i never really paid much attention to the LXD/LXC split because it was never really explained very well when I originally set it up a few years ago, all I know is that when I ran `lxc launch images:debian/13/cloud new-instance` it told me to go away and install incus.
@whitequark so it turns out the folks who run linuxcontainers dot org have basically told canonical to play hide and go fuck yourself and blocked container image downloads from LXC tools. Theres a very simple LXC-to-incus migration script available, and then everything just keeps on trucking after you change lxc to incus in commands lines.
Also, nested containers works, I’ve got podman running inside an incus guest without elevated privileges.