Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
I think Flatcar is alive and well. I haven't used it personally so I can't really comment much on it.
As for building VM images, I don't actually do that in my setup. I just use the base FCOS image, boot it with a barebones Butane to configure disks and then use the CoreOS Layering features to setup my workload.
If you want to use ZFS on your setup, check out https://github.com/coreos/layering-examples/blob/main/build-... which has an example of building the ZFS on Linux module so you can setup your ZFS pools.
What these sort of introductions to immutable always fail to consider is the other side of the coin, image-based. I'm working on https://universal-blue.org/ along with many people much more skilled than me. We build OCI container images on top of vanilla Fedora Silverblue & many other editions with different desktops. Those images can then be booted to (or rather rebased to) using rpm-ostree. This is a more robust way of extending the system than layering, and the same changes can be easily benefited or inherited from by anyone. You can even make your own image really easily!
I think that VanillaOS and SUSE are working on similar things, but we're not an OS project, just a downstream from Fedora. Fedora's full support is underway but with what's already working perfectly our methods are already IME some of the most robust and easy ways of delivering Nvidia drivers for example.
On the server-side, there's Bottlerocket OS [1] (Amazon). They use A/B partitions for upgrades, and the idea is that you just run containers for anything non-base. Boot containers are used to do custom configuration at boot, and host-container (or DaemonSet, if you run K8S) is used for long-running services.
[1] https://github.com/bottlerocket-os/bottlerocket
While I am glad Silverblue is on this list, not having Fedora CoreOS on it too is a shame. FCOS is an amazing OS to run in production and it has come a very long way since the CoreOS acquisition. I find that FCOS is a good middle ground of being usable and easy to learn while still being immutable compared to Nix.
The FCOS devs introduced a new feature called CoreOS Layering which lets you define your system in a Dockerfile and FCOS will rebase to that state and all you have to do is reboot to configure your server. It is super powerful.
Anyways, your next project needs a VM, give it a shot. I made a Python based CLI tool to help you develop locally on a Linux workstation to create a Butane file to fit your needs. Below is the GitHub for Bupy and a good example of running an app (Paperless NGX) on FCOS with the CoreOS Layering features.
https://github.com/quickvm/bupy
https://github.com/quickvm/fcos-layer-paperless-ngx
https://coreos.github.io/rpm-ostree/container/
An OCI image is pretty simple, yes, so is the sort of image that is in an OSTree repository. The difference is that when using `rpm-ostree` packages installed with `rpm-ostree install` are "layered" on top of the base image, while packages in the "base image" (be it OCI or OSTree) are part of the system and thus not "layered".
Adding packages in an image has the benefit of pseudo-reproducability (have the same image on multiple computers) and the added robustness of your base system being built elsewhere daily. Your computer just pulls the diffs. For example, there have been issues with rpmfusion on Fedora that ublue users completely avoided. Codecs & other essential rpmfusion packages are included in the images, and the rpmfusion repository is removed after they are installed. This way, if something package-related breaks it breaks at the image build stage, and an ordinary user wont even notice it before it is fixed.
The most noticeable benefit IMO, though, is being able to ship the same changes on top of a base image every day for multiple machines. This is not only packages, but for example udev rules, and other QoL things like our `justfile`s, configuration for https://just.systems/ that has some useful scripts for adding the kargs necesarry for Nvidia drivers to work and `just update` for updating the system, flatpaks & distroboxes.
I'm really, really happy with my current setup of Fedora immutable + toolbox [0]. This tool lets you create containers that are fully integrated with the system, so you have acces to the entire Fedora repos, can run graphical apps, etc. while still having everything inside a container in your home directory. That means no Flatpak required. Highly recommended.
[0] https://containertoolbx.org