Some awesome community projects have also been born out of this space:
- https://universal-blue.org/ provides some neat Fedora images, which have one of the best Nvidia driver experiences on Linux IME, and are over all solid and dependable
- https://blue-build.org/ makes it pretty easy to build images like Universal Blue's for personal use
The best part here is really the composability; you can take a solid atomic Linux base, add whatever you like, and ship it over the air to client computers with container registries. All clients see is a diff every day, which they pull and 'apply' to be used after the next boot.
I've been hoping NixOS moves in this direction over time, the distribution/rollout aspect seems under-baked currently.
Do you think this helps that at all?
Did I guess it right that it basically processes Containerfile and instead of producing a .tar artifact (which is what container images usually are) it produces .qcow2/.ami/.raw/.iso/.vmdk file which in case of .qcow2/.raw/.vmdk can be used by a virtualization software to start up a VM with a disk mounted from that file?
Will the changes made inside a session with such a VM persist? or will they get lost (which is the default behavior with containers)?
Container's filesystem may be as narrow as a single binary file, surely a VM with such a filesystem won't be able to boot - where will it take the OS (with the kernel, drivers and other stuff) from?
2) you push that container image to some registry
3) you use the bootc image container to create an qcow file from the image you have built (or you install the image on a bare metal system)
4) you boot up the virtual machine or bare metal system, which now includes "bootc" utilties too
5) from this point on you can update the container image you have created in step 1) and you automatically roll forward the booted virtual machine or bare metal system to the latest image you have relased (or rollback, if your updated image breaks stuff) using the included bootc utility
Currently the image that supports this seems to be limited to centos:stream9, or rhel9:
https://www.redhat.com/en/blog/image-mode-red-hat-enterprise...
registry.fedoraproject.org/fedora-bootc:latest
> Begin by confirming that your system is subscribed to get RHEL content.
> $ sudo subscription-manager register
nope.
So only CentOS? Would it be possible to run that with firecracker? If that is the case, then wouldn't it be better to just run a Docker/container file in a firecracker vm. It will be more isolation, and easier scripting and networking?
I wonder if this project would've served my use case. The OCI images you build when layering FCOS images all build atop the base FCOS image. So I would expect them to be "bootable" in some sense.
I have used GitHub Actions and GitHub Container Registry the way Bluefin uses it to build and push images there. You might be able to even just mirror them from there if you want to punch a hole in your air gap.
By the way, is there a way to create minimal NixOS VMs without systemd?
- [0] https://github.com/alpinelinux/alpine-make-vm-image - [1] https://github.com/nix-community/nixos-generators
No, systemd is a hard dependency for NixOS.
Key differences: I like the chrootyness instead of having the complete filesystem available (similar to what orbstack does). I'll have a look this weekend.
It would be nice to have my "own" Linux distro.
The whole project is in major flux now though, with v1.3 -> v2.1 being pre-release and docs haven't been updated, so I'm waiting for dust to settle before picking it back up. But basically `docker build` -> `elemental build-disk` -> qcow2/iso -> deploy / `elemental upgrade` update via OCI registry, or deploy vanilla image and then just update that via registry.
This turns a Linux container into a bootable Linux OS.
If your container starts a GUI environment and launches a browser pointed to your React app I see no reason to think that wouldn't work after making it bootable.
It sounds like you're expecting it to be some kind of OS of its own though, that it would automatically drop straight in to code you give it somehow. That's not what it is.
I tried Nix a few times, but the documentation was so lacking and/or outdated that I couldn't figure out how to get the setup I needed working, and I had to drop the idea as I couldn't justify the time investment that would be needed to prod around in the dark until everything worked.
Between the nonguix README and other resources like systemcrafters, you're in pretty good company as far as the documentation for non-free things to.
Edit: less related but I still wanted to mention:
Guix makes extensive use of the info[0][1] system for documentation also. There is essentially a textbook worth of information locally on the machine, which is generally what I use instead of turning to the web.
[0] https://www.gnu.org/software/texinfo/manual/info-stnd/info-s...
[1] https://www.gnu.org/software/emacs/manual/html_mono/info.htm...
Surely you can even boot a bootc-enabled container image like this on a Firecracker MicroVM.
Are currently available, but since this is an open source project, we look forward to other distros creating bootc images.
And the fact that it’s ever so slightly easier to build and deploy a NixOS VM from scratch on a Proxmox VE server than to build and deploy a CoreOS VM using Ignition (also on Proxmox).
But it’s probably worth it for me to switch back, at least for now. It takes maybe 10-15 minutes to build a bootable Bluefin fork native container image with GitHub Actions, but a relatively basic NixOS+ Plasma 6 image took closer to 60 minutes and came out to over 8 GB compressed…