Project Bluefin: an immutable, developer-focused, Cloud-native Linux
ypsidanger.com
ypsidanger.com
By having less moving parts, it is much easier to provide a Linux operating system that works (more) reliably on many different machines.
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.
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?
Yeah, I know now it's much more usable because it now integrates my host-spawn (https://github.com/1player/host-spawn) tool, but the easiest setup is to have a toolbox/distrobox container for work and dev, where you install all your tools.
I have been using an Arch Linux container (that starts at boot) with emacs, nvim, the myriad of LSP tools that are only found in AUR, exported with `distrobox-export` so I can start them from my dock.
Flatpak is for everything else (even Steam), but dev tools, editors and any other package should be installed inside a regular pet container.
We found that people struggle with the pet toolbox pattern so we send them right to the devcontainer pattern. This is an area where we differ from Fedora. It should just come set up out of the box.
I don't see how one might struggle with learning how to use distrobox. Of course there's some learning curve, but if one wants a normal Linux they might as well use stock Fedora. All one needs is to create a terminal profile that launches `distrobox enter container`.
(I used to use bluefin until recently, when a regression on distrobox forced me back on Silverblue. I could not for the life of me force rpm-ostree to downgrade distrobox to 1.5.0 vs the 1.6.0 bluefin ships with; I reckon it's because bluefin is a container rather than an ostree commit, and downgrading packages is still unsupported)
Though distrobox is bash so maybe running the older version in your home directory would have been a good bandaid in the meantime, maybe I should write that up as a tip?
But yeah +1 on distrobox!
Due to an unrelated issue, switching back from bluefin to the main Fedora tree was just an `rpm-ostree rebase` and a reboot away.
> What if I want something like KDE or another window manager?
> Bluefin is an opinionated GNOME experience. However Universal Blue provides a maintained set of base images for anyone to be able to make a custom image. We hope Bluefin acts as an inspiration for others to build their own communities around user experiences. For example check out Bazzite if you want a great KDE gaming experience, similar to SteamOS.
The Bazzite link 404s, but there is info at https://universal-blue.org/blog/2023/11/08/bazzite-20/ and https://github.com/ublue-os/bazzite. Seems mostly focused on SteamDeck.
If you have an AMD Framework the gnome-power-profiles manager has the inprogress patches from AMD already included and are probably better. Upstream Fedora is also in the process of evaluating `tuned` so in the future there may not even need to be a separate image for Framework.
Rebase instructions here: https://universal-blue.org/images/
I later picked up a framework (exactly 2 weeks ago) and have been daily driving Bluefin on it and the experience is exactly what I'd want from a daily driver. The durability and mindlessness of a Chromebook for updates, options to install all my tools/utilities, and disposable/composable development environments built right into the base system.
Couldn’t agree more with this! :)
I’d be curious to know what aspects you enjoy about Bluefin that has you using it over, say, stock Fedora Silverblue (especially any features that may not be mentioned in the OP)?
What are the best places to hang out to follow along?
take your pick :)
Discourse: https://universal-blue.discourse.group/ Discord: https://universal-blue.org/mission/ (link on left side, click discord) GitHub: https://github.com/ublue-os/
EDIT a few minutes of reading and I seem to get it now. this project and some of the others (Silverblue specifically but also devbox and devpod) have been under my radar but I think I'm going to try this out for a bit.
`rpm-ostree` grew OCI support, which lets us build the entire thing with a dockerfile and github actions, which is much easier, we can run the entire thing out of github.
It would be awesome if you could use Debian for this but alas, no one has made a `deb-ostree`. If someone did it wouldn't be too hard for Universal Blue to publish Debian-based images.
The reason it had to be Fedora was because I can't do this with Debian or Ubuntu. Fedora had the tech but I still enjoy the Ubuntu/Debian part of the OS. Since distrobox exists I can replicate a reasonable facsimile of the native distro with an ubuntu container and a more ubuntu-like desktop.
https://projectbluefin.io scrolls in a really really janky way specifically on mobile firefox. It seems to work correctly on desktop firefox, and mobile chrome. It probably performs poorly in other low resource environments as well.
Even on a desktop browser its easy to stimulate noticeable CPU usage merely by scrolling and almost 400MB of RAM usage explicitly and only for this tab.
Using the 3G profile in firefox dev tools it takes over 40 seconds to load. What is remarkable is how long it took to actually load while only in fact transferring 5MB which is much slower than one would expect even when throttled to 750Kbps.
Even at the DSL profile (2Mbps) its a fairly shockingly slow 16s to load.
Incidentally 2.6 of the 5 is just a png file that could easily be reduced to ~900k without noticeable degradation.
Compare that to the linked blog post which scrolls normally without noticeable CPU usage, loads almost instantly while progressively loading the images and uses about 80MB of RAM.
I must say I love how it looks but it is a triumph of form over function that probably works only if most prospective users are viewing this on fast devices with a fast connection. Bounce rate for websites goes up enormously as one goes over 3-4 seconds.
If your website needs a loading screen and its not a desktop app running in a browser window stop whatever you are doing and throw it away and rethink it.
Reminded me of NanoBSD, which is a readonly version of FreeBSD.
Given that i'm on NixOS atm i'm quite interested in this aspect.
> Bluefin is a custom image of Fedora Silverblue by a bunch of cloud-native nerds.
Fedora Silverblue is an immutable variant of Fedora[0]
One bit of advice for the creators/maintainers: stop saying “cloud native”. It’s effectively meaningless, and definitely confusing. But most importantly, it’s irrelevant. Start with customers and work backwards. And in that process, ask if they really care about “cloud native”. They don’t. So don’t water down or distract people away from a great thing, please.
I guess I'm fortunate in that I already made for the endgame of that quest, which is NixOS.
Everyone should read Eelco Dolstra’s paper IMHO.
ostree > NixOS
NixOS tries to tame the complexity of the Linux world by making the world declarative; a quixotic approach. Ostree is just git+Docker for your operating system image. Also known as "worse is better".
Nix covers not only that but all user-installed libs, apps, etc.
Less is not more in this case. It’s like Mongo vs. Postgres where there are things you can do with Postgres that are either impossible or highly complicated to do in Mongo… due to the lack of a relational engine and JOINs.
The fact that people don’t want to understand JOINs should not be an argument for MongoDB!
It’s just the functional declarative paradigm as applied to package management, going all the way to the metal. This paradigm has succeeded better than the procedural/OOP paradigm in just about every realm of computing where it’s been applied, other than 3-D graphics processing. (Example: All of Whatsapp is run off a single server and 20 engineers. Erlang/BEAM stack.) If you can’t see, or aren’t on board with the latter, then you won’t understand or see the former.
If you’ve ever preferred to style HTML using CSS instead of JavaScript, then you’re starting to see it.
I cannot take this project seriously. Dope art, though.
The funny thing, is that it is a website, web applications can be built for developers, the scrolling doesn't lag on my device, the spinner doesn't bother me, and it completely respects my navigation controls. I think you have a "you" problem, and enjoy projecting it at anything that doesn't fit into your mental model of how the world "should be". Go solve that, and you can come back and be a productive participant in these conversations.
On several of my devices that are plenty fast enough for pretty much anything else, the scrolling is still pretty laggy.
Looking at CPU usage I see that having this page open, eats an unnecessary amount (>70%) of CPU for what appears to be a static page, so there's definitely something not quite right there.
Odd that you responded to me saying this, as I made no claims about my experience being universal, I was quite obviously just speaking for myself as an exception to their universal claims. Go read the parent comment again, you still have time to edit yours and point it in the right direction.