Cloud native is a set of principles with which you develop and build software to make it less likely to break and be more conducive to rapid iteration(In theory you dont even need to deploy your app to cloud to be cloud native) ublue and project bluefin just cherry picked those principles that make sense for a desktop OS to try and bring what cloud native did for server world into desktop linux and hopefully make it not suck.
one of those sucky things about linux desktop is package management which is just sad at best problematic at worst which is why image-based and flatpak first
> Bluefin is a custom image of Fedora Silverblue. The best of both worlds: the reliability and ease of use of a Chromebook, with the power of a GNOME desktop.
How is it like a "Chromebook"? Are they selling a piece of hardware? If not, then how is the comparison apt?
For example, it would be a weird thing to say "compare Ubuntu 23.x.x with a Chromebook, which one should I use?" because one is an OS and one is a hardware + OS combo, with the hardware manufactured by multiple different companies.
no project bluefin doesnt sell a piece of hardware but chromebook is far more known as a technology then the operating system it runs ChromeOS(based on gentoo)
so its wording targeted at layman
Chromebooks pioneered seamless, image-based system updates for Linux. Updates are downloaded in the background to a separate partition and activated at the next system reboot. This works similarly but using ostree instead of dual root partitions.
It’s closer to a spin of Fedora than a completely different distro because it uses Fedora silverblue with some options about what should be installed by default (including drivers).
Different desktop environments are available, but gnome is the default.
Hi! I worked on this with some friends over the past two years or so (we had to work on the generic tooling first: https://universal-blue.org/)
I'm happy to answer questions you might have! Thanks for checking it out! (I'll be at KubeCon Chicago with stickers if you want the live demo on a Framework 13)
Wow this looks really cool, and I'm excited that you're releasing m1/m2 support soon. I use Silverblue as a daily driver, but so far not on m2 hardware. Looking forward to giving it a shot!
There's stuff to do as far as making ostree/oci builds out of that but we're talking to folks regularly now so hopefully we'll get it sorted. Also a huge shout out to Equinix Metal for sponsoring an Ampere builder for us, hoping to get on as many ARM devices as we can!
My problem with respins and derivatives like this is, they're usually only backed by one developer, and when that developer gets bored with the project, or gets too busy to keep up with bugfixes and patches, everyone has to abandon it and go back to the base distro. They'd be better off just tweaking silverblue themselves at the end of the day.
I use plain old Debian now, but used to love some of the Debian based distros. CrunchBang springs to mind.
I tend to stick pretty close to defaults these days, so some scripts and Ansible playbooks configure everything on all of my machines with not a lot of maintenance or future worries.
(Co maintainer here) Yeah this why don't call it a distro. It's just your scripts/ansible playbooks and then github runs "podman build" regularly and spits out an image at the end.
At the end of the day it's just running a build step in CI so that your machines just end up with the final image instead of running the playbook/script on each one. Hope that helps!
On the note of quay.io, is there a function on the website to see the Containerfile that created the artifact? I recall digging around in the past but couldn't really find a link to the source Containerfile.
Totally agreed one man distros might not get maintained after release or two but:
Behind Bluefin is a project called Universal blue which is a whole bunch of people with many interests, but biggest one being DevOps, devOps combined with its "immutable", image-based nature which should make maintenance of distro lot easier then normal
That runs as root not one but three bits of mutable shell scripts from the internet.
I love me some nix, but the most reproducible package manager should not be install via a hodpodge of directly running scripts from the Internet. Really nothing from my distribution should be doing that.
At the very least they should be vendored as part of the project so you can see when these scripts change.
Random side note: Something with this website causes a bizarre issue when opened: I have youtube open in another browser window and it starts lagging like crazy when the website is opened. I checked to see if there was any spike in gpu/cpu usage but i didn't see anything that stuck out
i saw cloud native and closed the tab. A few hours later i came back to HN and read the comments and realized it was work on top of universal-blue which i was familiar with.
Now i'm actually gonna read the page.
That talk of cloud-native definitely threw me off.
its more applying cloud native principles (principles that work very well in server side even if you don't use cloud) to create stable and well made "next-gen" distros
It's built in the cloud every day, and your machine just fetches the changes. So same thing as image-based, basically, but more eye catching for a cloud professional or something.
your normal distro does updates by pulling every package on your system and swapping files mid running this can cause miriad of issues just by doing it and another miriad if update is stopped mid updating(not always but sometimes). So this means your system is being recomposed at runtime
while on other hand on bluefin and simialr image based OS-s composition of your OS is done somewhere else not directly on your running file system(could be your computer just not your rootFS) then it takes that image and pulls old image(normally on startup) and places new one in its place all in one go, so any composition errors dont get triggered during update and such. (composition before deployment is a principle cloud-native pushes) This makes updates far more stable and less error prone and automatic updates are a thing you dont even notice day to day. and what happens if image cant boot it just boots the old one or you can select the old one from grub(2 old versions are stored per default if i remember correctly) This idea has been successfully used by likes of android chromeOS and such to create seamless and risk free updates.
> This idea has been successfully used by likes of android chromeOS and such to create seamless and risk free updates.
Those are not updates, they are just containers deployments at the end of the day (Flatpak and all related technologies).
> your normal distro does updates by pulling every package on your system and swapping files mid running this can cause miriad of issues just by doing it and another miriad if update is stopped mid updating(not always but sometimes). So this means your system is being recomposed at runtime
In practice rolling distros so that every day, with very little issues. (Arch is a good example of that).
yes it is un update its not a container deployment and this is in no way connected to flatpak outside of ostree
well my experiance and experiance of many other people say otherwise and most wide reaching example look at how a single miss configured package(dependancy misconfiguration) deleted Linus Sebastians pop desktop.(and no the fact that he didnt read doesnt excuse poor package dependancies that even got to that point) that could have easily been caught if composition didnt happen at runtime
On non 0 number of occasions i lost or recoverably broke arch installs while it was updating using pacman just because X or DE's WM got crashed during update because of update. just 2 examples out of many for why composition at runtime is a bad idea for linux to be a more mainstream OS
It seems to be a distribution that applies concepts popular in the cloud/devops world - immutable images, atomic updates, CI pipelines, apps and dev environments running in containers.
I've always been curious about SilverBlue but found many papercuts, especially related to code editors / dev environments and other issues with FlatPak that are still not solved (e.g. mDNS host resolution not working inside FlatPak apps).
I'll be interested in having a look at this one over the next few months as it seems to have some out-of-the-box solutions for many of those, and a lot of thought/effort has been put into it for the past 2 years!
been using bluefin while it was in beta for almost a year and for me it was very easy to move to it as my development workflow is nothing like most and i heavily utilize podman containers on the outset and not system packager or flatpak. this is what i have been recommending to most at this time as it lowers friction whether you use silverblue or not, and enchances tability of your system as if you switch versions doesnt leave lots of gooblygook of orphaned files and such brokedness
Ive been using Bazzite for a while now. it has been great. Works great, has a solid base, but great modifications and additions.I will say I am not a fan of a lot of the distrobox stuff, so I disabled steam, supporting steam stuff, and so on in Distrobox, and replaced it all with direct Flatpak variants. They work better for my needs. I actually had games not work in the distrobox Steam but work just fine in flatpak Steam.
But other than that, everything is just humming along.
65 comments
[ 3.3 ms ] story [ 136 ms ] threadIs it another Linux distro? Does the OS live on my hardware or not?
I would have no idea what that project is just looking the website.
It’s a immutable distro, and that particular flavor is more opinionated on what package is installed at first.
Cool birds picture tho
one of those sucky things about linux desktop is package management which is just sad at best problematic at worst which is why image-based and flatpak first
One can be right and die on this hill, or be thankful that you have the feedback to make it better.
yes
> Does the OS live on my hardware or not
yes
Feels like just Fedora Silverblue with some extra packages installed by default. Haven’t tried it yet but not really interested.
How is it like a "Chromebook"? Are they selling a piece of hardware? If not, then how is the comparison apt?
For example, it would be a weird thing to say "compare Ubuntu 23.x.x with a Chromebook, which one should I use?" because one is an OS and one is a hardware + OS combo, with the hardware manufactured by multiple different companies.
This is the most serious question of all.
If you say yes or no,
You lose your own Cloud-nature.
Different desktop environments are available, but gnome is the default.
I'm happy to answer questions you might have! Thanks for checking it out! (I'll be at KubeCon Chicago with stickers if you want the live demo on a Framework 13)
There's stuff to do as far as making ostree/oci builds out of that but we're talking to folks regularly now so hopefully we'll get it sorted. Also a huge shout out to Equinix Metal for sponsoring an Ampere builder for us, hoping to get on as many ARM devices as we can!
I use plain old Debian now, but used to love some of the Debian based distros. CrunchBang springs to mind.
I tend to stick pretty close to defaults these days, so some scripts and Ansible playbooks configure everything on all of my machines with not a lot of maintenance or future worries.
I run Debian on all of my server stuff at home too. It's not a perfect desktop, but the consistency between machines is something I appreciate.
I use it as my stable base while running most applications from Flatpaks. They're up to date but the OS itself never surprises me.
At the end of the day it's just running a build step in CI so that your machines just end up with the final image instead of running the playbook/script on each one. Hope that helps!
For example I saw that in your blog [1] you used the base on line 1 `FROM ghcr.io/cgwalters/fedora-silverblue:37`.
I was wondering where I could find the Containerfile for that, my Google-fu and searching through the Fedora pages are failing me
[1] https://www.ypsidanger.com/building-your-own-fedora-silverbl...
That's what ends up on quay.io/fedora-ostree-desktops/ which is what we use to make our base images.
Fedora is in the middle of a transition to make more official images on quay.io/fedora, I'm sorry I don't have the info offhand, it's probably in here somewhere: https://discussion.fedoraproject.org/tag/silverblue/l/top?pe...
On the note of quay.io, is there a function on the website to see the Containerfile that created the artifact? I recall digging around in the past but couldn't really find a link to the source Containerfile.
Behind Bluefin is a project called Universal blue which is a whole bunch of people with many interests, but biggest one being DevOps, devOps combined with its "immutable", image-based nature which should make maintenance of distro lot easier then normal
An example is this bit: https://github.com/ublue-os/bluefin/blob/main/usr/bin/ublue-...
That runs as root not one but three bits of mutable shell scripts from the internet.
I love me some nix, but the most reproducible package manager should not be install via a hodpodge of directly running scripts from the Internet. Really nothing from my distribution should be doing that.
At the very least they should be vendored as part of the project so you can see when these scripts change.
Literally everything is running scripts directly from the internet, without any version pinning or check summing.
There is no way to run the same build twice and have any confidence that the result was the same.
https://github.com/ublue-os/bluefin/blob/41bdf294c20a3903f4a...
Now i'm actually gonna read the page.
That talk of cloud-native definitely threw me off.
If it's just a custom Silverblue image why not just say so. It's an idea good enough on its own to not require cloud gobbledygook.
while on other hand on bluefin and simialr image based OS-s composition of your OS is done somewhere else not directly on your running file system(could be your computer just not your rootFS) then it takes that image and pulls old image(normally on startup) and places new one in its place all in one go, so any composition errors dont get triggered during update and such. (composition before deployment is a principle cloud-native pushes) This makes updates far more stable and less error prone and automatic updates are a thing you dont even notice day to day. and what happens if image cant boot it just boots the old one or you can select the old one from grub(2 old versions are stored per default if i remember correctly) This idea has been successfully used by likes of android chromeOS and such to create seamless and risk free updates.
Those are not updates, they are just containers deployments at the end of the day (Flatpak and all related technologies).
> your normal distro does updates by pulling every package on your system and swapping files mid running this can cause miriad of issues just by doing it and another miriad if update is stopped mid updating(not always but sometimes). So this means your system is being recomposed at runtime
In practice rolling distros so that every day, with very little issues. (Arch is a good example of that).
well my experiance and experiance of many other people say otherwise and most wide reaching example look at how a single miss configured package(dependancy misconfiguration) deleted Linus Sebastians pop desktop.(and no the fact that he didnt read doesnt excuse poor package dependancies that even got to that point) that could have easily been caught if composition didnt happen at runtime
On non 0 number of occasions i lost or recoverably broke arch installs while it was updating using pacman just because X or DE's WM got crashed during update because of update. just 2 examples out of many for why composition at runtime is a bad idea for linux to be a more mainstream OS
I'll be interested in having a look at this one over the next few months as it seems to have some out-of-the-box solutions for many of those, and a lot of thought/effort has been put into it for the past 2 years!
But other than that, everything is just humming along.