> nix-build '<nixpkgs/nixos>' -A vm -I nixpkgs=channel:nixos-25.05 -I nixos-config=./configuration.nix
I use nixos btw
`nixos-rebuild build-image --image-variant vmware`
See https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui...
...as long as the images are in the Red Hat family (Fedora, CentOS Stream, RHEL).
Do Native Containers work as VM images that can be stored in an OCI Image/Artifact/Package Registry?
I've been mentioning Native Containers since I realized that was how bazzite works now.
Is vagrant necessary anymore if host, vm, and container images can all be signed and stored in an OCI Image store?
From https://news.ycombinator.com/item?id=44137501 re: Firecracker and Microsandbox VMs :
> ostree native containers are bootable host images that can also be built and signed with a SLSA provenance attestation; https://coreos.github.io/rpm-ostree/container/
ublue-os/image-template: https://github.com/ublue-os/image-template :
> Build your own custom Universal Blue Image
ublue-os/akmods has nvidia GPU drivers, nvidia-open, zfs: https://github.com/ublue-os/akmods :
> A caching layer for pre-built Fedora akmod RPMs
> OCI images providing a set of cached kernel RPMs and extra kernel modules to Universal Blue images. Used for better hardware support and consistent build process.
nvidia-container-toolkit (CDI) is necessary for --gpus=all to do CUDA and libEGL 3D with podman. Is this also already installed in bazzite?
ublue-os/toolboxes: "quadlets and systemd service units for management", boxkit : https://github.com/ublue-os/toolboxes#images
ublue-os/devcontainer .devcontainer/devcontainer.json: https://github.com/ublue-os/devcontainer/blob/main/src/base/...
It looks like the Just Justfile 40-nvidia.just has moved due to image topology simplification? https://news.ycombinator.com/item?id=39364975 :
> ublue-os/config//build/ublue-os-just/40-nvidia.just defines the `ujust configure-nvidia` and `ujust toggle-nvk` commands
From https://coreos.github.io/rpm-ostree/container/#ostree-native... :
> rpm-ostree inherits work in ostree-rs-ext to create “container native ostree” functionality. This elevates OCI/docker containers to be natively supported as a transport mechanism for bootable operating systems.
I think it means simplification of complexity and unnecessary re-duplication.
I've used this to start from a minimal base and added what I've needed on top. Best of all, updates are delivered via a container registry.
Does anyone have experience worth sharing with both?
Also, bootc is a basis for the Universal Blue family of distros, especially Bazzite, which is very popular with gamers.
I thought of the underlying tech for those other distros being ostree more than anything but this is the better interpretation.
What I like about this is always having a known working image I can quickly swap to, particularly for the machine with an nvidia card.
I've always been hesitant to use this method over debootstrap: the Ubuntu container images ("FROM ubuntu:20.04") are created from a tarball that Ubuntu's convoluted CI system spits out and I'm not confident I understand if it's somehow suitable only for a container and not for real hardware.
https://github.com/systemd/mkosi
However beware that they break backwards compatibility almost every 6 months. This is probably the most backwards-incompable project I know, you can't rely that the minor version update won't break your projects.
twelvenmonkeys•7mo ago
https://github.com/podman-desktop/extension-bootc
We’re also starting to see other projects adopt a “OS as a Container image” such as Bazzite: https://bazzite.gg/ using bootc :)
Feel free to ask any questions!
ChocolateGod•7mo ago
jeffro_rh•7mo ago