It would be so nice to get a brief description of what this is, and why it is useful, without a bunch of project names and buzzwords. Can it be boiled down to a few simple concepts that are delivered by this project?
It is a Linux distribution that is based on Fedora Silverblue (another Linux distribution). What makes these distributions special is that they have an immutable/readonly root file system, which means that only /var (which contains /var/home) and /etc can be manipulated directly by root.
By having less moving parts, it is much easier to provide a Linux operating system that works (more) reliably on many different machines.
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.
Hey Jorge! Just chiming in to say that I really appreciate the work you've done on ublue-os. I've been using your nvidia image on my Linux workstation, and it's been really great. Thanks!
> Why isn't Fedora Silverblue sufficient by itself? What does this project add?
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.
The cloud-native part is that it's built with tools and things you'd see in cloud-native like OCI containers, gitops, etc. Here's the containerfile as an example of how it's put together: https://github.com/ublue-os/bluefin/blob/main/Containerfile
And then all the developer patterns are cloud native like devcontainers instead of using the host packages, included k8s, podman, and docker tooling, etc.
So "Cloud Native" speaks to multiple aspects of how universal-blue is both built, distributed, and some of the guiding principals behind the project.
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.
Having personally also fucked up a silverblue install (featuring a DKMS kernel module I built to support my DSLR camera hdmi capture card) with proprietary nvidia drivers - and then let it sit on that partition long enough that my fedora version was too out of date to pull updates for; and as someone who builds CI pipelines in $DAYJOB: thank you so very very much.
Oh i have a rather hard time to notice AI comments if the language they are written in isn't my native one.
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.
It's a sad world when a thoughtful, well-structured, obviously experience-based and informative comment is immediately assumed to be word guessing machine generated garbage.
Wow, I wish I'd discovered this about 12 hours ago. I just built a new PC yesterday and started installing and configuring Silverblue today, and basically everything I spent this afternoon on is automated by this project. Getting VSCode devcontainers working with Silverblue + Distrobox in particular would have saved me some time. Since I'm not particularly invested in my Silverblue setup yet, I'm installing this now.
Tip from one that has been running Silverblue for years: VSCode or any other editor from flatpak is a noob trap.
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.
Bluefin comes with vscode and devcontainers set up out of the box, we don't recommend pet containers.
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.
VSCode and Devcontainers work iff you want to use VSCode. Using Silverblue or Bluefin without toolbox or distrobox is setting yourself up for failure, because otherwise one will try to install everything through rpm-ostree and then complain that ostree is slow and stupid.
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)
We've held back versions of distrobox before, if you file an issue we can usually figure it out.
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?
A minor word of caution: don't use distros with unique(ish) features in production if you can't replace those features (quickly). It's of course a cost/effectiveness consideration, but I've been bitten by that when I inherited a project that ran on an immutable distribution that was withdrawn. There was a fork, but there was no upgrade path and the hosting company didn't offer it as an install on new servers, so now the thing runs on an LTS Ubuntu. When development on that stops, switching to another Linux should be easier.
What does "cloud-native" mean in this context, if anything? When I hear the term, I think of things like CoreOS, whereas this looks rather desktop-focused.
It's worth noting that the submitter didn't use the actual title, and TFA doesn't characterize Bluefin as a "cloud-native Linux", but a distribution made by "cloud-native nerds" that integrates tools generally associated with cloud development (kind, flux, helm, kubectl).
Most here seem to understand it pretty wrong. I think it's basically about the OS being built in the cloud every day, with your computer just ingesting the diffs. This is opposed to traditional distributions, where after the initial installation packages installed are all pulled & updated individually on your host system.
I read this article and ended up with the exact same question. Does it mean that it wants to imitate Chromebooks, where the most important app you use is the browser, and all of your apps are in the cloud rather than on the desktop?
No, the OS itself is a read-only container image booted on bare metal (via OSTree) and includes the tools usually used to build container images (used for kubernetes etc), as well as pushing desktop applications via Flatpak.
I guess it makes you feel better as a user to be part of the hyper converged buzzword bingo. But seriously it seems to be both web and container (web) focussed. They should maybe rather say what they are not and what the limitations of their approach is ( I guess isolation comes at some costs)
This is the announcement post, which is pretty old by now. Lots of great things have happened since, and it’s worth a look! This is my go-to distro when I build a computer for family. It’s bullet proof, practical, and everything auto updates with zero user interaction.
> 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.
Bluefin is one of the many Universal Blue images. Under the full image list https://universal-blue.org/images/, there are images for KDE (under the name Kinoite), Cinnamon, Mate, Budgie, Deepin, LXQt, and others.
Are there any special images that are designed for use with Framework computers? For silverblue there is "silverblue-framework": https://universal-blue.org/images/#38_85
Yep: `bluefin-framework` and `bluefin-dx-framework` for the stock and developer version. We also have asus and surface images with their respective kernels.
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.
I've been a consumer of bazzite for almost a full year now. I built an AMD based gaming machine and wanted an experience as pleasant as SteamOS but for HTPC's. That was what first turned me on to the universal-blue project.
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.
Bluefin has been my daily driver for over a year now. Love the community of people just trying to make Linux awesome on the desktop. I'm happy to answer questions about the project too.
> Love the community of people just trying to make Linux awesome on the desktop
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)?
There's a discourse forum if you're into async, or there's a Discord server for more up-to-the-minute updates. Along with the github repos to track bugs, feature requests, and see how the project is made.
I would love to know why it's based on Fedora instead of Debian since it seems to be highly influenced by Ubuntu.
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.
Hi! I work on this. There's no `rpm-ostree` equivalent in Debian, so you'd have to make an image natively with ostree. This is what EndlessOS does: https://www.endlessos.org/os
`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.
The information is well thought out and relevant but I have mixed feelings about the envelope its delivered in.
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.
One could argue that the information page you're profiling is designed for maximum attention grabbing, and is for an OS that is based on containers, development, and a combination of the two. If you're primarily a kuberbetes dev interested in working and reproducing locally, you probably have the resources on your machine to render this smoothly and properly. And have a fast enough connection to make the bandwidth claims negligible.
In that way, I guess it's good gatekeeping for who and what should run Bluefin. I recently learned this myself after installing Bluefin DX on both a low resource machine and my main dev box.
Protip: probably should be used only on your main dev box at the moment
It's a web page. It's not even a web app its just scrollable text interspersed with video and links. You don't really have to "optimize" it to not hit the CPU on a 6 core desktop computer, use 400MB of RAM, or lag on a phone. It's not a technical trade off its just 5 minute job that probably should have been a 15 minute job.
What I'm missing is a very simple step by step how to get started guide. How would I test this out? I love the enthusiasm! But if you want a new generation to use this the entry barrier should be lower than a link to GitHub release page.
I love the concept here and will absolutely give this a go.
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'm not using neither nix nor those flatpak/distrobox/all-containers-distro things, but I tried both, and I really don't see a single argument why those would be a better approach than nix. It's so coherent and fast and lightweight, and seems like a much simpler approach for everybody involved (well, apart from the language which can be confusing for sys guys like me).
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've opened up the website https://projectbluefin.io, but it turns out that this is not a website, but rather a web application. You cannot do things like this and claim it is built for developers. Scrolling lags, it shows a loading spinner and it does not respect navigation controls.
I cannot take this project seriously. Dope art, though.
Interesting choice of gatekeeping you do here. Complain that it's a "web application" instead of a website, then claim that web applications cannot be built for developers. And to round it all off, whine about scrolling latency, that it has a spinner, and that it "doesn't respect navigation controls", whatever that means. Did I miss anything, or does this sum the contents of your post?
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.
I can't believe I have to say this but your experience is not universal.
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.
You and I are in agreement, that no one's experience is universal. That is why I was compelled to respond to aerzen, who was very much claiming that his experiences and viewpoints are universal across all developers.
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.
The more I re-read the comments, the more ludicrous it seems for you to target your comment at me. The parent poster I understand, but you... Why exactly did you think I was making universal claims for all developers, especially given the parent comment? I cannot find an interpretation of my comment that even suggests that is the case. What were you thinking?
Remember the adage about not judging a book by its cover? Usually applies to a lot of cool stuff in software and hardware. Not tried Bluefin, but Debian's site looks quite archaic, yet is very cool as a project. I could go on for hours.
Yes, we know the adage, but as many people do indeed judge a book by its cover, perhaps greater attention should be put in covers, or websites, and especially websites of new projects.
Perhaps. Or perhaps with finite time, energy, resources and money, we should focus on substance over style. Pull requests are usually welcome when it comes to the sizzle alongside the steak.
