By having less moving parts, it is much easier to provide a Linux operating system that works (more) reliably on many different machines.
And if you don't mind me also asking, what features are described by the term "cloud-native"?
I'm not affiliated with either distribution. Both distributions provide different out-of-the-box experiences. Fedora Silverblue tries to be a general purpose desktop OS while BlueFin has a focus on software development. You can still adapt both of them for the same purposes, but BlueFin might be a nicer starting point if you actually are a developer.
The biggest difference to classic read-write Linux distributions is that you have an immutable base system which includes software that you might find useful or useless. In addition, you can install software as Flatpaks into your home directory. It is also possible to change the software that is part of the immutable base system, but it is typically something you want to avoid.
> what features are described by the term "cloud-native"?
I suppose it refers to the container management software that is included in the immutable base system.
This project uses this upcoming feature in Fedora: https://fedoraproject.org/wiki/Changes/OstreeNativeContainer... and switches to its consumption model entirely.
On stock Fedora you're pulling from a distribution-hosted ostree endpoint to do updates. With Bluefin (and other universal-blue.org images) you're pulling from a container registry (in this case ghcr.io, but you can push your builds to any registry or host your own).
We ingest Fedora daily and then add codecs, a bunch of hardware enablement support via udev rules, add a few pain-in-the-ass-otherwise things like the obs virtual cam, xbox controller support, etc. Then that image is pushed to ghcr.io and the local package manager uses that.
We also enable Flathub out of the box and Distrobox: https://github.com/89luca89/distrobox - then ship a few preconfigured boxes for you to play with: Ubuntu, Fedora, and Wolfi.
Then we have another image that you can rebase to by typing `just devmode` in a terminal which adds vscode with devcontainers, devpod, devbox, kvm/qemu, incus/lxc/lxd, some nice monospace fonts, cockpit, kind, docker, and a bunch of associated cluster tools.
And since we build everything in CI there's no local package conflicts like in upstream Fedora when the main repo and rpmfusion repos are conflicting, your PC only ever gets successfully built images.
Does that mean every system update will download a complete image file or is there some mechanism to only download the diffs?
And then all the developer patterns are cloud native like devcontainers instead of using the host packages, included k8s, podman, and docker tooling, etc.
I'll start at the very basics, where we define "Cloud Native": Cloud native is the software approach of building, deploying, and managing modern applications in cloud computing environments.
I'll get a little hand wavy here as our desktops/laptops aren't typically defined as a "cloud" (read: grouping of machines, typically behind an API that someone else manages but makes available to users or customers). However - we can look at it as a target platform for deployment. How universal-blue gets there is the real interesting part. That "made by cloud native nerds" is a very compact way of describing how the project is built, tested, and rolled out.
Universal-blue images are all built in CI. In this case - its a combination of base layer components - sometimes built in COPR for some projects that are included in the product operating system, and then those COPR built artifacts are included by a Containerfile. Along with all the goodness contained in SilverBlue (fedora rpm artifacts).
That containerfile is built, tested, and signed in GitHub actions, and a manifest is then updated (somewhere, i don't actually know where ublue looks for these manifests to identify it has an update - it might just be the GHCR registry - but don't hold me to that).
Now this probably all sounds like something you see in your day to day if you work in infrastructure, or in a company producing software/services for the web. But what's really unique from a consumed operating system perspective is that those builds and tests effectively gatekeep the "blessed" configuration for universal-blue. Classically you have kernel modules that get built on your machine using a technique known as DKMS (Dynamic Kernel Module System). Every update to the kernel you have to re-build some library as part of the update process. And if your particular version of a module hasn't been vetted with what kernel you just pulled you can be left in a rather bad state - I've had this happen to me with the proprietary nvidia drivers as an example.
How ublue delivers these modules is part of that not-so-secret sauce that makes it wonderful. These modules are built in the cloud in that same release pipeline, and if they fail - they don't get released! You simply don't see an update for that day, and things hum along just fine. This breaking happening somewhere other than your computer is part of that reliability promise - you wont be dealing with kernel module breakage, the release maintainers will have to resolve the break (or communicate with upstream to find a solution) so your incoming stream of updates can be unblocked.
Finally - there are a lot of "patterns" - or process to achieve a desired outcome, that has been piloted in the Cloud Native world. Someone mentioned CloudNative makes them think of CoreOS. I'm glad you brought this up - If you keep your older versions (by pinning, or ublue keeps the last known booted image by default, and you can change this to keep say 10 if you wanted) - you can always roll back to the version that worked before you encountered a fault. This same pattern exists in the base-line SilverBlue distribution.
This is not an exhaustive analysis but I've already penned a good novel here. I hope this helps outline how universal-blue brings Cloud Native to the desktop. I encourage you to kick the tires and try it out, even if only in a virtual machine.
Could you tell me what's most suspicious about the text? Imo the structure is a bit to well rounded and it kind of reads like a transcript of something someone said not like a comment.
Doesn't look like gpt4 to me, someone should make a "guess the LLM" game.